Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebAuth Proof of Concept #1058

Open
wants to merge 76 commits into
base: main
Choose a base branch
from

Conversation

Benjamin-Philip
Copy link
Contributor

@Benjamin-Philip Benjamin-Philip commented Oct 7, 2021

The following is a Proof of Concept for web auth.

Closes #1024

@Benjamin-Philip Benjamin-Philip marked this pull request as ready for review October 7, 2021 12:53
@Benjamin-Philip
Copy link
Contributor Author

@wojtekmach here's the pr.

@Benjamin-Philip Benjamin-Philip changed the title Bp web auth po c Bp web auth poc Oct 7, 2021
@Benjamin-Philip Benjamin-Philip changed the title Bp web auth poc WebAuth Proof of concept Oct 7, 2021
@Benjamin-Philip Benjamin-Philip changed the title WebAuth Proof of concept WebAuth Proof of Concept Oct 7, 2021
@Benjamin-Philip Benjamin-Philip marked this pull request as draft October 7, 2021 13:48
lib/hexpm/web_auth.ex Outdated Show resolved Hide resolved
@Benjamin-Philip
Copy link
Contributor Author

Does everything else look fine?

@Benjamin-Philip
Copy link
Contributor Author

Benjamin-Philip commented Oct 14, 2021

@ericmj , I have got an incomplete implementation in Schema. Whenever I run Repo.update in submit, I get the following error. I figured it might be due to the way I am migrating this, but I am unable to troubleshoot. Any ideas?

** (DBConnection.EncodeError) Postgrex expected an integer in -9223372036854775808..9223372036854775807, got %{id: 2344, inserted_at: ~U[2021-10-14 12:19:23.249932Z], last_use: nil, name: "Web Auth foo key", organization_id: nil, permissions: [%{domain: "api", id: "ad886288-2d8f-4c9c-b888-859b1d4c8953", resource: "write"}], public: true, revoke_at: nil, revoked_at: nil, secret_first: "3c663e623cc7cd32516dfc99c2b3c990", secret_second: "65a86ffcfe4f6299f910e48117cbca71", updated_at: ~U[2021-10-14 12:19:23.249932Z], user_id: 8435}. Please make sure the value you are passing matches the definition in your table or in your query or convert the value accordingly.

@ericmj
Copy link
Member

ericmj commented Oct 14, 2021

I have got an incomplete implementation in Schema. Whenever I run Repo.update in submit, I get the following error. I figured it might be due to the way I am migrating this, but I am unable to troubleshoot. Any ideas?

It's hard to say without seeing what's being updated and when I try to run your branch it fails with a compilation error, but it looks like postgres is expecting an id/integer where you are passing a Key schema or Key params.

I do notice that you are creating a Key with Keys.create and then embedding it in WebAuth which means it is stored in two places which we should try to avoid. Why does WebAuth need to store a Key?

@Benjamin-Philip
Copy link
Contributor Author

Benjamin-Philip commented Oct 14, 2021

@ericmj, I need to return the key when the user attempts to access it in the last step.

Since, the web auth requests are temporary, I cannot do a one to one association.

I could return a url to access the key which I think right now is the best approach , but I am not sure if I can access a generated key via the api.

@ericmj
Copy link
Member

ericmj commented Oct 14, 2021

I need to return the key when the user attempts to access it.

Will the user need to fetch the key multiple times? Isn't it enough to create the key first when the user needs it and then not store it separately?

@Benjamin-Philip
Copy link
Contributor Author

Benjamin-Philip commented Oct 14, 2021

@ericmj Well, the cli won't.

On second thoughts, storing the generated key's primary id and accessing it when the user needs is doable.

Wdyt?

@ericmj
Copy link
Member

ericmj commented Oct 14, 2021

On second thoughts, storing the generated key's primary id and accessing it when the user needs is doable.

I think we should only generate the key when the user needs it and never let them access it again. We should not store the user secret of the key, if you look at the Key code you can see that we only store the hashed version of the key secret. The reason being if the database is compromised you cannot use that information to authenticate to Hex. If the user can retrieve the key multiple times the point of this is moot.

@Benjamin-Philip
Copy link
Contributor Author

If the user can retrieve the key multiple times the point of this is moot.

So, in the GenServer implementation, the request is deleted after few minutes, after which the user can't access the key.

Anyways, we'll generate the key when the user attempts to access it like you said.

@Benjamin-Philip
Copy link
Contributor Author

