OAuth Implicit Flow | Curity
On this page
Implicit Flow vs Code Flow
The implicit flow (also referred to as implicit grant flow) is a browser only flow. It is less secure than the Code Flow since it doesn't authenticate the client. 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).
Overview of the Flow
- Browser redirects to the authorization endpoint at the Token Service of the Authorization Server
- If the user is not yet authenticated the Token Service of the Authorization Server redirects to the Authentication Service
- The user authenticates, and is redirected back to the Token Service
- The Authorization Server issues the access token immediately and redirects back to the client
User Authentication
The user is authenticated during the Authorization flow. This may involve multiple factors and is not defined by the OAuth specification. In the Curity Identity Server all user authentication is configured in the Authentication Service and is configured per client.
Client Authentication
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 clients can use to call the API and gain access. It is often a Bearer token, and as such must not be sent to untrusted parties. The access token usually has 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 the Curity Identity Server 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
- Method:
GET - Agent: Browser
- Response Type: Redirect to pre-registered callback at client with parameters in the fragment
Request Parameters
| Parameter | Value | Mandatory | Description |
|---|---|---|---|
| client_id | The Client ID | yes | The ID of the requesting client |
| response_type | token | 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. |
Response
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.
| Parameter | Value | Mandatory | Description |
|---|---|---|---|
| state | The same value as given in the request | yes* | The same value as the client sent in the request. Use to match requests 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 were issued. If present the issued scopes may differ from the requested scopes. |
| token_type | Bearer or other token type | yes | Describes how the token can be used. Most commonly Bearer token usage. |
Replacing the Implicit Flow
Since the implicit flow returns tokens directly in browser URLs it has security issues and is not a recommended OAuth flow. The implicit flow originates from the early days of OAuth, where some environments did not support cross-origin requests from the browser to the token endpoint. These restrictions no longer exist.
Nowadays, your app should follow the recommendations from the OAuth for Browser-Based Apps document. Use the code flow with an implementation that keeps all tokens out of the browser. Only return the most secure HttpOnly cookies in the browser, to limit the impact of JavaScript exploits. Curity recommends that you use the token handler pattern.
Jacob Ideskog
Identity Specialist and CTO at Curity
Join our Newsletter
Get the latest on identity management, API Security and authentication straight to your inbox.
Start Free Trial
Try the Curity Identity Server for Free. Get up and running in 10 minutes.
Start Free Trial
