2. JWT Access Token Header and Data Structure (En-tête et structure de données du jeton d'accès JWT)
2.1. Header (En-tête)
Les jetons d'accès JWT doivent être signés (MUST). Bien que les jetons d'accès JWT puissent utiliser n'importe quel algorithme de signature, l'utilisation de la cryptographie asymétrique est recommandée (RECOMMENDED) car elle simplifie le processus d'acquisition des informations de validation pour les serveurs de ressources (voir Section 4). Les jetons d'accès JWT ne doivent pas (MUST NOT) utiliser "none" comme algorithme de signature. Voir la Section 4 pour plus de détails.
Les serveurs d'autorisation et les serveurs de ressources conformes à cette spécification doivent (MUST) inclure RS256 (tel que défini dans [RFC7518]) parmi leurs algorithmes de signature pris en charge.
Cette spécification enregistre le type de média (Media Type) "application/at+jwt", qui peut être utilisé pour indiquer que le contenu est un jeton d'accès JWT. Les jetons d'accès JWT doivent (MUST) inclure ce type de média dans le paramètre d'en-tête "typ" pour déclarer explicitement que le JWT représente un jeton d'accès conforme à ce profil. Conformément à la définition de "typ" dans la Section 4.1.9 de [RFC7515], il est recommandé (RECOMMENDED) que le préfixe "application/" soit omis. Par conséquent, la valeur "typ" utilisée devrait (SHOULD) être "at+jwt". Voir la section Considérations de sécurité pour plus de détails sur l'importance d'empêcher que les jetons d'identité OpenID Connect (tels que définis par la Section 2 de [OpenID.Core]) soient acceptés comme jetons d'accès par les serveurs de ressources implémentant ce profil.
2.2. Data Structure (Structure de données)
Les revendications (Claim) suivantes sont utilisées dans la structure de données du jeton d'accès JWT.
iss REQUIS (REQUIRED) - tel que défini dans la Section 4.1.1 de [RFC7519].
exp REQUIS (REQUIRED) - tel que défini dans la Section 4.1.4 de [RFC7519].
aud REQUIS (REQUIRED) - tel que défini dans la Section 4.1.3 de [RFC7519]. Voir la Section 3 pour des indications sur la façon dont un serveur d'autorisation devrait déterminer la valeur de "aud" en fonction de la demande.
sub REQUIS (REQUIRED) - tel que défini dans la Section 4.1.2 de [RFC7519]. Dans le cas des jetons d'accès obtenus via des octrois où un propriétaire de ressource (Resource Owner) est impliqué, tel que l'octroi de code d'autorisation (Authorization Code Grant), la valeur de "sub" devrait (SHOULD) correspondre à l'identifiant du sujet du propriétaire de ressource. Dans le cas des jetons d'accès obtenus via des octrois où aucun propriétaire de ressource n'est impliqué, tel que l'octroi d'informations d'identification du client (Client Credentials Grant), la valeur de "sub" devrait (SHOULD) correspondre à un identifiant que le serveur d'autorisation utilise pour indiquer l'application client. Voir la Section 5 pour plus de détails sur ce scénario. Voir également la Section 6 pour une discussion sur la façon dont différents choix dans l'attribution des valeurs "sub" peuvent affecter la vie privée.
client_id REQUIS (REQUIRED) - tel que défini dans la Section 4.3 de [RFC8693].
iat REQUIS (REQUIRED) - tel que défini dans la Section 4.1.6 de [RFC7519]. Cette revendication identifie le moment où le jeton d'accès JWT a été émis.
jti REQUIS (REQUIRED) - tel que défini dans la Section 4.1.7 de [RFC7519].
2.2.1. Authentication Information Claims (Revendications d'informations d'authentification)
Les revendications énumérées dans cette section peuvent (MAY) être émises dans le contexte d'octrois d'autorisation impliquant le propriétaire de ressource et reflètent les types et la force de l'authentification dans le jeton d'accès que le serveur d'authentification a appliqués avant de retourner la réponse d'autorisation au client. Leurs valeurs sont fixes et restent les mêmes pour tous les jetons d'accès qui dérivent d'une réponse d'autorisation donnée, que le jeton d'accès ait été obtenu directement dans la réponse (par exemple, via le flux implicite (Implicit Flow)) ou après un ou plusieurs échanges de jetons (par exemple, l'obtention d'un nouveau jeton d'accès en utilisant un jeton de rafraîchissement (Refresh Token) ou l'échange d'un jeton d'accès contre un autre via les procédures [RFC8693]).
auth_time OPTIONNEL (OPTIONAL) - tel que défini dans la Section 2 de [OpenID.Core].
acr OPTIONNEL (OPTIONAL) - tel que défini dans la Section 2 de [OpenID.Core].
amr OPTIONNEL (OPTIONAL) - tel que défini dans la Section 2 de [OpenID.Core].
2.2.2. Identity Claims (Revendications d'identité)
Dans le contexte d'octrois d'autorisation impliquant le propriétaire de ressource, les serveurs d'autorisation commerciaux incluent souvent des attributs du propriétaire de ressource directement dans les jetons d'accès afin que les serveurs de ressources puissent les consommer directement à des fins d'autorisation ou autres sans aucun autre aller-retour vers les points de terminaison d'introspection (Introspection) ([RFC7662]) ou UserInfo ([OpenID.Core]). Ceci est particulièrement courant dans les scénarios où le client et le serveur de ressources appartiennent à la même entité et font partie de la même solution, comme c'est le cas pour les clients de première partie (First-Party Client) invoquant leur propre API backend.
Ce profil n'introduit aucun mécanisme permettant à un client de demander directement la présence de revendications spécifiques dans les jetons d'accès JWT, car le serveur d'autorisation peut déterminer quelles revendications supplémentaires sont requises par un serveur de ressources particulier en prenant en considération le client_id du client et les paramètres "scope" et "resource" inclus dans la demande.
Tout attribut d'identité supplémentaire dont la sémantique est bien décrite par une entrée dans le registre IANA "JSON Web Token (JWT)" introduit dans [RFC7519] devrait (SHOULD) être encodé en utilisant le nom de revendication correspondant, si cet attribut doit être inclus dans le jeton d'accès JWT. Notez que le registre IANA JWT inclut les revendications trouvées dans la Section 5.1 de [OpenID.Core].
Les serveurs d'autorisation peuvent (MAY) retourner des attributs arbitraires non définis dans aucune spécification existante, tant que les noms de revendication correspondants sont résistants aux collisions ou que les jetons d'accès sont destinés à être utilisés uniquement dans un sous-système privé. Veuillez vous référer aux Sections 4.2 et 4.3 de [RFC7519] pour plus de détails.
Les serveurs d'autorisation incluant des attributs de propriétaire de ressource dans les jetons d'accès JWT doivent faire preuve de prudence et vérifier que toutes les exigences en matière de confidentialité sont respectées, comme indiqué dans la Section 6.
2.2.3. Authorization Claims (Revendications d'autorisation)
Si une demande d'autorisation inclut un paramètre scope, le jeton d'accès JWT émis correspondant devrait (SHOULD) inclure une revendication "scope" telle que définie dans la Section 4.2 de [RFC8693].
Toutes les chaînes de portée individuelles dans la revendication "scope" doivent (MUST) avoir une signification pour les ressources indiquées dans la revendication "aud". Voir la Section 5 pour plus de considérations sur la relation entre les chaînes de portée et les ressources indiquées par la revendication "aud".
2.2.3.1. Claims for Authorization Outside of Delegation Scenarios (Revendications pour l'autorisation en dehors des scénarios de délégation)
De nombreux serveurs d'autorisation intègrent des attributs d'autorisation qui vont au-delà des scénarios délégués décrits par [RFC7519] dans les jetons d'accès qu'ils émettent. Des exemples typiques incluent les appartenances du propriétaire de ressource à des rôles (Role) et des groupes (Group) pertinents pour la ressource en cours d'accès, les droits (Entitlement) attribués au propriétaire de ressource pour la ressource ciblée que le serveur d'autorisation connaît, etc.
Un serveur d'autorisation souhaitant inclure de tels attributs dans un jeton d'accès JWT devrait (SHOULD) utiliser les attributs "groups", "roles" et "entitlements" du schéma de ressource "User" défini par la Section 4.1.2 de [RFC7643] comme types de revendications.
Les serveurs d'autorisation devraient (SHOULD) encoder les valeurs de revendication correspondantes selon les conseils définis dans [RFC7643]. En particulier, un exemple non normatif d'un attribut "groups" peut être trouvé dans la Section 8.2 de [RFC7643]. Aucun vocabulaire spécifique n'est fourni pour "roles" et "entitlements".
La Section 7.2.1 de ce document fournit des entrées pour l'enregistrement des attributs "groups", "roles" et "entitlements" de [RFC7643] comme types de revendications à utiliser dans ce profil.