Skip to main content

Aperçu

Concepts clés
  • Consultez les limites des clés de développeur Auth0.
Lorsque vous utilisez l’un des fournisseurs d’identité sociale disponibles, vous devez enregistrer votre application auprès du concerné afin d’obtenir un et un .
Auth0 vous permet de tester un fournisseur d’identité sociale sans indiquer votre propre Client ID ni votre propre Client Secret en utilisant les clés de développeur Auth0. Vous pouvez ainsi activer et tester rapidement un fournisseur d’identité sociale donné, mais cela ne doit pas être utilisé en production.
Les clés de développeur Auth0 ne sont pas offertes dans les déploiements Private Cloud. Pour les environnements de production, assurez-vous de suivre les étapes correspondant au fournisseur choisi afin d’obtenir le Client ID et le Client Secret auprès du fournisseur et d’éviter les limitations liées à l’utilisation des 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 des 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 pour 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.

Client ID et Client Secret

La terminologie exacte de Client ID / Client Secret peut varier d’un fournisseur d’identité à l’autre. Par exemple, X les désigne par Consumer Key / Consumer Secret, et LinkedIn par API Key / Secret Key.

Limites des clés de développeur

Les clés de développeur Auth0 sont strictement destinées aux tests. Les utiliser à la place de votre propre Client ID et Client Secret peut entraîner des comportements inattendus, des fonctionnalités limitées ou des erreurs d’application. 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 d’autres renseignements sur l’application.
Écran de consentement

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

Si vous utilisez l’expérience Classic Login ou l’expérience Universal Login, les limitations suivantes s’appliquent :
  1. Vous ne pouvez pas utiliser de clés de développeur avec les domaines personnalisés.
  2. L’authentification unique ne fonctionnera pas correctement si vous utilisez les clés de développeur Auth0. Les applications de développeur Auth0 sont configurées pour rediriger vers l’URL https://login.auth0.com/login/callback au lieu de l’URL de rappel de votre propre tenant, par exemple https://YOUR_AUTH0_DOMAIN/login/callback. Par conséquent, le cookie SSO n’est pas défini sur le domaine de votre tenant. Ainsi, la prochaine fois qu’un utilisateur s’authentifie, aucun cookie SSO ne sera détecté, même si vous avez configuré votre application pour Use Auth0 instead of the Identity Provider to do Single Sign-on (tenants Legacy uniquement).
  3. La redirection des utilisateurs avec Actions ne fonctionnera pas correctement. Les Redirect Actions reprennent au point de terminaison https://YOUR_AUTH0_DOMAIN/continue. Lors de l’utilisation des clés de développeur d’Auth0, la session est établie sur un point de terminaison spécial qui est générique et indépendant du tenant, et l’appel à /continue ne retrouvera pas votre session précédente, ce qui entraînera une erreur.
  4. Le Federated Logout ne fonctionne pas. Lors de l’utilisation des clés de développeur d’Auth0, l’appel à /v2/logout?federated déconnectera 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() d’Auth0.js utilise prompt=none en interne, donc cela 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 Auth0, la réponse SAML générée comportera des erreurs, comme un attribut InResponseTo manquant ou un élément AudienceRestriction vide.
  7. La Multi-Factor Authentication ne fonctionnera pas correctement. Lorsque l’authentification MFA réussit, une requête POST est envoyée à https://YOUR_AUTH0_DOMAIN/mf. Lors de l’utilisation des clés de développeur d’Auth0, la session est établie sur un point de terminaison spécial qui est générique et indépendant du tenant, et l’appel à /mf ne retrouvera pas votre session précédente, ce qui entraînera une erreur.