OAuth Implicit Flow
The OAuth Implicit Flow in Detail.
Implicit Flow Overview¶
The implicit flow is a browser only flow. It is less secure than the Code Flow since it doesn't authenticate the client. But it is still a useful flow in web applications that need access tokens and cannot make use of a backend. Since it doesn't rely on the client being able to make back-channel calls it only consists of calls to the Authorization endpoint (compared to the Code flow which also has calls to the Token endpoint).
- Browser redirects to the Authorize endpoint of the OAuth Server
- If the user isn't authenticated the OAuth Server redirect to the Authentication Service
- The User authenticates, and is redirected back to the OAuth Server
- The OAuth Server issues the Access Token immediately and redirects back to the client
The user is authenticated during the Authorization flow. This may involve multiple factors and is not defined by the OAuth specification. In Curity all user authentication is configured in the Authentication Service and is configured per client.
The client is never authenticated in the implicit flow. This is a significant difference to the code flow.
The Access Token¶
The Access Token is returned by the token endpoint. It is the token that later can be used to call the API and gain access. It is a Bearer token, and must not be sent to untrusted parties. The access token usually have a lifetime of 5-30 minutes.
The Refresh Token¶
No refresh token is issued during the implicit flow, instead if a client needs additional access tokens it needs to re-authorize. If Curity is configured with Single Sign-On the re-authorization can happen without user interaction since the SSO session might still be valid.
The Authorize Endpoint¶
- Agent: Browser
- Response Type: Redirect to pre-registered callback at client with parameters in the fragment
|client_id||The Client ID||yes||The ID of the requesting client|
|response_type||yes||Defines the flow type: implicit flow|
|state||a random value||no||Will be provided back to the client in (4). Useful to keep track of the session in the client or to prevent unsolicited flows.|
|scope||Space separated string of scopes||no||List the scopes the client is requesting access to.|
|redirect_uri||The client callback URL||no*||The redirect_uri the client wants (4) to redirect to. *Mandatory if multiple redirect URIs are configured on the client.|
A redirect back to the “redirect_uri”. Response parameters are provided on the fragment part of the URL. This means that only the browser can access the values of the response. The client server will not receive these values.
|state||The same value as given in the request||yes*||The same value as the client sent in the request. Use to match request to the redirect response. *Mandatory if the state was sent in the request|
|access_token||A newly issued access token||yes||The resulting access token for the flow|
|expires_in||Expiration in seconds||yes||The time to live of the access token in seconds|
|scope||Space separated string||no||If not present the requested scopes where issued. If present the issued scopes may differ from the requested scopes.|
|token_type||yes||Describes how the token can be used. Most commonly Bearer token usage.|
Let’s Stay in Touch!
Get the latest on identity management, API Security and authentication straight to your inbox.