Implicit flow
The Implicit flow has been omitted in OAuth 2.1 specification. It is no longer recommended to use Implicit flow for SPAs. Please refer to authorization code flow with PKCE for SPAs
Prerequisite
- Setup the OpenID Connect custom application
Implicit grant is a simplified version of an authorization code grant. In the implicit grant type, the client is directly issued an access token and ID token on the authorization request instead of returning the authorization code. It is primarily used for clients implemented in a browser using a scripting language such as Javascript.
The authorization server does not authenticate the client in this grant type. Implicit grant type improves the responsiveness and efficiency of some clients as it reduces the round trips required to obtain the tokens.
How does it work?
In this flow,
- The client application (or relying party), the bank sends an authorization request with the client ID and client secret to CyberArk Identity, which acts as the authorization server. The response_type in this flow is id_token token
- CyberArk Identity authenticates the user and redirects the user with access, ID, and optionally refresh tokens
Integrate CyberArk Identity's implicit code flow
The first endpoint to be invoked is the /oauth2/authorize/ endpoint. The response_type is set to id_token token (or) id_token to indicate that it is an implicit code flow:
{tenant_url}/oauth2/authorize/{application_id}?scope={scope}&response_type=id_token token&redirect_uri={redirect_uri}&client_id={client_id}
If the user is not authenticated to CyberArk Identity, the response contains HTML with a redirect URI to a login page:
<html><head><title>Object moved</title></head>
<body>
<h2>Object moved to <a href="/login?cloudRedirect=Oauth2%2FAuthorize%2Ftest%3Fbounce%3DKZhmpLy...">here</a>.</h2>
</body>
</html>
The client invokes the cloud redirect URI mentioned above by appending the tenant URL:
GET {tenant_url}/login?cloudRedirect=Oauth2%2FAuthorize%2Ftest%3Fbounce%3DKZhmpLy...
As the user authenticates through the login page, the Start Authentication and Advance Authentication endpoints are invoked.
When the user successfully fulfills the security challenge(s), the /oauth2/authorize/{app ID} endpoint is invoked internally. This time, the response contains an access token, ID token, and optionally refresh token in the code query parameter of the redirect URI returned:
<html><head><title>Object moved</title></head>
<body>
<h2>Object moved to <a
href="{redirect_uri}#access_token=eyJhbGciI6...&token_type=Bearer&expires_in=18000&id_token=eyJhbGciOiJS...&scope=openid%20profile%20email">here</a>.
</h2>
</body>
</html>
The below table shows the authorization response based on the response types:
"response_type" value | Flow | Tokens received at the "authorize" endpoint |
---|---|---|
id_token | Implicit | ID token only |
id_token token | Implicit Flow | ID token and access token |
Updated about 1 year ago