OAuth Implicit Flow

OAuth Implicit Flow

develop

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).

Authorization Endpoint

Implicit Flow

  1. Browser redirects to the Authorize endpoint of the OAuth Server
  2. If the user isn't authenticated the OAuth Server redirect to the Authentication Service
  3. The User authenticates, and is redirected back to the OAuth Server
  4. The OAuth 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

ParameterValueMandatoryDescription
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.

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.

ParameterValueMandatoryDescription
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.
Was this page helpful?