Echange de jetons

Les jetons de sécurité, tels que les jetons Web JSON (JWT), les jetons d'accès OAuth et autres, facilitent le partage des identités, autorisent l'accès aux API, etc. à travers les domaines de sécurité et les systèmes. Un service de jetons de sécurité (STS) est un système capable de valider les jetons de sécurité qui lui sont fournis et de les échanger contre de nouveaux jetons de sécurité en réponse. Cela permet aux clients d'obtenir des jetons de sécurité adaptés et appropriés pour faciliter l'accès aux ressources et effectuer des opérations.

OAuth 2.0 Token Exchange est une extension d'OAuth 2.0 qui permet à un serveur d'autorisation d'agir en tant que STS. Ce mécanisme permet aux services ou clients de confiance d'obtenir et d'échanger des jetons en toute sécurité. L'échange de jetons est particulièrement utile lorsqu'un service ou une application doit acquérir un autre type de jeton ou un jeton doté de privilèges spécifiques pour accéder à une ressource ou effectuer une action.

Flux OAuth traditionnels ou échange de jetons

Dans le flux OAuth typique, l'application cliente demande l'accès à des ressources protégées à l'aide d'un jeton d'accès délivré par Verify. Cette application est enregistrée sur Verify et demande des jetons uniquement à Verify. L'utilisateur ou le client de l'API s'authentifie auprès de Verify ou par son intermédiaire.

En revanche, l'échange de jetons offre une plus grande souplesse quant au lieu d'émission initial du jeton de sécurité. Par exemple, il peut s'agir d'un fournisseur d'identité tiers qui émet un jeton d'identification OIDC lors de l'authentification de l'utilisateur. L'application échange ensuite ce jeton contre un jeton d'accès délivré par Verify et l'utilise pour accéder aux ressources protégées. Il existe d'autres scénarios dans lesquels le jeton initial peut également être émis par le même locataire Verify, par exemple pour échanger un jeton émis pour le client A contre un jeton utilisé par le client B.

D'un point de vue sémantique, il existe deux scénarios différents à explorer : l'impersonnalisation et la délégation.

Usurpation d'identité

L'usurpation d'identité est l'usage le plus courant de l'échange de jetons. Prenons l'exemple suivant pour illustrer ce propos.

L'application client reçoit un jeton d'accès après l'authentification de l'utilisateur et ce jeton est utilisé pour accéder à la ressource protégée "A". "A" a besoin d'accéder à une autre ressource protégée "B", mais le jeton délivré au client ne peut pas être utilisé à cette fin, car il ne dispose pas des autorisations nécessaires pour accéder directement à "B". Dans ce cas, le service "A" est en mesure d'échanger le jeton de l'application client contre un nouveau jeton qui dispose des autorisations nécessaires pour accéder à "B".

Ici, le service "A" se fait passer pour le sujet du jeton et agit en son nom.

Le principe de base est le suivant :

1. Le jeton d'entrée (également appelé jeton de sujet) est délivré au client pour qu'il agisse au nom du sujet ou qu'il contienne des informations sur l'identité de l'utilisateur qui identifient le sujet.
2. Le jeton de sortie est délivré au client pour qu'il agisse au nom du sujet ou contienne des informations sur l'identité de l'utilisateur.

Ainsi, les jetons d'entrée et de sortie sont tous deux liés au même sujet.

Ce mode d'utilisation introduit de nouveaux paramètres à inclure dans l'appel API du jeton OAuth 2.0

• subject_token est le jeton de sécurité validé par Verify et associé au sujet.

  📘

  Note

  La validation requise est différente selon les types de jetons. Par exemple, la validité d'un jeton émis par le même locataire Verify est vérifiée par introspection. Un JWT émis par une partie externe est validé à l'aide des clés publiques disponibles (sous la forme de jwks_uri configuré pour le type de jeton ou dans le magasin de certificats du locataire).

• subject_token_type indique le type du jeton sujet et est utilisé pour déterminer la manière dont il est validé. Verify prend en charge nativement plusieurs types de jetons de sujet et permet également de créer des types de jetons personnalisés. Cette valeur est généralement au format URN.

