Comprendre l'échange de jetons dans OAuth/OIDC

Introduit dans RFC 8693, l'échange de jetons est une extension OAuth qui permet à des clients de confiance d'échanger un jeton existant pour un nouveau avec des attributs ou des portées différents. Ce mécanisme est particulièrement utile pour un service, une application ou un utilisateur final pour obtenir un jeton d'accès OAuth normal via un jeton préautorisé, sans avoir besoin de passer par le flux OAuth complet.

Comparaison avec le flux de code d'autorisation#

Tout d'abord, examinons le flux de code d'autorisation OAuth, qui est le flux le plus courant pour obtenir un jeton d'accès.

Et voici le flux d'échange de jetons :

Redirection#

La principale différence est que dans le flux de code d'autorisation, l'application cliente redirige l'utilisateur vers le serveur d'autorisation pour obtenir un jeton d'accès. Dans l'échange de jetons, l'application cliente peut échanger un jeton avec le serveur d'autorisation sans impliquer l'utilisateur dans la redirection.

Cela est dû au fait que dans le flux de code d'autorisation, l'application cliente n'est pas "de confiance" et doit connaître les identifiants de l'utilisateur pour obtenir un jeton d'accès. Dans l'échange de jetons, l'application cliente est considérée comme ayant déjà obtenu le jeton de l'utilisateur et le serveur d'autorisation vérifiera le jeton et en émettra un nouveau.

Émetteur de jetons et service d'échange de jetons#

Dans le flux d'échange de jetons, le "Auth Server" est maintenant deux participants :

1. Émetteur de jetons : émet le jeton de sujet à l'application cliente.
2. Service d'échange de jetons : valide le jeton de sujet et émet un nouveau jeton à l'application cliente.

Le service d'échange de jetons est le même que "Auth Server" dans le flux de code d'autorisation, et l'émetteur de jetons peut être un fournisseur d'identité tiers ou séparé du "Auth Server" comme un service dédié.

Quand utiliser l'échange de jetons ?#

Le flux d'échange de jetons peut être effectué sans interaction utilisateur, ce qui est utile dans les scénarios suivants :

• Usurpation d'identité : Permettre aux services (par exemple, aux microservices backend) ou aux utilisateurs administrateurs d'effectuer des actions au nom d'un utilisateur sans exposer les identifiants complets de l'utilisateur.
• Automatisation : Permettre aux services de confiance d'effectuer automatiquement des actions sans intervention manuelle, ou de réaliser des tests automatisés.
• Intégration avec d'autres fournisseurs d'identité (IdP) : Traduire les jetons entre différents systèmes d'identité pour maintenir une expérience utilisateur fluide et gérer les autorisations efficacement, un scénario courant étant de traduire un jeton SSO en un jeton pour un service en aval.
• Migration : Migrer les jetons d'un serveur d'autorisation à un autre, par exemple, d'un système hérité à un système moderne conforme à OAuth/OIDC.

Processus d'échange de jetons#

L'échange pour un nouveau jeton d'accès est le cas d'utilisation le plus courant, nous prendrons cet exemple. Non limité au jeton d'accès, l'échange de jetons peut également être utilisé pour émettre d'autres types de jetons tels que les jetons de rafraîchissement, les jetons d'identité, etc.

Application cliente#

Pour effectuer un échange de jetons, une application cliente enregistrée auprès du serveur d'autorisation est requise.

Et l'application cliente doit avoir un subject_token avant d'initier le flux d'échange de jetons, ce jeton est généralement accordé par le serveur d'autorisation ou le fournisseur d'identité tiers de confiance. En possédant ce jeton, l'application cliente peut maintenant être "de confiance" pour échanger des jetons sans besoin des identifiants et de l'interaction de l'utilisateur.

Demande d'échange de jetons#

Le client envoie une demande au point de terminaison du jeton du serveur d'autorisation pour échanger un jeton existant. Cela inclut le subject_token (le jeton en cours d'échange) et éventuellement, l'audience cible souhaitée, la portée et le type de jeton.

1. grant_type: REQUIS. La valeur de ce paramètre doit être urn:ietf:params:oauth:grant-type:token-exchange indique qu'un échange de jetons est en cours.
2. subject_token: REQUIS. Le PAT de l'utilisateur.
3. subject_token_type: REQUIS. Le type de jeton de sécurité fourni dans le paramètre subject_token. Une valeur courante de ce paramètre est urn:ietf:params:oauth:token-type:access_token, mais cela peut varier en fonction du jeton échangé.
4. resource: OPTIONNEL. L'indicateur de ressource, aide à spécifier la ressource cible pour le jeton d'accès.
5. audience: OPTIONNEL. L'audience du jeton d'accès, indiquant les destinataires prévus du jeton, le serveur d'autorisation peut utiliser la valeur de resource si audience n'est pas spécifiée.
6. scope: OPTIONNEL. Les portées demandées.

De plus, la demande doit inclure les informations du client, qui peuvent être encodées en tant qu'en-tête Basic Auth ou envoyées en tant que données de formulaire.

Voici un exemple de demande :

Échange de jetons dans Logto#

Logto prend en charge l'échange de jetons par défaut, y compris usurpation d'identité et jetons d'accès personnels.