Idea #4919
open
[API] Arvados clients can use standard OAuth2 protocol instead of custom token handling mechanism
Description
While the API server uses OAuth2 to authenticate with the SSO server, Workbench does not use OAuth2 to authenticate with SSO directly, but instead follows a custom login flow that authenticates the user on API server with SSO, and then returns an API server token to workbench via a query parameter in a redirect URL.
https://tools.ietf.org/html/rfc6750 section 5.3:
Don't pass bearer tokens in page URLs: Bearer tokens SHOULD NOT be
passed in page URLs (for example, as query string parameters).
Instead, bearer tokens SHOULD be passed in HTTP message headers or
message bodies for which confidentiality measures are taken.
Browsers, web servers, and other software may not adequately
secure URLs in the browser history, web server logs, and other
data structures. If bearer tokens are passed in page URLs,
attackers might be able to steal them from the history data, logs,
or other unsecured locations.
Also, section 2.1:
OAuth2 specifies that the Authorization header using access tokens is "Authorization: Bearer XYZ" ( not "Authorization: OAuth2 XYZ" (which we use now)
Updated by Peter Amstutz almost 10 years ago
Proposed flow for workbench:
- Workbench login button sends browser directly to SSO for sign in (no redirects via API server)
- SSO server performs log in, and redirects the user back to workbench with authorization code
- Workbench gets browser request with authorization code
- Workbench sends login request with authorization code to API server
- API server gets workbench request with authorization code
- API server sends authorization code to SSO for validation
- SSO gets request with authorization code from API
- SSO validates user identity and responds to API
- API gets response from SSO
- API server finds/creates user for associated SSO
- API server creates new API token and responds to workbench
- Workbench gets API token and puts it in the browser session
- Respond to browser by loading the desired page
Updated by Peter Amstutz almost 10 years ago
Proposed flow for browser based apps that talk to API server directly:
- Login button sends browser directly to SSO for sign in (no redirects via API server)
- SSO server performs log in, and redirects the user back to browser app with authorization code
- Browser app sends login request with authorization code to API server
- API server gets browser app request with authorization code
- API server sends authorization code to SSO for validation
- SSO gets request with authorization code from API
- SSO validates user identity and responds to API
- API gets response from SSO
- API server finds/creates user for associated SSO
- API server creates new API token and responds to browser app
- Browser app gets API token and possibly puts it in local storage
- Browser proceeds to use API token to communicate with API server directly
Updated by Peter Amstutz almost 10 years ago
- Subject changed from Workbench uses OAuth2 instead of custom login flow to Arvados web apps use OAuth2 instead of custom login flow
Updated by Peter Amstutz almost 10 years ago
Also, OAuth2 specifies that the Authorization header using access tokens is "Authorization: Bearer XYZ" (https://tools.ietf.org/html/rfc6750) not "Authorization: OAuth2 XYZ" (which we use now)
Updated by Tom Clegg almost 10 years ago
- Subject changed from Arvados web apps use OAuth2 instead of custom login flow to [API] Arvados clients can use standard OAuth2 protocol instead of custom token handling mechanism
- Story points set to 2.0
Updated by Tom Clegg almost 10 years ago
- Target version set to Arvados Future Sprints
Updated by Ward Vandewege over 3 years ago
- Target version deleted (
Arvados Future Sprints)