Implicit Flow with OIDC

Learn how the OIDC-conformant pipeline affects the Implicit Flow.

Traditionally, the Implicit Flow was used by applications that were incapable of securely storing secrets. Using this flow is no longer considered a best practice for requesting access tokens; new implementations should use Authorization Code Flow with PKCE. However, when used with Form Post response mode, Implicit Flow does offer a streamlined workflow if the application needs only an ID token to perform user authentication; in these cases, it would be used as part of the Hybrid Flow.

Refresh tokens will no longer be returned when using the Implicit Flow for authentication.

In addition, the OIDC-conformant pipeline affects the Implicit Flow in the following areas: authentication request, authentication response, ID token structure, and access token structure.

Authentication request

Legacy

GET /authorize?
    response_type=token
    &scope=openid email favorite_color offline_access
    &client_id=123
    &state=af0ifjsldkj
    &redirect_uri=https://app.example.com
    &device=my-device-name

The device parameter is only needed if requesting a refresh token by passing the offline_access scope. To learn more, read Refresh Tokens.

OIDC-conformant

GET /authorize?
    response_type=token id_token
    &scope=openid email
    &client_id=123
    &state=af0ifjsldkj
    &nonce=jxdlsjfi0fa
    &redirect_uri=https://app.example.com
    &audience=https://api.example.com

• response_type indicates that we want to receive both an access token and ID token.
• Refresh tokens are not allowed in the implicit grant. Use prompt=none instead. To learn more read Configure Silent Authentication.
• favorite_color is no longer a valid scope.
• audience is optional.
• nonce must be a cryptographically secure random string. To learn more, read Mitigate Replay Attacks When Using the Implicit Flow.

Authentication response

Legacy

HTTP/1.1 302 Found
Location: https://app.example.com/#
    access_token=SlAV32hkKG
    &expires_in=86400
    &state=af0ifjsldk
    &id_token=eyJ...
    &refresh_token=8xLOxBtZp8
    &token_type=Bearer

• The returned access token is valid for calling the /userinfo endpoint.
• A refresh token will be returned only if a device parameter was passed and the offline_access scope was requested.

OIDC-conformant

HTTP/1.1 302 Found
Location: https://app.example.com/#
    access_token=eyJ...
    &expires_in=86400
    &state=af0ifjsldk
    &id_token=eyJ...
    &token_type=Bearer

• The returned access token is valid for calling the /userinfo endpoint (provided that the API specified by the audience param uses RS256 as signing algorithm) and optionally the resource server specified by the audience parameter.
• If using response_type=id_token, Auth0 will only return an ID token. Refresh Tokens are not allowed in the implicit grant. Use prompt=none instead.

ID token structure

Legacy

OIDC-conformant

• The favorite_color claim must be namespaced and added through a rule. To learn more, read Create Namespaced Custom Claims.
• After validating the ID token, the application must validate the nonce to mitigate replay attacks.

Access token structure (optional)

Legacy

HTTP

SlAV32hkKG

The returned Access Token is opaque and only valid for calling the /userinfo endpoint.

OIDC-conformant

• The returned access token is a JWT valid for calling the /userinfo endpoint (provided that the API specified by the audience param uses RS256 as signing algorithm) as well as the resource server specified by the audience parameter.
• An opaque access token could still be returned if /userinfo is the only specified audience.

Learn more

• Access Tokens with OIDC
• External APIs with OIDC
• Authorization Code Flow with OIDC
• Client Credentials Flow with OIDC
• Delegation with OIDC
• Refresh Tokens with OIDC