Les multiples visages du Token Exchange d’OAuth 2.0

• Un mécanisme standardisé permettant de convertir un jeton de sécurité en un autre, défini par la spécification d’extension OAuth 2.0 RFC 8693
• Transforme le serveur d’autorisation en Security Token Service (STS), qui valide le jeton envoyé par le client et émet un nouveau jeton adapté à un autre contexte, audience ou objectif
• Son fonctionnement se divise globalement en deux modes : impersonation et delegation
• Chaque cas d’usage — impersonation administrateur, transition de protocole, chaînage de services, identité fédérée, etc. — implique ses propres compromis et impacts de sécurité
• Avec la généralisation des agents IA, les tâches qui traversent plusieurs services et fournisseurs deviennent par nature des chaînes de délégation, ce qui renforce encore l’importance du token exchange

---

Qu’est-ce que le Token Exchange ?

• Le client envoie un subject_token (un jeton représentant l’utilisateur ou l’entité à l’origine de la requête) et, éventuellement, un actor_token (la partie qui effectue l’échange), puis reçoit un nouveau jeton adapté au contexte cible
• Transmettre le jeton existant tel quel ou créer un nouveau jeton peut sembler intuitif, mais ces deux approches provoquent de sérieux problèmes ; cette spécification a été conçue pour les résoudre

• Deux modes de fonctionnement de base

  • Impersonation : la partie qui fait la requête reçoit un jeton impossible à distinguer de celui du sujet d’origine ; le service downstream ne peut pas savoir s’il s’agit du vrai utilisateur ou d’un acteur qui l’imite
  • Delegation : l’identité des deux parties est préservée ; grâce à la claim act (actor) incluse dans le nouveau jeton, le service downstream peut identifier à la fois l’utilisateur et le mandataire
  • L’impersonation est puissante mais opaque, la delegation est plus contrainte mais auditable : ce choix détermine la posture de sécurité et la capacité de traçabilité

Impersonation administrateur (Administrative Impersonation)

• Pour diagnostiquer un problème d’affichage de données erronées dans le tableau de bord d’un client, un ingénieur support peut avoir besoin de voir exactement le même écran, avec les mêmes droits et le même accès aux données que le client
• L’administrateur échange son propre jeton contre un jeton représentant l’identité du client ; le jeton résultant contient les claims sub, les scopes et l’audience du client, si bien que l’application l’interprète comme une requête envoyée par ce client
• Dans ce cas, la requête n’utilise que le subject_token (l’utilisateur à impersonate) sans actor_token, car l’objectif est une impersonation complète

• Le problème de la perte de piste d’audit

  • Comme il s’agit d’une véritable impersonation, la piste d’audit indiquant qui a réellement effectué l’action disparaît
  • Il faut donc impérativement l’accompagner d’un mécanisme de logging externe enregistrant qui, quand et pour quelle raison l’échange a été déclenché, faute de quoi la résolution d’incident peut créer une faille de sécurité

Gérer la transition de protocole (Managing Protocol Transition)

• Dans un environnement où subsistent des systèmes legacy et d’anciens protocoles, on peut avoir un scénario de coexistence lors d’une migration de l’authentification SAML vers OpenID Connect (OIDC)
• Un service qui authentifie l’utilisateur avec SAML échange une assertion SAML contre un access token OAuth 2.0 ; le serveur d’autorisation valide l’artefact SAML reçu et émet un access token standard compris par les services downstream

• Le paramètre subject_token_type

  • Il identifie le format du jeton entrant ; la RFC 8693 définit plusieurs identifiants de types de jetons
    • Assertion SAML 2.0 : urn:ietf:params:oauth:token-type:saml2
    • Jeton JWT : urn:ietf:params:oauth:token-type:jwt
  • Le serveur d’autorisation peut ainsi accepter des jetons issus de différentes familles de protocoles et les normaliser dans un format cohérent pour les services modernes
• C’est un pattern qui apparaît lorsque, par exemple après une fusion-acquisition, deux organisations dotées de piles d’identité différentes doivent interopérer avant une migration complète : l’utilisateur continue à s’authentifier comme avant, et le système convertit les credentials dans le format requis par le service consommateur

Chaînage d’appels de services (Chaining Service Calls)

• Dans une architecture microservices, lorsqu’un Service A traite une requête utilisateur puis doit appeler Service B au nom de l’utilisateur, avant que Service B n’appelle à son tour Service C, la question clé devient : quels credentials chaque service doit-il utiliser pour l’appel suivant ?

• Option 1 — utiliser les propres credentials du service

  • Service A ignore le contexte utilisateur et appelle Service B avec ses propres client credentials ; cette approche convient aux appels interservices où le contexte utilisateur n’est pas nécessaire, comme les traitements batch, les contrôles d’état système ou la synchronisation de données
  • Mais lorsqu’un utilisateur est concerné, Service B ne peut pas faire respecter une autorisation au niveau utilisateur : il ne sait pas quel utilisateur est à l’origine de la requête et ne peut donc pas vérifier les droits d’accès, ce qui entraîne une perte du contexte de sécurité

