Skip to main content
L’Échange de jetons personnalisé permet aux applications d’échanger leurs jetons existants contre des jetons Auth0 lors d’une requête au point de terminaison /oauth/token, comme défini dans la RFC 8693. Parmi les cas d’utilisation courants de l’Échange de jetons personnalisé, on retrouve les suivants :
  • Obtenir des jetons Auth0 pour une autre
  • Intégrer un externe
  • Migrer vers Auth0
  • Autorisation déléguée : un principal (comme un service, un agent IA ou un agent de soutien) agit au nom d’un utilisateur
Pour en savoir plus, consultez Exemples de cas d’utilisation et échantillons de code.
Si vous n’avez pas d’exigences de validation de jetons personnalisée et que vous devez seulement propager le contexte de délégation entre vos propres services, utilisez plutôt l’Échange de jetons On-Behalf-Of. Il n’exécute pas d’Action personnalisée par requête et prend en charge un débit considérablement plus élevé. Utilisez l’Échange de jetons personnalisé lorsque vous devez valider des subject tokens ou jetons d’acteur dans un format personnalisé, intégrer un fournisseur d’identité externe ou que vous avez autrement besoin d’un contrôle complet sur la logique d’échange.
Chaque requête d’Échange de jetons personnalisé correspond à un profil d’Échange de jetons personnalisé régi par une Action, où vous pouvez :
  • Écrire du code personnalisé pour décoder et valider les subject_tokens transmis au point de terminaison /oauth/token
  • Autoriser l’accès et définir l’utilisateur associé à la transaction.
Vous pouvez configurer plusieurs profils d’Échange de jetons personnalisé pour une application. Une fois que l’Auth0 Authorization Server a validé que la requête d’Échange de jetons personnalisé est valide et correspond à un profil d’Échange de jetons personnalisé existant, le déclencheur d’Échange de jetons personnalisé exécute l’unique Action associée à ce profil. L’application peut ensuite tirer parti de l’Échange de jetons personnalisé pour authentifier l’utilisateur et obtenir pour celui-ci des jetons Auth0 d’accès, d’ID et d’actualisation.
L’Échange de jetons personnalisé vous offre une souplesse accrue pour définir l’utilisateur associé à la transaction, en contrepartie de la responsabilité supplémentaire de valider de façon sécuritaire le subject token correspondant qui identifie l’utilisateur pour la transaction.Gardez à l’esprit que les subject tokens et jetons d’acteur utilisés avec l’Échange de jetons personnalisé peuvent prendre n’importe quel format ou type de jeton, tant que le code de votre Action peut les interpréter. Vous devez mettre en œuvre une validation robuste des jetons que vous recevez et acceptez. Si vous ne le faites pas, vous vous exposez à différents vecteurs d’attaque, comme l’usurpation ou les attaques par rejeu, ce qui pourrait permettre à des acteurs malveillants de s’authentifier avec l’ID utilisateur de quelqu’un d’autre ou d’agir en son nom de manière non autorisée.Pour en savoir plus sur les différentes options permettant de mettre en œuvre une validation sécuritaire de vos subject tokens, consultez et appliquez les recommandations incluses dans Exemples de cas d’utilisation et échantillons de code. Assurez-vous également de tenir compte des fonctionnalités de Protection contre les attaques et de les appliquer.

​
Logs du tenant

Chaque transaction d’Échange de jetons personnalisé génère un log d’événement du tenant :
  • Transactions réussies : logs secte
  • Transactions Failed : logs fecte
Lorsqu’un acteur est défini au moyen de setActor(), la propriété actor (contenant sub et tout actor imbriqué) est incluse dans les entrées de log secte à des fins d’audit. Utilisez les logs du tenant pour vous aider à résoudre les problèmes rencontrés lors de votre échange de jeton.

​
Limitations

L’Échange de jetons personnalisé ne prend pas en charge les éléments suivants :
  • les méthodes de la MFA API api.authentication.challengeWith() et api.authentication.EnrollWith()
  • les connexions de base de données personnalisées avec le mode d’importation ON ne sont pas prises en charge pour les opérations setUserByConnection()
  • les clients tiers et non conformes à OIDC
  • l’API cible doit avoir l’option Autoriser l’omission du consentement de l’utilisateur activée, puisqu’il n’est pas possible de recueillir le consentement dans un flux non interactif.