1. Introduction
Un jeton de sécurité est un ensemble d'informations qui facilite le partage d'informations d'identité et de sécurité dans des environnements hétérogènes ou entre des domaines de sécurité. Des exemples de jetons de sécurité incluent les jetons JSON Web Token (JWT) [JWT] et les assertions Security Assertion Markup Language (SAML) 2.0 [OASIS.saml-core-2.0-os]. Les jetons de sécurité sont généralement signés pour assurer l'intégrité et parfois aussi chiffrés pour assurer la confidentialité. Les jetons de sécurité sont aussi parfois décrits comme des assertions, comme dans [RFC7521].
Un service de jetons de sécurité (STS) est un service capable de valider les jetons de sécurité qui lui sont fournis et d'émettre de nouveaux jetons de sécurité en réponse, ce qui permet aux clients d'obtenir des informations d'identification d'accès appropriées pour les ressources dans des environnements hétérogènes ou entre des domaines de sécurité. Les clients de services Web ont utilisé WS-Trust [WS-Trust] comme protocole pour interagir avec un STS pour l'échange de jetons. Alors que WS-Trust utilise XML et SOAP, la tendance dans le développement Web moderne a été vers des modèles RESTful (Representational State Transfer) et JSON. Le cadre d'autorisation OAuth 2.0 [RFC6749] et les jetons porteurs OAuth 2.0 [RFC6750] sont apparus comme des normes populaires pour autoriser l'accès des applications tierces aux ressources HTTP et RESTful. L'interaction OAuth 2.0 conventionnelle implique l'échange d'une certaine représentation de l'autorisation du propriétaire de la ressource contre un jeton d'accès, ce qui s'est avéré être un modèle extrêmement utile en pratique. Cependant, ses entrées et sorties sont un peu trop contraintes en l'état pour accueillir pleinement un cadre d'échange de jetons de sécurité.
Cette spécification définit un protocole étendant OAuth 2.0 qui permet aux clients de demander et d'obtenir des jetons de sécurité auprès de serveurs d'autorisation agissant dans le rôle d'un STS. Tout comme OAuth 2.0, cette spécification se concentre sur la simplicité pour le développeur client et ne nécessite qu'un client HTTP et un analyseur JSON, qui sont presque universellement disponibles dans les environnements de développement modernes. Le protocole STS défini dans cette spécification n'est pas lui-même RESTful (un STS ne se prête pas particulièrement bien à une approche REST) mais utilise des modèles de communication et des formats de données qui devraient être familiers aux développeurs habitués à travailler avec des systèmes RESTful.
Un nouveau type d'autorisation pour une demande d'échange de jetons et les paramètres spécifiques associés pour une telle demande au point de terminaison de jeton sont définis par cette spécification. Une réponse d'échange de jeton est une réponse OAuth 2.0 normale du point de terminaison de jeton avec quelques paramètres supplémentaires définis ici pour fournir des informations au client.
L'entité qui effectue la demande d'échange de jetons est considérée comme le client dans le contexte de l'interaction d'échange de jetons. Cependant, cela ne limite pas l'utilisation de ce profil aux clients OAuth traditionnels. Un serveur de ressources OAuth, par exemple, peut assumer le rôle du client pendant l'échange de jetons afin d'échanger un jeton d'accès qu'il a reçu dans une demande de ressource protégée contre un nouveau jeton qu'il est approprié d'inclure dans un appel à un service backend. Le nouveau jeton peut être un jeton d'accès dont la portée est plus étroite pour le service en aval ou il peut s'agir d'un type de jeton entièrement différent.
La portée de cette spécification est limitée à la définition d'un protocole de demande et de réponse de base pour un échange de jetons de style STS utilisant OAuth 2.0. Bien que quelques nouvelles revendications JWT soient définies qui permettent d'exprimer la sémantique de délégation, la syntaxe, la sémantique et les caractéristiques de sécurité spécifiques des jetons eux-mêmes (à la fois ceux présentés au serveur d'autorisation et ceux obtenus par le client) sont explicitement hors de portée, et aucune exigence n'est imposée au modèle de confiance dans lequel une implémentation pourrait être déployée. Des profils supplémentaires peuvent fournir des exigences plus détaillées concernant la nature spécifique des parties et la confiance impliquées, par exemple si la signature et/ou le chiffrement des jetons sont nécessaires ou si des jetons de style preuve de possession seront requis ou émis. Cependant, de tels détails seront souvent des décisions de politique prises en fonction des besoins spécifiques des déploiements individuels et seront configurés ou mis en œuvre en conséquence.
Les jetons de sécurité obtenus peuvent être utilisés dans un certain nombre de contextes, dont les détails dépassent également le cadre de cette spécification.
1.1. Sémantique de délégation vs usurpation d'identité
Un cas d'utilisation courant pour un STS (comme mentionné dans la section précédente) est de permettre à un serveur de ressources A d'effectuer des appels vers un service backend C au nom de l'utilisateur demandeur B. Selon la politique du site local et l'infrastructure d'autorisation, il peut être souhaitable pour A d'utiliser ses propres informations d'identification pour accéder à C avec une annotation d'une certaine forme indiquant que A agit au nom de B ("délégation") ou que A se voit accorder une information d'identification d'accès limitée à C mais qui continue d'identifier B comme l'entité autorisée ("usurpation d'identité"). La délégation et l'usurpation d'identité peuvent également être des concepts utiles dans d'autres scénarios impliquant plusieurs participants.
Lorsque le principal A usurpe l'identité du principal B, A reçoit tous les droits que B a dans un contexte de droits défini et est indiscernable de B dans ce contexte. Ainsi, lorsque le principal A usurpe l'identité du principal B, en ce qui concerne toute entité recevant un tel jeton, elle traite en fait avec B. Il est vrai que certains membres du système d'identité peuvent avoir conscience que l'usurpation d'identité est en cours, mais ce n'est pas une exigence. À toutes fins utiles, lorsque A usurpe l'identité de B, A est B dans le contexte des droits autorisés par le jeton. La capacité de A à usurper l'identité de B pourrait être limitée dans la portée ou le temps, ou même avec une restriction d'utilisation unique, que ce soit via le contenu du jeton ou un mécanisme hors bande.
La sémantique de délégation est différente de la sémantique d'usurpation d'identité, bien que les deux soient étroitement liées. Avec la sémantique de délégation, le principal A a toujours sa propre identité distincte de B, et il est explicitement compris que bien que B ait pu déléguer certains de ses droits à A, toutes les actions entreprises sont prises par A représentant B. En un sens, A est un agent pour B.
La délégation et l'usurpation d'identité ne couvrent pas toutes les situations. Lorsqu'un principal agit directement en son propre nom, par exemple, ni la délégation ni l'usurpation d'identité ne sont en jeu. Elles sont, cependant, les sémantiques les plus courantes opérant pour l'échange de jetons et, à ce titre, reçoivent un traitement plus direct dans cette spécification.
La sémantique de délégation est généralement exprimée dans un jeton en incluant des informations à la fois sur le sujet principal du jeton ainsi que sur l'acteur à qui ce sujet a délégué certains de ses droits. Un tel jeton est parfois appelé jeton composite car il est composé d'informations sur plusieurs sujets. Généralement, dans la demande, le "subject_token" représente l'identité de la partie au nom de laquelle le jeton est demandé tandis que le "actor_token" représente l'identité de la partie à laquelle les droits d'accès du jeton émis sont délégués. Un jeton composite émis par le serveur d'autorisation contiendra des informations sur les deux parties. Si et quand un jeton composite est émis est à la discrétion du serveur d'autorisation et de la politique et de la configuration applicables.
Les détails de la représentation d'un jeton composite et même si un tel jeton sera émis ou non dépendent des détails de la mise en œuvre et du type de jeton. Les représentations de jetons composites qui ne sont pas des JWT sont hors de la portée de cette spécification. Le paramètre de demande "actor_token", cependant, fournit un moyen de fournir des informations sur l'acteur souhaité, et la revendication JWT "act" peut fournir une représentation d'une chaîne de délégation.
1.2. Notation des exigences et conventions
Les mots clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans le BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.
1.3. Terminologie
Cette spécification utilise les termes "access token type", "authorization server", "client", "client identifier", "resource server", "token endpoint", "token request", et "token response" définis par OAuth 2.0 [RFC6749], et les termes "Base64url Encoding", "Claim", et "JWT Claims Set" définis par JSON Web Token (JWT) [JWT].