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:
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.
response_type=tokenwill only return an Access Token, not an ID Token. Use
- 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
nonceparameter will be rejected.
- Refresh Tokens must be used at the token endpoint instead of /delegation.
deviceparameter, 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.
scopeparameter 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
- Calling your APIs with Auth0 tokens
- User consent and third-party applications
- Custom user profile claims and
- Single sign-on (SSO)
- Initiating authentication flows:
- Refresh Tokens
- Passwordless authentication
- List of breaking changes for OIDC-conformant applications