Implicit Flow

Implicit Flow

tutorials

Using the OAuth 2 Implicit Flow

An app that needs access to an OAuth-protected back-end API on behalf of a user must obtain an Access Token. If the app can not keep a secret (i.e., it is deployed in an environment where users have access to its protected storage or communications), there is no added security in authenticating the app to the token endpoint as in the code flow. The Implicit Flow was specified exactly for this case, where the user is authenticated by the Authorization Server, and an Access Token is returned to the app directly in the fragment of a redirect URL.

Pre-requisites

{!tutorials/pre-requisites.md!}

Overview

{!oauth2/flows/implicit-flow-diagram.md!}

Because the app is not capable of keeping a secret, there is no long-lived, Refresh Token issued in this flow. Also, the issued Access Token should have a limited lifetime. Because an Access Token is returned in the fragment of the URI, it should not be cached or stored by intermediate systems or proxies. The security of the process relies on this property, as an Access Token should not be exposed to any party except the app.

For reference, the Implicit Flow is documented in section 4.2 of the OAuth 2.0 Specification.

To learn more about the client parameters of the Implicit flow see OAuth Implicit Flow.

Setup in Curity

Visit the Profiles screen and click the Token Service. On the right select Clients and click New.

New Client

Give the client an ID (eg. spa for a single page website client).

New Client

Capabilities

{!oauth2/flows/config-capabilities.md!}

Select the Implicit Flow capability and click Next.

Code Flow

Redirect URL

{!oauth2/flows/config-redirect-url.md!}

User Authentication

{!oauth2/flows/config-user-authentication.md!}

Add the openid Scope

{!oauth2/flows/config-openid-scope.md!}

Commit

Make sure to remember to commit the changes in the Changes -> Commit menu.


Making Requests with the Client

With the default configuration we’ve setup, the server’s authorization endpoint is at https://localhost:8443/oauth/v2/oauth-authorize. If you are not using that configuration, determine the URL of your authorization endpoint, and adjust the following requests accordingly. To use the implicit flow, an app would create a URL to this endpoint, and redirect the user to it. The URL looks like this:

https://localhost:8443/oauth/v2/oauth-authorize?client_id=spa&response_type=token

You can pretend to be the app, and enter this URL in a browser yourself. As a result, you will be asked to authenticate, after which Curity will redirect you back to the app by adding the token response parameters to the configured redirect URI, e.g.:

https://localhost/callback#access_token=e161b107-7110-421f-b449-940659ab58c1&token_type=bearer&expires_in=300

In case you want to request an ID Token as well, it turns into an OpenID Connect request, and for that you will need to include the redirect_uri and nonce parameters in the request:

https://localhost:8443/oauth/v2/oauth-authorize?client_id=spa&redirect_uri=https://localhost/callback&response_type=id_token&scope=openid&nonce=538B0D2A-545A-4113-ACD7-A2C3D315C605

After doing so, you should receive an ID token on the fragment of the callback URI.

If the app needs an ID token and an access token, the response_type request parameter should include both id_token and token, like this:

https://localhost:8443/oauth/v2/oauth-authorize?client_id=spa&redirect_uri=https://localhost/callback&response_type=id_token+token&scope=openid&nonce=538B0D2A-545A-4113-ACD7-A2C3D315C607

Let’s Stay in Touch!

Get the latest on identity management, API Security and authentication straight to your inbox.

Keep up with our latest articles and how-tos using RSS feeds