Docs

OIDC-conformant Implicit grant

Adoption Guide

This document is part of the adoption guide for OIDC-conformant authentication. If you haven't already, we strongly suggest reading the introduction before reading this document.

The Implicit grant is used by applications that are incapable of securely storing secrets, such as single-page JavaScript applications. This document describes the differences of this flow between the legacy and OIDC-conformant authentication pipelines.

Authentication request

  • This response_type parameter 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.
  • favorite_color is no longer a valid scope.
  • The audience parameter is optional.
  • The nonce parameter must be a cryptographically-secure random string.

Authentication response

  • 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.
  • 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

Access Token structure (optional)

  • 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.
  • Note that an opaque Access Token could still be returned if /userinfo is the only specified audience.

Further reading