authentication design document. #65
Conversation
| that lack a token or have an invalid/expired token. The signature needs to be | ||
| validated to ensure that the token has not been tampered with. An expired ID | ||
| token can be refreshed (as long as the refresh token has not expired). | ||
| 1. [CXG7] The cellxgene server will have an endpoint to check if the requestor |
There was a problem hiding this comment.
Can you add a note here to explain under what user story, this endpoint will be hit?
There was a problem hiding this comment.
The cellxgene frontend needs to know if the user is authenticated in order to show an Log In button or a Log Out button. I can add that. I have a new endpoint for this called "userinfo".
| 1. [CXG8] To avoid causing the ID token to expire while the user is working | ||
| (and thus disrupting the user’s work), the token can be automatically refreshed | ||
| when the ID token expires. The | ||
| expiration date of the Refresh token could be set to the maximum of 30 days. |
There was a problem hiding this comment.
Is this 90 days now? I forget...
There was a problem hiding this comment.
Actually, this should be indefinite now. The refresh token is itself is refreshed when the id token expires. So, a user can be logged in indefinitely as long as they visit the website at least once per 90 days. I can add a comment for that.
|
|
||
| 1. [C1] An authenticated user will have the option to logout | ||
| 1. [C2] An unauthenticated user will have an option to login | ||
|
|
There was a problem hiding this comment.
Are there additional requirements that were met here that mirror the cellxgene requirements? For example, I'm thinking that number 8 (refresh cycle), number 6 (ensuring that token is clean), and number 7 might have already been implemented? Also a requirement that auth is hidden under a flag until it is ready to be turned on (or however this is being done).
There was a problem hiding this comment.
Yeah, portal and cellxgene work in the same way. These should be reframed as common requirements.
|
|
||
| General | ||
|
|
||
| 1. [G1] GDPR requirements: For gdpr, the main thing we need to log is user id + time stamp for |
There was a problem hiding this comment.
Curious - where do we store this information?
There was a problem hiding this comment.
auth0 stores this. We can get the logs or access to the their DB if we need to.
| implemented in the client side. This has now been changed to | ||
| using the Authentication Code flow in the backend (same as cellxgene). This approach is | ||
| simpler with respects to the single sign on strategy. It avoids a step where the client | ||
| needs to access the server to set the cookie containing the tokens. It is also more secure. |
|
|
||
| - Login: start the authentication flow, set the cookie when complete | ||
| - Logout: logout, remove the cookie | ||
| - Is-authenticated: check if authenticated, and return user information |
There was a problem hiding this comment.
Sorry, I can't remember if this was built or not, but can you replace with the actual endpoint name if it was?
| that this question has already been asked, and we first verify the answer before proceeding | ||
| with the login process. | ||
|
|
||
| ## Detailed Design | Architecture | Implementation |
There was a problem hiding this comment.
Sorry I forget, did we add any tables to the RDS for cellxgene to keep track of users? Or do we only store their identify for annotations?
| cellxgene server in the diagram. | ||
|
|
||
|  | ||
|
|
There was a problem hiding this comment.
If you're willing/able to, I think a sequence UML diagram that showcases the steps for the login flow you've described below would be super helpful! It would show a clear picture of when the endpoints are called, by whom, and in what order. You could even substitute it for the above diagram which I (personally) don't find to be super helpful without cross checking with the wording below.
This version of the document is a translation from the google doc version. Some light reformattingh has been applied, but the content is basically identical. I will followup with content changes to reflect the current state, and add sections providing more details about the deployments.
tihuan
force-pushed
the
bmccandless/auth
branch
from
394798f
to
3bc8394
Compare
|
|
||
| ## References | ||
|
|
||
| [0][location to the authorization code flow diagram](https://auth0.com/docs/architecture-scenarios/web-app-sso/part-1) |
There was a problem hiding this comment.
@bmccandless if we want the link text not be lowercase, we'll need to add \ before the number like below, otherwise linter will force lowercase! Thank you!
## References
\[0][IETF's Github Process](https://tools.ietf.org/html/draft-ietf-git-using-github-06)
\[1][Google Developer Documentation Style Guide](https://developers.google.com/style/highlights#introduction_1)
\[2][Data Coordination Platform RFC Process](https://github.com/HumanCellAtlas/dcp-community/blob/master/rfcs/text/0001-rfc-process.md)
|
|
||
| - The login request. The client sends a request to the “/login” endpoint of the cellxgene | ||
| server. The request contains the location to the current dataset which will be used to | ||
| redirect the user back at the end of the process. The location can be path within the current |
There was a problem hiding this comment.
| redirect the user back at the end of the process. The location can be path within the current | |
| redirect the user back at the end of the process. The location must be a path within the current |
| - The cellxgene server then redirects (full page nav) the user back to the original dataset | ||
| , and directs the client to save the JWT in an httpOnly cookie on the client. | ||
| - The JWT proves the identity of the client. Subsequent requests from the client to the | ||
| cellxgene server will include the cookie with the JWT. When the cellxgene client re-requests |
There was a problem hiding this comment.
| cellxgene server will include the cookie with the JWT. When the cellxgene client re-requests | |
| cellxgene server will include the cookie with the `id_token`. When the cellxgene client re-requests |
might be worth the extra specificity wrt the oauth2/oidc protocol
| process by going back to step [1] | ||
| 2. The server will verify the signature of the token to ensure that it was signed by the | ||
| sender and not altered. | ||
| 3. If the ID token is expired, then the server will obtain a new ID token automatically |
There was a problem hiding this comment.
| 3. If the ID token is expired, then the server will obtain a new ID token automatically | |
| 3. If the ID token is expired, then the client will obtain a new ID token automatically |
I think this happens client-side?
|
|
||
| An alternative is to use the authorization code with proof key code exchange (PKCE). This is | ||
| the approach you might use in a single page app where you do not want the code running in a user’s | ||
| browser to have access to the auth0 client secret. |
There was a problem hiding this comment.
| browser to have access to the auth0 client secret. | |
| browser to have access to the oauth2 client secret. |
|
I would finish up this PR in before making additional changes from https://app.zenhub.com/workspaces/single-cell-5e2a191dad828d52cc78b028/issues/chanzuckerberg/corpora-data-portal/631undefined |
This version of the document is a translation from the google doc version.
Some light reformattingh has been applied, but the content is basically identical.
I will followup with content changes to reflect the current state, and add
sections providing more details about the deployments.