OIDC-conformant applications

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.

In order to make the transition to the OIDC-conformant authentication pipeline more predictable, applications now include an option called "OIDC Conformant", available under Advanced Settings > OAuth:

OIDC-conformant application setting

The objective of this flag is to disable as many legacy features as possible, so you can run into the OIDC-conformant pipeline's breaking changes at configuration time rather than run time. Enabling this flag on an application will have the following effects:

  • The following features are deprecated in favor of silent authentication:
    • Refresh Tokens on authentication with the implicit grant
    • /ssodata endpoint and getSSOData() method from Lock/auth0.js
  • Single Sign-on (SSO) can only be performed from Auth0 login pages.
  • Using response_type=token will only return an Access Token, not an ID Token. Use response_type=id_token or response_type=token id_token instead.
  • ID Tokens obtained with the implicit grant will be signed asymmetrically using RS256.
  • The /tokeninfo endpoint is disabled.
  • Responses from /userinfo will conform to the OIDC specification, similar to the contents of ID Tokens
  • Implicit grant authentication requests made without a nonce parameter will be rejected.
  • Refresh Tokens must be used at the token endpoint instead of /delegation.
  • The device parameter, originally used to obtain Refresh Tokens, is now considered invalid.
  • The legacy resource owner endpoint is disabled.
    • Passwordless authentication for embedded login is implemented at this endpoint, so it will be disabled as well.
  • The /oauth/access_token endpoint, used for social authentication from native mobile applications, is disabled. An OIDC-conformant alternative will be added in future releases.
  • The scope parameter of authentication requests will comply to the OIDC specification:
    • Custom claims must be namespaced and added to ID Tokens or Access Tokens via rules.
    • The namespace identifiers for custom claims must be HTTP or HTTPS URIs.
    • Custom scope values can be defined by a resource server (API).
  • OIDC-conformant applications cannot be the source or target application of a delegation request.

I don't want to make all these changes at once!

The "OIDC Conformant" flag will force all of these changes at the same time for a given application, but it's not the only option to gradually transition to the OIDC-conformant authentication pipeline. Any authentication requests made with an audience parameter will use the new pipeline, and all other requests will continue to work as usual.

If your application doesn't need a resource server but you want opt-in to the new pipeline on a per-request basis, you can use the following audience parameter:


Further reading