Passer au contenu principal

Aperçu

Concepts clés
  • Examinez les limites des clés de développeur d’Auth0.
Lorsque vous utilisez l’un des fournisseurs d’identité sociaux disponibles, vous devez enregistrer votre application auprès du approprié afin d’obtenir un et un .
Auth0 vous permet de tester un fournisseur d’identité social sans indiquer votre propre ID client ni votre propre Secret client en utilisant les clés de développeur Auth0. Cela vous permet d’activer et de tester rapidement un fournisseur d’identité social précis, mais cela ne doit pas être utilisé en production.
Les clés de développeur Auth0 ne sont pas disponibles dans les déploiements en nuage privé. Pour les environnements de production, assurez-vous de suivre les étapes pour le fournisseur que vous avez choisi afin d’obtenir l’ID client et le Secret client auprès du fournisseur et d’éviter les limitations associées à l’utilisation de clés de développeur. Pour savoir comment convertir des clés de développeur Google en clés de production, consultez cet Auth0 Developer Lab.

Clés de développeur personnalisées

Une ou plusieurs connexions utilisent les clés de développeur Auth0, qui sont destinées uniquement au développement et aux tests. Les connexions doivent être configurées avec vos propres clés de développeur afin que la page de consentement affiche votre logo au lieu de celui d’Auth0 et pour configurer l’authentification unique (SSO) pour ces connexions. Les clés de développeur Auth0 ne sont pas recommandées pour les environnements de production.

ID client et Secret client

La terminologie exacte pour l’ID client / le Secret client peut varier selon le fournisseur d’identité. Par exemple, X les désigne comme Consumer Key / Consumer Secret, et LinkedIn comme API Key / Secret Key.

Limites des clés de développeur

Les clés de développeur Auth0 sont destinées aux tests. Il y a donc quelques points à prendre en compte lorsque vous les utilisez. Selon que vous utilisez votre propre ID client et Secret client ou les clés de développeur Auth0, votre application peut se comporter différemment, voire certaines fonctionnalités peuvent ne pas fonctionner du tout. Lorsque vous utilisez les clés de développeur Auth0, le flux d’authentification des différents fournisseurs d’identité peut afficher à vos utilisateurs le nom, le logo et les renseignements d’Auth0. Lorsque vous enregistrez votre propre application, vous pouvez plutôt utiliser votre propre logo ainsi que les autres renseignements de l’application.
Écran de consentement

Limites des clés de développeur lors de l’utilisation de Universal Login

Si vous utilisez l’expérience Classic Login — et, dans certaines circonstances, l’expérience Universal Login — les limitations suivantes s’appliquent aussi :
  1. Vous ne pouvez pas utiliser de clés de développeur avec des domaines personnalisés.
  2. L’authentification unique (SSO) ne fonctionnera pas correctement lorsque vous utilisez les clés de développeur d’Auth0. En effet, les applications de développeur d’Auth0 associées à tous les fournisseurs d’identité pertinents sont configurées pour rediriger vers l’URL https://login.auth0.com/login/callback au lieu de l’URL de rappel de votre propre locataire, par exemple https://{yourDomain}/login/callback. Par conséquent, le cookie SSO n’est pas défini sur le domaine de votre locataire. La prochaine fois qu’un utilisateur s’authentifie, aucun cookie SSO ne sera donc détecté, même si vous avez configuré votre application pour utiliser Auth0 au lieu du fournisseur d’identité pour effectuer l’authentification unique (locataires hérités uniquement).
  3. La redirection des utilisateurs à partir de Rules ne fonctionnera pas correctement. En effet, les règles de redirection reprennent au point de terminaison https://{yourDomain}/continue. Lorsque vous utilisez les clés de développeur d’Auth0, la session est établie sur un point de terminaison spécial, générique et indépendant du locataire, et l’appel à /continue ne retrouvera pas votre session précédente, ce qui entraînera une erreur.
  4. La déconnexion fédérée ne fonctionne pas. Lorsque vous utilisez les clés de développeur d’Auth0, l’appel à /v2/logout?federated déconnecte l’utilisateur d’Auth0, mais pas du fournisseur d’identité social.
  5. prompt=none ne fonctionnera pas sur le point de terminaison /authorize. La méthode checkSession() de Auth0.js utilise prompt=none en interne, donc elle ne fonctionnera pas non plus.
  6. Si Auth0 agit comme fournisseur d’identité SAML et que vous utilisez une connexion sociale avec les clés de développeur d’Auth0, la réponse SAML générée comportera certaines erreurs, comme l’absence de l’attribut InResponseTo ou un élément AudienceRestriction vide.
  7. L’authentification multifacteur ne fonctionnera pas correctement. Lorsque l’authentification MFA réussit, une requête POST sera envoyée à https://{yourDomain}/mf. Lorsque vous utilisez les clés de développeur d’Auth0, la session est établie sur un point de terminaison spécial, générique et indépendant du locataire, et l’appel à /mf ne retrouvera pas votre session précédente, ce qui entraînera une erreur