How to use the OAuth implicit flow and its differences with the OAuth code flow.

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

Abstract showing the process of implicit flow
  1. Browser redirects to the authorization endpoint at the Token Service of the Authorization Server
  2. If the user is not yet authenticated the Token Service of the Authorization Server redirects to the Authentication Service
  3. The user authenticates, and is redirected back to the Token Service
  4. 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

client_idThe Client IDyesThe ID of the requesting client
response_typetokenyesDefines the flow type: implicit flow
statea random valuenoWill be provided back to the client in (4). Useful to keep track of the session in the client or to prevent unsolicited flows.
scopeSpace separated string of scopesnoList the scopes the client is requesting access to.
redirect_uriThe client callback URLno*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.

stateThe same value as given in the requestyes*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_tokenA newly issued access tokenyesThe resulting access token for the flow
expires_inExpiration in secondsyesThe time to live of the access token in seconds
scopeSpace separated stringnoIf not present the requested scopes where issued. If present the issued scopes may differ from the requested scopes.
token_typeBearer or other token typeyesDescribes 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.

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