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 ; 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 to perform user authentication; in these cases, it would be used as part of the Hybrid Flow. 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 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

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

​
OIDC-conformant

JSON
{
    "sub": "auth0|alice",
    "iss": "https://{yourDomain}/",
    "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 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

JSON
{
    "sub": "auth0|alice",
    "iss": "https://{yourDomain}/",
    "aud": [
        "https://api.example.com",
        "https://{yourDomain}/userinfo"
    ],
    "azp": "123",
    "exp": 1482816809,
    "iat": 1482809609,
    "scope": "openid email"
}
  • The returned access token is a 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 .

​
Learn more