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...&amp;token_type=Bearer&amp;expires_in=18000&amp;id_token=eyJhbGciOiJS...&amp;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