• requested_token_type est le type de jeton de sécurité demandé. Une application peut être en mesure de demander différents types de jetons pour différentes raisons. Verify prend en charge plusieurs types de jetons en mode natif et a également la possibilité d'émettre des jetons personnalisés, tels que JWT.

Voici quelques cas d'utilisation courante de l'usurpation d'identité.

Accéder à une ressource protégée après s'être authentifié auprès d'un fournisseur d'identité externe

Ici, l'application cliente doit accéder à une ressource protégée API. Dans un flux OAuth classique, l'application lance un flux d'octroi de code d'autorisation et, lors de l'authentification de l'utilisateur, l'application reçoit un jeton d'accès. Ce jeton d'accès peut ensuite être utilisé pour accéder aux ressources protégées.

Cependant, considérons le cas où l'utilisateur s'authentifie par l'intermédiaire d'un fournisseur d'identité externe et où Verify n'émet pas le(s) jeton(s). Considérons en outre que l'application reçoit un jeton d'identité sous la forme d'un JWT signé dans le cadre de l'authentification de l'utilisateur. Dans ce cas, l'application doit échanger le jeton d'identité contre un jeton d'accès approprié qui peut ensuite être utilisé pour accéder aux ressources protégées. L' échange de jetons OAuth 2.0 est utile à cet égard. Cette situation est illustrée de la manière suivante.

Principaux intérêts :

• subject_token est le jeton Web JSON émis par le fournisseur d'identité externe qui contient l'identifiant de l'utilisateur.
• subject_token_type est un type de JWT personnalisé qui est configuré sur le serveur d'autorisation. Il comprend des propriétés telles que le matériel clé qui peut être utilisé pour valider le jeton (soit comme jwks, jwks_uri ou une autre méthode), toute configuration de mappage pour identifier l'utilisateur sur le serveur d'autorisation, etc.
• requested_token_type est le type de jeton d'accès émis par le serveur d'autorisation.

📘

Note

Il peut y avoir une petite variante à ce flux. L'application génère le JWT signé au lieu qu'il soit émis par le fournisseur d'identité. Il est utilisé pour affirmer l'identité de l'utilisateur à l'application lors de l'authentification.

Cela peut être utile si le fournisseur tiers n'est pas en mesure d'émettre un JWT ou si l'utilisateur peut s'authentifier directement auprès de l'application avec différents fournisseurs d'identité. Dans ce dernier cas, bien que Verify prenne en charge plusieurs types de jetons personnalisés, il peut être utile de générer un JWT normalisé afin de réduire les données partagées avec Verify lors de l'appel à l'API du jeton.

Communication de ressource à ressource

Ceci décompose l'exemple utilisé précédemment pour expliquer l'usurpation d'identité.

Dans ce cas, le service de ressources A doit appeler un autre service de ressources B au nom de l'utilisateur. Le jeton utilisé par l'application pour autoriser la demande au service de ressources A ne peut pas être réutilisé pour appeler le service de ressources B pour les raisons suivantes :

1. Permissions manquantes pour appeler l'API du service de ressources B : si l'application n'a pas directement besoin d'appeler l'API de ressources B, le jeton ne devrait pas avoir ces droits.
2. Le jeton est limité à l'expéditeur et le service de ressources A ne peut donc pas l'utiliser pour appeler le service de ressources B.

Dans ce cas, le service de ressources A lance le flux d'échange de jetons en fournissant le jeton d'accès de l'utilisateur dans la demande. Un nouveau jeton d'utilisateur est émis, qui peut ensuite être utilisé pour appeler la ressource API B.

Principaux intérêts :

• subject_token est le jeton d'accès délivré par Verify qui peut être validé en mode natif.
• subject_token_type est le type de jeton d'accès natif pris en charge par Verify ( urn:ietf:params:oauth:token-type:access_token ).
• requested_token_type est le type de jeton d'accès natif pris en charge par Verify ( urn:ietf:params:oauth:token-type:access_token ).

Délégation

