Skip to main content
Auth0 est un fournisseur certifié OpenID Connect (OIDC). Dans le cadre des efforts d’Auth0 pour renforcer la sécurité et l’interopérabilité fondée sur des normes, nous déployons de nouvelles fonctionnalités exclusivement dans les flux d’authentification strictement conformes aux spécifications OIDC. Nous expliquerons les différences entre le pipeline conforme à OIDC et le pipeline hérité, et nous proposerons des pistes pour adapter vos applications existantes. Ces renseignements s’adressent aux développeurs et/ou aux administrateurs TI qui gèrent des intégrations Auth0 dans leurs applications à l’aide du framework d’autorisation OAuth 2.0. Cette information ne s’applique pas si vous utilisez ou WS-Federation. Tous les flux d’authentification sont décrits au moyen de requêtes HTTP plutôt qu’en fonction d’un langage ou de la mise en œuvre d’une bibliothèque en particulier. Toutes les nouvelles fonctionnalités ciblent uniquement le pipeline conforme à OIDC, et toutes les versions héritées de l’Auth0 SDK sont dépréciées, ne reçoivent pas de mises à jour pour les nouvelles fonctionnalités ni pour les problèmes de sécurité non critiques, et finiront par être abandonnées. De plus, toute la documentation, les bibliothèques et les exemples à l’extérieur de ce guide s’appliquent uniquement au pipeline conforme à OIDC. C’est pourquoi nous recommandons fortement d’adopter le pipeline conforme à OIDC, même si vous n’avez pas besoin d’exploiter de nouvelles fonctionnalités ou capacités dans l’immédiat.

​
Appliquer le pipeline conforme à OIDC

Selon l’ancienneté de votre tenant, vous pourriez disposer de différentes options pour appliquer le pipeline conforme à OIDC.

​
Nouveaux tenants

Si vous créez un nouveau tenant à l’aide du , le pipeline conforme à OIDC est utilisé par défaut. Il s’agit du paramètre par défaut du Dashboard depuis le début de 2019.
Il est toutefois possible que vous ayez désactivé manuellement le paramètre OIDC Conformant. Dans ce cas, vous devriez suivre nos instructions pour les anciens tenants.

​
Tenants plus anciens

Si vous souhaitez appliquer en même temps, pour une application donnée, toutes les modifications décrites dans ce guide afin de voir tous les changements non rétrocompatibles pendant la configuration plutôt qu’à l’exécution, vous devez :
  1. Accédez à Dashboard > Applications > Applications, puis sélectionnez l’application souhaitée.
  2. Faites défiler jusqu’à Advanced Settings, puis ouvrez l’onglet OAuth.
  3. Activez la bascule OIDC Conformant, puis cliquez sur Save Changes.
Si vous souhaitez utiliser le pipeline conforme à OIDC au cas par cas, pour chaque requête d’authentification, et que votre application doit envoyer une requête à une API avec un , lancez la requête vers le point de terminaison /social avec un paramètre audience. Si vous souhaitez utiliser le pipeline conforme à OIDC au cas par cas, pour chaque requête d’authentification, et que votre application n’a pas besoin d’envoyer une requête à une API, utilisez le paramètre audience suivant :

​
Différences

L’activation du pipeline conforme à OIDC entraîne les changements suivants dans le pipeline hérité.

​
APIs

Les applications et les API (ressources) doivent être définies comme des entités Auth0 distinctes. Pour en savoir plus, consultez OIDC-Conformant Adoption: APIs.

​
Jetons d’accès

  • Les API doivent être sécurisées à l’aide de jetons d’accès plutôt qu’avec des . Pour en savoir plus sur les différences, consultez Jetons.
  • Un ensemble défini de claims standard sur les utilisateurs peut être renvoyé dans les jetons ID ou dans la réponse de /userinfo.
  • Les claims personnalisés doivent respecter un format avec espace de noms. Pour en savoir plus, consultez Créer des claims personnalisés avec espace de noms.
  • Les réponses de /userinfo seront conformes à la spécification OIDC, à l’instar du contenu des jetons ID
  • Les scopes peuvent servir à demander soit des claims standard, soit des permissions d’API personnalisée.
Pour en savoir plus, consultez Adoption conforme à OIDC : jetons d’accès.

