Implicit Flow with OIDC

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

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

{
    "sub": "auth0|alice",
    "iss": "https://YOUR_DOMAIN/",
    "aud": "123",
    "exp": 1482809609,
    "iat": 1482773609,
    "email": "alice@example.com",
    "email_verified": true,
    "favorite_color": "blue"
}

OIDC-conformant

{
    "sub": "auth0|alice",
    "iss": "https://YOUR_DOMAIN/",
    "aud": "123",
    "exp": 1482809609,
    "iat": 1482773609,
    "email": "alice@example.com",
    "email_verified": true,
    "https://app.example.com/favorite_color": "blue",
    "nonce": "jxdlsjfi0fa"
}

  • 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

SlAV32hkKG

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

OIDC-conformant

{
    "sub": "auth0|alice",
    "iss": "https://YOUR_DOMAIN/",
    "aud": [
        "https://api.example.com",
        "https://YOUR_DOMAIN/userinfo"
    ],
    "azp": "123",
    "exp": 1482816809,
    "iat": 1482809609,
    "scope": "openid email"
}

  • 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