Adopter l’authentification conforme à OIDC

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é basée sur des normes, nous déployons de nouvelles fonctionnalités exclusivement sur les flux d’authentification strictement conformes aux spécifications d’OIDC.

Nous expliquerons les différences entre les pipelines conformes à OIDC et ceux plus anciens, et nous vous proposerons des suggestions sur la manière d’adapter vos applications existantes. Si vous êtes un développeur et/ou un administrateur qui gère les intégrations Auth0 dans vos applications à l’aide du Cadre d’applications Authorization OAuth 2.0, ces informations ne s’appliquent pas si vous utilisez SAML ou WS-Federation. Tous les flux d’authentification sont décrits via des requêtes HTTP plutôt que dans le contexte d’une implémentation de langage ou de bibliothèque particulière.

Toutes les nouvelles fonctionnalités visent uniquement le pipeline conforme à OIDC, et toutes les anciennes versions de la trousse SDK Auth0 sont obsolètes; elles ne reçoivent pas de mises à jour pour les nouvelles fonctionnalités ou les problèmes de sécurité non critiques, et elles seront finalement 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 vous recommandons fortement d’adopter le pipeline conforme à OIDC, même si vous n’avez pas besoin d’exploiter de nouvelles fonctionnalités dans un avenir immédiat.

En fonction de la date de création de votre locataire, vous pouvez disposer de différentes options pour appliquer le pipeline conforme à OIDC.

Si vous créez un nouveau locataire à l’aide du Auth0 Dashboard, le pipeline conforme à OIDC est utilisé par défaut. Il s’agit d’un paramètre par défaut pour le Dashboard depuis début 2019.

Si vous souhaitez forcer toutes les modifications décrites dans ce guide en même temps pour une application donnée afin de pouvoir rencontrer toutes les modifications importantes lors de la configuration plutôt que lors de l’exécution, vous devez :

1. Allez à Dashboard > Applications > Applications et sélectionnez l’application souhaitée.

2. Défilez jusqu’à Advanced Settings (Réglages avancés) et ensuite jusqu’à l’onglet OAuth.

3. Activez le commutateur OIDC Conformant (Conforme à OIDC) et cliquez sur Save Changes (Enregistrer les modifications).

Si vous souhaitez utiliser le pipeline conforme à OIDC sur la base d’une demande d’authentification par demande et que votre application doit appeler une API avec un jeton d’accès JWT, lancez la demande au point de terminaison /social avec un paramètre audience.

Si vous souhaitez utiliser le pipeline conforme à OIDC pour chaque requête d’authentification et que votre application n’a pas besoin d’appeler une API, utilisez le paramètre audience suivant :

https://{yourDomain}/userinfo

L’activation du pipeline conforme à OIDC entraîne les modifications suivantes dans le pipeline existant.

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

• Toutes les API doivent être sécurisées avec des jetons d’accès plutôt que des jetons d’ID. Pour en savoir plus sur les différences, lisez Jetons.

• Un ensemble défini de demandes standard concernant les utilisateurs peut être renvoyé dans les jetons d’ID ou dans la réponse de /userinfo.

• Les demandes personnalisées doivent être conformes à un format nommé. Pour en savoir plus, veuillez consulter Créer des demandes personnalisées avec espace de noms.

• Les réponses de /userinfo seront conformes à la spécification OIDC, similaire au contenu des jetons d’ID

• Les permissions peuvent être utilisées pour effectuer des demandes standard ou demander des autorisations API personnalisées.

Pour en savoir plus, lisez Adoptions conformes à OIDC : Jetons d’accès.

• Flux de code d’autorisation : des différences structurelles existent dans la demande d’authentification, la réponse d’authentification, la demande d’échange de code, la réponse d’échange de code, la structure du jeton d’ID et la structure du jeton d’accès.

• Flux des identifiants client : nouveau flux activé, qui permet aux applications de s’authentifier elles-mêmes (plutôt que pour le compte d’un utilisateur) afin d’obtenir l’accès à une API de manière programmatique et sécurisée.

• Flux implicite : des différences structurelles existent dans la demande d’authentification, la réponse d’authentification, la structure du jeton d’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 d’ID, utilisez response_type=id_token ou response_type=token id_token.

  • Les jetons d’ID seront signés de manière asymétrique en utilisant RS256.

  • Les demandes d’authentification effectuées sans paramètre « nombre aléatoire » seront rejetées. Pour en savoir plus, consultez Atténuer les attaques par réinsertion 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 de mot de passe du propriétaire de ressource : des différences structurelles existent dans la demande d’authentification, la réponse d’authentification, la structure du jeton d’ID et la structure du jeton d’accès. Plus précisément :

  • le point de terminaison du propriétaire de la ressource héritée est désactivé, ce qui désactive également l’authentification sans mot de passe pour la connexion intégrée à partir de ce point de terminaison. Pour mettre en oeuvre l’option sans mot de passe avec une connexion intégrée, vous devez utiliser l’API intégrée sans mot de passe ou nos trousses SDK, selon le type de votre application.

  • le paramètre device est maintenant considéré comme étant invalide si vous demandez un jeton d’actualisation à l’aide de la permission offline_access.

• Déconseillé : point de terminaison /delegation, sauf lorsqu’il est utilisé pour obtenir des jetons API tiers.

• Les applications conformes à l’OIDC ne peuvent pas être la source ou la cible de demandes de délégation.

Pour en savoir plus, lisez Adoption conforme à OIDC : Délégation.

• Déconseillé : point de terminaison /tokeninfo

• Désactivé: le point de terminaison /oauth/access_token (utilisé pour l’authentification sociale à partir d’applications mobiles natives).

• Déconseillé : Point de terminaison /ssodata

• Déconseillé : Point de terminaison /delegation sauf lorsqu’il est utilisé pour obtenir des jetons API tiers.

• Les 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 rotation de ces derniers peut augmenter la sécurité pour la plupart des flux; ils doivent toujours être utilisés pour les applications publiques lors de l’utilisation du flux de code d’autorisation avec PKCE. Pour en savoir plus sur les demandes confidentielles, lisez Applications confidentielles et publiques. Pour en savoir plus sur la rotation des jetons d’actualisation, lisez Rotation des jetons d’actualisation.

• Lorsque vous obtenez de nouveaux jetons, vous devez utiliser le point de terminaison /oauth/token.

• Le paramètre device n’est plus nécessaire lors de la requête d’un jeton d’actualisation à l’aide de la permission offline_access dans les requêtes d’authentification.

Pour en savoir plus, lisez Adoption conformes à OIDC : Jetons d’actualisation.

• L’authentification unique (SSO) ne peut être effectuée qu’à partir des pages de connexion Auth0, ce qui signifie que vous devez utiliser la connexion universelle.

• Pour déterminer si les utilisateurs sont connectés par le biais de la SSO, vous devez utiliser l’authentification silencieuse. Pour en savoir plus, lisez Configurer l’authentification silencieuse.

• Déconseillé : Point de terminaison /ssodata et méthode getSSOData() de Lock/auth0.js.

Pour en savoir plus, lisez Adoption conforme à OIDC : Authentification unique.

• Créez des applications tierces pour vos API et affichez des boîtes de dialogue de consentement pour l’autorisation. Pour en savoir plus, lisez Consentement pour l’autorisation et tierce parties.

• Restreint les informations de profil utilisateur fournies aux applications lors de l’authentification. Pour en savoir plus, consultez Profils utilisateurs.

• Enregistre dynamiquement les applications. Pour en savoir plus, consultez Enregistrement dynamique des clients.

• Les Organization et leurs fonctionnalités associées deviennent disponibles.