​
Flux d’autorisation

  • Flux du code d’autorisation : Il existe des différences structurelles dans la requête d’authentification, la réponse d’authentification, la requête d’échange de code, la réponse d’échange de code, la structure du jeton ID et la structure du jeton d’accès.
  • Flux d’identifiants du client : Nouveau flux activé, qui permet aux applications de s’authentifier elles-mêmes (plutôt qu’au nom d’un utilisateur) pour obtenir un accès à une API de façon programmatique et sécurisée.
  • Flux implicite : Il existe des différences structurelles dans la requête d’authentification, la réponse d’authentification, la structure du jeton ID et la structure du jeton d’accès. Plus précisément :
    • response_type=token renvoie uniquement un jeton d’accès. Pour obtenir un jeton ID, utilisez response_type=id_token ou response_type=token id_token.
    • Les jetons ID seront signés de façon asymétrique à l’aide de RS256.
    • Les requêtes d’authentification effectuées sans paramètre nonce seront rejetées. Pour en savoir plus, consultez Mitigate Replay Attacks When Using Implicit Flow.
    • Les jetons d’actualisation ne seront plus renvoyés lors de l’utilisation du flux implicite pour l’authentification.
  • Flux de mot de passe du propriétaire de la ressource : Il existe des différences structurelles dans la requête d’authentification, la réponse d’authentification, la structure du jeton ID et la structure du jeton d’accès. Plus précisément :

​
Delegation

  • Obsolète : point de terminaison /delegation, sauf lorsqu’il est utilisé pour obtenir des jetons d’API tiers.
  • Les applications conformes à OIDC ne peuvent être ni la source ni la cible de requêtes de délégation.
Pour en savoir plus, consultez Adoption de la conformité à OIDC : Delegation.

​
Points de terminaison

  • Obsolète : point de terminaison /tokeninfo
  • Désactivé : le point de terminaison /oauth/access_token (utilisé pour l’authentification sociale à partir d’applications mobiles natives).
  • Obsolète : point de terminaison /ssodata
  • Obsolète : point de terminaison /delegation, sauf lorsqu’il est utilisé pour obtenir des jetons d’API tierces.

​
Jetons d’actualisation

  • ne seront plus retournés lors de l’utilisation du Flux implicite pour l’authentification.
  • Les jetons d’actualisation peuvent être utilisés pour les applications confidentielles, mais la peut renforcer la sécurité dans la plupart des flux et devrait toujours être utilisée pour les applications publiques avec le Flux de code d’autorisation avec PKCE. Pour en savoir plus sur les applications confidentielles, consultez Applications confidentielles et publiques. Pour en savoir plus sur la rotation des jetons d’actualisation, consultez Refresh Token Rotation.
  • Pour obtenir de nouveaux jetons, vous devez utiliser le point de terminaison /oauth/token.
  • Le paramètre device n’est plus nécessaire pour demander un jeton d’actualisation à l’aide de la portée offline_access dans les requêtes d’authentification.
Pour en savoir plus, consultez Adoption de la conformité à OIDC : jetons d’actualisation.

​
Authentification unique (SSO)

  • Le ne peut être utilisé qu’à partir des pages de connexion Auth0, ce qui signifie que vous devez utiliser .
  • Pour déterminer si les utilisateurs sont connectés via SSO, vous devez utiliser l’authentification silencieuse. Pour en savoir plus, consultez Configurer l’authentification silencieuse.
  • Obsolète : le point de terminaison /ssodata et la méthode getSSOData() de Lock/auth0.js.
Pour en savoir plus, consultez Adoption conforme à OIDC : authentification unique.

​
Fonctionnalités supplémentaires

  • Créez des applications tierces pour vos API et affichez des boîtes de dialogue de consentement lors de l’autorisation. Pour en savoir plus, consultez User Consent and Third-Party Applications.
  • Restreignez les renseignements du profil utilisateur fournis aux applications lors de l’authentification. Pour en savoir plus, consultez Profils utilisateur.
  • Enregistrez dynamiquement des applications. Pour en savoir plus, consultez Dynamic Client Registration.
  • Organizations et les fonctionnalités qui s’y rapportent deviennent disponibles.