Benjamin-Philip commented Oct 16, 2021

@ericmj, I have pushed a complete implementation of WebAuth. Please review when you get the time. :)

Note: It doesn't compile on this branch as I have made some changes to the Phoenix Router which I have not committed which it depends on (To determine the verification and access_key uri).

@Benjamin-Philip
Copy link
Contributor Author

@ericmj, also I don't plan to work on the controller so as to avoid doing redundant work in case the Schema implementation is not to your satisfaction.

lib/hexpm/accounts/web_auth.ex Show resolved Hide resolved
lib/hexpm/accounts/web_auth.ex Outdated Show resolved Hide resolved
lib/hexpm/accounts/web_auth.ex Outdated Show resolved Hide resolved
lib/hexpm/accounts/web_auth.ex Outdated Show resolved Hide resolved
@ericmj
Copy link
Member

ericmj commented Nov 16, 2021

@Benjamin-Philip I noticed you pushed more commits. Let us know when it's ready for second review.

@Benjamin-Philip
Copy link
Contributor Author

Benjamin-Philip commented Nov 17, 2021

Sure.

I only fixed some minor stuff and still have to split the Web auth module into a context. I also have the remove the extra information.

The thing is this and next month, I may not have much time to work on this PR. So updates are going to be slow.

@Benjamin-Philip
Copy link
Contributor Author

Sure.

I only fixed some minor stuff and still have to split the Web auth module into a context. I also have the remove the extra information.

The thing is this and next month, I may not have much time to work on this PR. So updates are going to be slow.

@ericmj, I hope there isn't a hurry?

@wojtekmach
Copy link
Member

There is no rush :)

@Benjamin-Philip
Copy link
Contributor Author

@ericmj and @wojtekmach, I have split WebAuth into a context and a schema.

I'm not very sure if what I have done is the right way to go about it. (All the functions in the Context are impure, so I think it is.)

@Benjamin-Philip
Copy link
Contributor Author

@ericmj, and @wojtekmach, please review the WebAuthRequest schema and the WebAuth context so that I can make improvements (or plan accordingly to work on them).

Note: Changes to HexpmWeb is not yet review ready.

lib/hexpm/accounts/web_auth.ex Outdated Show resolved Hide resolved
lib/hexpm/accounts/web_auth.ex Outdated Show resolved Hide resolved
lib/hexpm/accounts/web_auth.ex Outdated Show resolved Hide resolved
lib/hexpm/accounts/web_auth.ex Outdated Show resolved Hide resolved
lib/hexpm/accounts/web_auth.ex Outdated Show resolved Hide resolved
test/hexpm/accounts/web_auth_test.exs Outdated Show resolved Hide resolved
test/hexpm/accounts/web_auth_test.exs Outdated Show resolved Hide resolved
lib/hexpm/accounts/web_auth.ex Outdated Show resolved Hide resolved
lib/hexpm/accounts/web_auth.ex Outdated Show resolved Hide resolved
lib/hexpm/accounts/web_auth_request.ex Outdated Show resolved Hide resolved
Benjamin-Philip and others added 24 commits May 4, 2022 16:05
Co-authored-by: Eric Meadows-Jönsson <eric.meadows.jonsson@gmail.com>
Co-authored-by: Eric Meadows-Jönsson <eric.meadows.jonsson@gmail.com>
Previously, the browser user agent was used to creating an audit.
This had the following problem:

- It gave a false sense on whose request the key was generated.
- The user agent was stored under the field `audit` which caused confusion.

This commit changes the WebAuth flow so that the client's user agent
(that is on the `access_key` action) is used to create a key.
WebAuth requests made a day (i.e. stale) before should not be supported.

This commit adds support for the `submit` and `access_key` actions to
filter out stale requests when querying the DB.
This commit adds a release task that will remove all stale requests
from the database.
This commit adds the RFC that was used as a reference when developing
the WebAuth flow as a comment
The audit data format changed and required an ip address.
This commit updates the WebAuth PR to use this new format.
@Benjamin-Philip
Copy link
Contributor Author

Benjamin-Philip commented May 4, 2022

@ericmj and @josevalim, could we request someone else to review this PR as well?

This PR went out of date and had errors due to changes in main. I think we should try to merge this PR as soon as possible to prevent such errors - updating this PR to work with main periodically may prove a hassle to me and the reviewers.

@Benjamin-Philip
Copy link
Contributor Author

Also I rebased this PR to main.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Web auth to authenticate CLI from browser
4 participants