Considérons un scénario dans lequel un utilisateur A doit agir au nom d'un autre utilisateur B. Dans ce cas, l'application cliente a besoin d'un jeton qui lui permet d'agir au nom de l'utilisateur B, mais l'utilisateur qui interagit avec l'application est l'utilisateur A. Ainsi, l'utilisateur A est l'"acteur" et l'utilisateur B est le "sujet". Cette situation est très fréquente pour les autorisations basées sur les relations. Par exemple, un médecin de famille qui a besoin d'accéder aux dossiers médicaux de ses patients.

Bien qu'il soit possible d'y parvenir par l'usurpation d'identité (et c'est d'ailleurs ce qui se fait avec les anciens protocoles comme WS-Trust), on perd ainsi la possibilité d'audit et une méthode prescrite de mise en œuvre.

Ce mode présente deux différences essentielles :

1. actor_token est inclus en tant que paramètre avec un actor_token_type correspondant. Il est utilisé pour valider l'acteur.
2. may_act est une demande ajoutée au site subject_token qui est un objet JSON d'une ou plusieurs propriétés en corrélation avec les propriétés du jeton d'acteur.

Prenons l'exemple d'une clinique médicale nommée "Votre clinique familiale". Tout médecin de cette clinique peut accéder aux informations relatives aux patients de la clinique. Le site actor_token qui représente un médecin peut être un JWT avec la charge utile suivante.

{
    "iss": "https://jke.com",
    "sub": "docA",
    "clinic": "your_family_clinic"
}

Le site subject_token est un JWT qui identifie le patient. La mention may_act dans ce jeton indique que tout jeton d'acteur dont la valeur "clinic" est "your_family_clinic" peut demander un nouveau jeton de patient. Ce jeton peut ensuite être utilisé pour accéder aux dossiers médicaux des patients. La charge utile qui suit illustre le jeton sujet.

{
    "sub": "patientB",
    "may_act": {
        "clinic": "your_family_clinic"
    }
}

Ce mode d'utilisation introduit de nouveaux paramètres à inclure dans l'appel API du jeton OAuth 2.0

• actor_token est le jeton de sécurité qui est validé pour confirmer l'identité de l'acteur et ses droits à demander cet échange de jetons.
• actor_token_type est le type de jeton de sécurité. Il est similaire à subject_token_type et peut être un type personnalisé.

📘

Note

Tout d'abord, le jeton de sujet peut être un jeton d'accès émis pour le patient. L'objectif est d'identifier le sujet (patient) et les acteurs autorisés (indiqués par may_act ). Avec les jetons d'accès, cette information est obtenue à partir de la réponse d'introspection OAuth.

Deuxièmement, l'allégation may_act peut avoir plus d'une propriété et toutes doivent correspondre aux propriétés du site actor_token. Verify inclut la demande may_act dans les événements d'audit SSO et de jeton.

Troisièmement, Verify offre la possibilité d'évaluer une politique d'accès dans le cadre du flux d'échange de jetons afin d'effectuer des contrôles d'autorisation plus fins.

Voici un autre cas d'utilisation courante pour illustrer ce mode.

Procuration

Prenons le cas d'un parent âgé qui accorde une procuration PoA un enfant. L'enfant peut ainsi accéder aux services publics pour son parent, effectuer des transactions bancaires en son nom, etc.

Dans ce cas, Verify détermine si un jeton de parent doit être émis en fonction de la relation entre le parent et l'enfant et si le parent a consenti à ce que l'enfant effectue des actions en son nom.

L'enveloppe

L'échange de jetons OAuth 2.0 permet aux applications et aux services d'échanger des jetons émis par Verify ou par des tiers contre des jetons émis par Verify avec des champs d'application et des contraintes configurables. Il peut être configuré sous la forme de clients STS autonomes et dans les applications OpenID Connect en tant que type de subvention. Verify prend en charge les types de jetons JWT personnalisés en plus des types de jetons natifs, tels que les jetons d'accès, les jetons de rafraîchissement et les jetons d'identification. Les clients et les applications peuvent être configurés dans Verify pour utiliser des formes plus fortes d'authentification du client, telles que les assertions JWT, et produire des jetons limités à l'expéditeur, tels que les jetons DPoP.

💎

Vivek Shankar, IBM Security