• Option 2 — le service impersonate l’utilisateur

  • Service A transmet le jeton d’origine de l’utilisateur tel quel à Service B, ou l’échange contre un jeton impossible à distinguer de celui de l’utilisateur ; Service B le traite alors comme une requête émise par l’utilisateur et applique une autorisation au niveau utilisateur
  • Service B ne peut cependant pas distinguer une action directe de l’utilisateur d’une action effectuée par Service A en son nom ; si Service A est compromis, il peut émettre n’importe quel appel dans les limites des droits de l’utilisateur, et il devient impossible d’appliquer des niveaux de confiance différents entre requêtes directes et requêtes proxy : le contexte utilisateur est conservé, mais le contexte du service est perdu

• Option 3 — agir au nom de l’utilisateur (Delegation)

  • Service A échange le jeton utilisateur contre un nouveau jeton identifiant à la fois l’utilisateur (subject) et Service A (actor) ; la claim act du jeton résultant signifie « requête concernant l’utilisateur X, effectuée par Service A »
  • C’est le modèle de delegation que la RFC 8693 a principalement été conçue pour prendre en charge ; Service B peut ainsi prendre des décisions d’autorisation fines — si Service A tente une action que l’utilisateur n’a pas autorisée, la requête échoue
  • La claim act peut être imbriquée (nestable) ; si Service B appelle Service C, la chaîne de délégation s’allonge et fournit une piste d’audit complète
  • Le compromis, c’est la complexité : chaque saut nécessite un token exchange, ce qui augmente la latence, et chaque service doit être enregistré comme client auprès du serveur d’autorisation ; mais dans les architectures où sécurité et audit sont essentiels, c’est l’option de principe

Token Exchange et identité fédérée

• Lorsque les services traversent des domaines de sécurité distincts (par exemple un service fourni par une organisation tierce), le scénario de chaînage devient nettement plus complexe
  • Service A détient un jeton lui permettant d’accéder à Service B au nom d’un utilisateur dans le domaine de sécurité de MyCompany
  • Service B doit appeler Service C, protégé dans le domaine d’External Provider, et a besoin pour cela d’un access token
• Un jeton émis par le serveur d’autorisation de MyCompany n’a aucune signification dans le domaine d’External Provider : un jeton émis par un serveur d’autorisation n’est pas automatiquement accepté par un autre, car les frontières de confiance existent précisément pour limiter le blast radius

• Les limites de la configuration fédérée

  • Il faut configurer le serveur d’autorisation d’External Provider pour qu’il accepte les jetons du domaine MyCompany comme subject_token valides ; cela suppose une confiance préalable par échange de métadonnées, validation de certificats ou configuration directe, ainsi qu’un mapping d’identité entre domaines
  • À mesure que le nombre de domaines augmente — intégration d’entreprise, écosystèmes SaaS, multi-cloud — la matrice de relations de confiance bilatérales devient ingérable

• Cross App Access et Identity Chaining

  • Pour résoudre ce problème de passage à l’échelle, Cross App Access (XAA) met en œuvre Identity Assertion JWT Authorization Grant et introduit un IdP d’entreprise comme intermédiaire pour les échanges interdomaines
  • L’idée clé est que l’IdP connaît déjà les deux applications et leur relation avec l’utilisateur ; au lieu d’établir une confiance bilatérale entre chaque paire de domaines, on centralise la décision d’accès au niveau de l’IdP

  • Les 4 parties du flux XAA

    • Requesting App : l’application du domaine MyCompany (ou l’agent IA) qui doit accéder à une ressource dans un autre domaine
    • Enterprise IdP : le fournisseur d’identité du domaine MyCompany qui authentifie les employés et gère les politiques cross-app
    • Resource App : l’application du domaine d’External Provider qui possède l’API protégée
    • Resource Authorization Server : le serveur d’autorisation qui émet les access tokens pour l’API protégée de Resource App

  • Le déroulé du flux XAA

    • L’employé se connecte à Requesting App via le SSO et obtient un ID token de l’IdP
    • Requesting App renvoie cet ID token à l’IdP pour demander une assertion d’identité interdomaines (ID-JAG, un JWT spécial scoped pour l’usage cross-app)
    • L’IdP vérifie la politique XAA — il détermine si l’accès à Resource App est autorisé au nom de cet utilisateur ; si oui, il renvoie l’ID-JAG
    • Requesting App présente l’ID-JAG au serveur d’autorisation de Resource App
    • Le serveur d’autorisation de Resource App valide l’ID-JAG à l’aide de la clé publique de l’IdP via OIDC discovery, puis émet un access token
    • Requesting App appelle l’API de Resource App avec cet access token
  • La différence décisive avec un token exchange classique se situe à l’étape 3, où l’IdP fait respecter la décision de politique : l’administrateur configure explicitement quelles applications peuvent atteindre quelles ressources, ce qui donne à l’IT visibilité et contrôle tout en évitant à l’utilisateur des flux de consentement répétés
  • Identity Chaining désigne le pattern plus large dans lequel l’assertion d’identité utilisateur circule, de façon standardisée, depuis l’authentification initiale jusqu’à tous les services downstream ; XAA en est une implémentation fondée sur les primitives OAuth
  • Ce modèle est particulièrement pertinent dans les scénarios d’agents IA, où une seule requête utilisateur peut déclencher des appels à des services de plusieurs fournisseurs tiers

