OAuth Implicit Flow
On this page
Implicit Flow vs Code Flow
The implicit flow (also refer 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. 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).
Authorization Endpoint
- 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 Curity 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 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
- 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 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 | Bearer or other token type | yes | Describes how the token can be used. Most commonly Bearer token usage. |
Prefer the Code Flow
Since the implicit flow returns tokens directly in browser URLs, it is no longer recommended as a best practice. Nowadays, the code flow is the standard option for the best security.
