Passer au contenu principal
Auth0 est un fournisseur OpenID Connect (OIDC) certifié. Dans le cadre des efforts d’Auth0 pour améliorer la sécurité et l’interopérabilité fondée sur les normes, nous déployons de nouvelles fonctionnalités exclusivement dans les flux d’authentification qui respectent strictement les spécifications OIDC. Nous expliquerons les différences entre le pipeline conforme à OIDC et le pipeline hérité, et nous proposerons des suggestions 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 cadre d’autorisation OAuth 2.0. Ces renseignements ne s’appliquent pas si vous utilisez ou WS-Federation. Tous les flux d’authentification sont décrits au moyen de requêtes HTTP plutôt que dans le contexte d’un langage ou d’une bibliothèque en particulier. Toutes les nouvelles fonctionnalités visent uniquement le pipeline conforme à OIDC, et toutes les anciennes versions des SDK Auth0 sont obsolètes, ne reçoivent plus de mises à jour pour les nouvelles fonctionnalités ni pour les problèmes de sécurité non critiques, et seront éventuellement abandonnées. De plus, toute la documentation, les bibliothèques et les exemples en dehors de ce guide s’appliquent uniquement au pipeline conforme à OIDC. Pour cette raison, nous recommandons fortement d’adopter le pipeline conforme à OIDC, même si vous n’avez pas besoin de tirer parti de nouvelles fonctionnalités dans l’immédiat.

​
Appliquer le pipeline conforme à OIDC

Selon la date de création de votre locataire, différentes options peuvent s’offrir à vous pour appliquer le pipeline conforme à OIDC.

​
Nouveaux locataires

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

​
Locataires plus anciens

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

​
Différences

L’activation du pipeline conforme à OIDC entraîne les changements suivants par rapport au pipeline hérité.

​
API

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

​
Jetons d’accès

  • Les API doivent être sécurisées au moyen de jetons d’accès plutôt qu’avec des . Pour en savoir plus sur les différences, consultez Tokens.
  • Un ensemble défini de claims standard concernant les utilisateurs peut être renvoyé dans les ID Tokens ou dans la réponse de /userinfo.
  • Les claims personnalisés doivent respecter un format avec espace de noms. Pour en savoir plus, consultez Create Namespaced Custom Claims.
  • Les réponses de /userinfo seront conformes à la spécification OIDC, tout comme le contenu des jetons d’identité
  • Les scopes peuvent être utilisés pour demander soit des claims standard, soit des autorisations d’API personnalisées.
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 d’identité et la structure du jeton d’accès.
  • Flux des informations d’identification de l’application : Nouveau flux activé, qui permet aux applications de s’authentifier en leur propre nom (plutôt qu’au nom d’un utilisateur) afin d’obtenir un accès sécurisé à une API par programmation.
  • Flux implicite : Il existe des différences structurelles dans la requête d’authentification, la réponse d’authentification, la structure du jeton d’identité et la structure du jeton d’accès. Plus précisément :
    • response_type=token retourne uniquement un jeton d’accès. Pour obtenir un jeton d’identité, utilisez response_type=id_token ou response_type=token id_token.
    • Les jetons d’identité seront signés de manière asymétrique avec RS256.
    • Les requêtes d’authentification effectuées sans le paramètre nonce seront rejetées. Pour en savoir plus, consultez Atténuer les attaques par rejeu lors de l’utilisation du flux implicite.
    • Les jetons d’actualisation ne seront plus renvoyés lors de l’utilisation du flux implicite pour l’authentification.
  • Flux du 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 d’identité et la structure du jeton d’accès. Plus précisément :

​
Délégation

  • Obsolète : le point de terminaison /delegation, sauf lorsqu’il est utilisé pour obtenir des jetons pour des API tierces.
  • Les applications conformes à OIDC ne peuvent pas servir de source ni de cible pour les demandes de délégation.
Pour en savoir plus, consultez Adoption conforme à OIDC : délégation.

​
Points de terminaison

  • Obsolète : le 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 : le point de terminaison /ssodata
  • Obsolète : le point de terminaison /delegation, sauf lorsqu’il est utilisé pour obtenir des jetons d’API tiers.

​
Jetons d’actualisation

  • ne seront plus renvoyé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 avec les applications publiques lorsque vous utilisez le flux du code d’autorisation avec PKCE. Pour en savoir plus sur les applications confidentielles, consultez Confidential and Public Applications. 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 du scope offline_access dans les requêtes d’authentification.
Pour en savoir plus, consultez OIDC-Conformation Adoption: Refresh Tokens.

​
Authentification unique (SSO)

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

​
Fonctionnalités supplémentaires