Token Exchange et Auth0

• Auth0 implémente le token exchange à travers plusieurs mécanismes couvrant différents points du spectre présenté plus haut

• Custom Token Exchange

  • Implémente la RFC 8693 sur l’endpoint /oauth/token d’Auth0, avec un contrôle total du développeur sur la logique de validation
  • Définit un Token Exchange Profile qui mappe l’URI subject_token_type à une Action personnalisée ; à la réception de la requête, Auth0 appelle ce code Action pour valider le jeton, appliquer les règles d’autorisation et associer l’utilisateur dans le tenant
  • Comme Auth0 traite le subject_token comme une chaîne opaque, il peut accepter n’importe quel format : JWT d’un autre IdP, assertion SAML legacy, jeton propriétaire d’une API partenaire, etc. — un mécanisme utile pour la transition de protocole et la fédération personnalisée

• Token Vault

  • Conçu pour les scénarios d’agents IA qui appellent des API tierces au nom de l’utilisateur chez plusieurs fournisseurs, en ajoutant au token exchange un stockage sécurisé et une gestion automatique du cycle de vie
  • Après authentification, l’utilisateur connecte ses comptes (Google, GitHub, Slack, Microsoft, etc.) ; Token Vault stocke les jetons en sécurité et gère automatiquement leur renouvellement, tandis que l’agent IA récupère depuis ce coffre un access token valide via token exchange
  • Le jeton résultant inclut une claim act identifiant l’agent IA — créant ainsi une piste d’audit sur quel agent a accédé à quel service au nom de quel utilisateur, ce qui est indispensable pour la conformité en entreprise où il faut savoir ce qui a déclenché l’automatisation

• On-Behalf-Of (OBO) Token Exchange

  • Implémente directement le pattern de delegation pour les scénarios de chaîne de services : un service intermédiaire échange le jeton utilisateur entrant contre un nouveau jeton scoped pour une API downstream et s’ajoute à la chaîne de délégation via la claim act
  • Prend en charge jusqu’à 5 niveaux d’imbrication dans la chaîne de délégation ; chaque jeton contient les claims sub (préservation de l’identité utilisateur), aud (scope du service cible) et act imbriquée (historique de la chaîne de services impliqués)

• Cross App Access (XAA)

  • Ciblé sur les scénarios d’identité fédérée où l’application requérante doit appeler une API de ressource protégée par un autre serveur d’autorisation ; implémente l’extension OAuth Identity Assertion Authorization Grant
  • Auth0 joue le rôle de Resource Authorization Server : Requesting App envoie le user ID token à un IdP comme Okta pour recevoir un ID-JAG, et l’IdP n’émet cette assertion que si l’administrateur a configuré la connexion cross-app dans l’Admin Console
  • Requesting App présente ensuite l’ID-JAG à Auth0, qui le valide via OIDC discovery avant d’émettre un access token scoped, offrant ainsi à l’IT une visibilité centralisée sur le partage de données cross-app

Choisir la bonne approche

• Le token exchange n’est pas une solution unique mais un ensemble de patterns, et le bon choix dépend du contexte à préserver et des frontières de confiance à franchir
  • Impersonation administrateur : quand il faut voir exactement ce que voit l’utilisateur pour résoudre un problème
  • Transition de protocole : quand il faut un pont entre systèmes d’identité legacy et modernes pendant une migration
  • Delegation : quand une chaîne de services a besoin du contexte utilisateur avec une auditabilité complète
  • Cross App Access / Identity Chaining : quand la délégation s’étend sur plusieurs domaines de sécurité
  • Token Vault : quand un agent IA a besoin d’un accès géré à des API tierces au nom de l’utilisateur
• Les agents IA qui orchestrent des actions au nom de l’utilisateur à travers plusieurs services et fournisseurs forment par nature une chaîne de délégation, et les mécanismes de token exchange constituent la base de sécurité qui rend cette chaîne auditable, autorisée et scoped selon l’intention de l’utilisateur