1. Introduction
La spécification originale du cadre d'autorisation OAuth 2.0 (OAuth 2.0 Authorization Framework) [RFC6749] n'impose aucun format spécifique pour les jetons d'accès (Access Token). Bien que cela reste parfaitement approprié pour de nombreux scénarios importants, l'utilisation sur le marché a montré que de nombreuses implémentations commerciales d'OAuth 2.0 ont choisi d'émettre des jetons d'accès dans un format qui peut être analysé et validé directement par les serveurs de ressources (Resource Server), sans intervention supplémentaire du serveur d'autorisation (Authorization Server). Cette approche est particulièrement courante dans les topologies où le serveur d'autorisation et le serveur de ressources ne sont pas co-localisés, ne sont pas exploités par la même entité ou sont autrement séparés par une certaine frontière. Au moment de la rédaction, de nombreuses implémentations commerciales exploitent le format JSON Web Token (JWT) [RFC7519].
De nombreux jetons d'accès JWT spécifiques aux fournisseurs partagent la même disposition fonctionnelle, utilisant des revendications (Claim) JWT pour transmettre les informations nécessaires pour prendre en charge un ensemble commun de cas d'utilisation : validation des jetons, transport d'informations d'autorisation sous forme de portées (Scope) et de droits (Entitlement), transport d'informations d'identité sur le sujet (Subject), etc. Les différences sont principalement limitées aux noms de revendications et à la syntaxe utilisés pour représenter les mêmes entités, ce qui suggère que l'interopérabilité pourrait être facilement atteinte en normalisant un ensemble commun de revendications et de règles de validation.
L'hypothèse selon laquelle les jetons d'accès sont associés à des informations spécifiques n'apparaît pas seulement dans les implémentations commerciales. Diverses spécifications de la famille OAuth 2.0 (telles que les indicateurs de ressources (Resource Indicator) [RFC8707], l'utilisation des jetons bearer OAuth 2.0 (Bearer Token Usage) [RFC6750] et d'autres) postulent la présence de mécanismes de portée, tels qu'un public (Audience), dans les jetons d'accès. La famille de spécifications associées à l'introspection (Introspection) suggère également indirectement un ensemble fondamental d'informations que les jetons d'accès sont censés transporter ou au moins être associés.
Cette spécification vise à fournir un profil (Profile) standardisé et interopérable comme alternative aux dispositions propriétaires des jetons d'accès JWT à l'avenir. Outre la définition d'un ensemble commun de revendications obligatoires et optionnelles, le profil fournit des indications claires sur la manière dont les paramètres de la demande d'autorisation déterminent le contenu du jeton d'accès JWT émis, comment un serveur d'autorisation peut publier des métadonnées pertinentes pour les jetons d'accès JWT qu'il émet, et comment un serveur de ressources doit valider les jetons d'accès JWT entrants.
Enfin, cette spécification fournit des considérations de sécurité et de confidentialité destinées à prévenir les erreurs courantes et les anti-modèles susceptibles de se produire lors d'une utilisation naïve du format JWT pour représenter les jetons d'accès.
Veuillez noter : Bien que ce document et [RFC7523] utilisent tous deux des JSON Web Tokens dans le contexte du cadre OAuth2, les deux spécifications diffèrent tant dans leur intention que dans leurs mécanismes. Alors que [RFC7523] définit comment un jeton bearer JWT (JWT Bearer Token) peut être utilisé pour demander un jeton d'accès, ce document décrit comment encoder les jetons d'accès au format JWT.
1.1. Requirements Notation and Conventions (Notation et conventions des exigences)
Les mots-clés "MUST" (doit), "MUST NOT" (ne doit pas), "REQUIRED" (requis), "SHALL" (doit), "SHALL NOT" (ne doit pas), "SHOULD" (devrait), "SHOULD NOT" (ne devrait pas), "RECOMMENDED" (recommandé), "NOT RECOMMENDED" (non recommandé), "MAY" (peut) et "OPTIONAL" (optionnel) dans ce document doivent être interprétés comme décrit dans le BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en lettres majuscules, comme indiqué ici.
1.2. Terminology (Terminologie)
Jeton d'accès JWT (JWT access token) : Un jeton d'accès OAuth 2.0 encodé au format JWT et conforme aux exigences décrites dans cette spécification.
Cette spécification utilise les termes "access token" (jeton d'accès), "refresh token" (jeton de rafraîchissement), "authorization server" (serveur d'autorisation), "resource server" (serveur de ressources), "authorization endpoint" (point de terminaison d'autorisation), "authorization request" (demande d'autorisation), "authorization response" (réponse d'autorisation), "token endpoint" (point de terminaison de jeton), "grant type" (type d'octroi), "access token request" (demande de jeton d'accès), "access token response" (réponse de jeton d'accès) et "client" définis par le cadre d'autorisation OAuth 2.0 (The OAuth 2.0 Authorization Framework) [RFC6749].