Comprendre les Claims des Jetons d'Accès OAuth 2

26 juin 2023

OAuth 2.x est un protocole largement adopté pour sécuriser les API et fournir un accès délégué aux ressources des utilisateurs. Les jetons d’accès (access tokens) jouent un rôle essentiel dans le flux OAuth, servant de justificatifs (credentials) pour autoriser les requêtes API. Dans cet article de blog, nous explorerons les différents claims (revendications) présents dans les jetons d’accès OAuth, en mettant en lumière leur rôle et leur importance.

Introduction aux claims de jeton d’accès

Les jetons d’accès dans OAuth 2.0 et OAuth 2.1 sont généralement encodés sous forme de JSON Web Tokens (JWT), qui consistent en un ensemble de claims. Les claims sont des informations contenues dans la charge utile (payload) du jeton d’accès, fournissant des détails pertinents sur le jeton, l’utilisateur et les permissions autorisées.

Claims Standards

Issuer (iss) : Le claim iss spécifie l’émetteur du jeton d’accès. Il représente le serveur d’autorisation qui a émis le jeton.
Subject (sub) : Le claim sub identifie le sujet du jeton d’accès, qui peut être un utilisateur ou un client (pour les communications de machine à machine). Pour les jetons d’accès utilisateur, ce claim contient souvent un identifiant unique pour l’utilisateur authentifié (user id).
Audience (aud) : Le claim aud identifie le public destinataire du jeton d’accès. Il représente le(s) serveur(s) de ressources ou service(s) auquel le jeton est destiné. Par exemple, si vous avez des serveurs de ressources pour le stockage de fichiers et d’autres serveurs de ressources pour le streaming vidéo, vous pouvez restreindre l’accès à un seul d’entre eux.
Scope (scope) : Le claim scope spécifie les permissions accordées au jeton d’accès. Il définit les actions et les ressources auxquelles le jeton peut accéder. Par exemple, un jeton avec le scope read peut uniquement être capable de lire des données, tandis qu’un jeton avec le scope write peut être capable d’écrire des données. Certains scopes sont définis par la spécification OAuth 2.0, tandis que d’autres peuvent être des scopes personnalisés définis par le serveur d’autorisation.
Expiration Time (exp) : Le claim exp indique l’heure d’expiration du jeton d’accès. Après cette heure, le jeton ne doit plus être considéré comme valide.
Issued At (iat) : Le claim iat spécifie l’horodatage auquel le jeton d’accès a été émis. Il peut être utile pour déterminer l’âge du jeton et calculer les périodes de validité.
Not Before (nbf) : Le claim nbf indique le moment le plus précoce à partir duquel le jeton d’accès peut être considéré comme valide. Les jetons présentés avant ce moment doivent être rejetés.
Token Identifier (jti) : Le claim jti fournit un identifiant unique pour le jeton d’accès. Il peut être utilisé pour suivre ou révoquer des jetons dans certains scénarios.

Voici un exemple de charge utile (payload) de jeton d’accès contenant ces claims standards :

{
  "iss": "https://auth.example.com",
  "sub": "1234567890",
  "aud": "https://api.example.com",
  "scope": "read write",
  "exp": 1635200000,
  "iat": 1635196400,
  "nbf": 1635196400,
  "jti": "abc123"
}

Claims Personnalisés (Custom Claims)

En plus des claims standards, OAuth permet l’inclusion de claims personnalisés spécifiques à l’application ou au serveur d’autorisation. Ces claims peuvent fournir du contexte ou des informations supplémentaires nécessaires au client ou au serveur de ressources.

Informations spécifiques au client : Les claims personnalisés peuvent également inclure des données spécifiques au client, telles que des identifiants utilisateur spécifiques à l’application ou toute autre information pertinente requise par le client. Privilégiez l’utilisation des claims standards lorsqu’ils existent. Si vous utilisez la couche d’identité OpenID Connect, vous devriez utiliser les claims standards d’OpenID Connect.
Rôles des utilisateurs : Bien que les claims personnalisés puissent inclure des informations sur les rôles des utilisateurs, vous ne devriez pas utiliser les claims personnalisés OAuth pour transmettre des permissions au sein du système. OAuth est un protocole d’autorisation d’application initialement conçu pour gérer l’autorisation d’application, et non les permissions des utilisateurs. Pour les permissions des utilisateurs, vous devriez utiliser un système de permissions comme UMA et/ou un modèle comme Google Zanzibar.

Validation et Utilisation des Jetons d’Accès

Pour garantir la sécurité et l’intégrité des jetons d’accès, il est essentiel de valider les jetons avant d’accepter et de traiter les requêtes. Le processus de validation implique généralement la vérification de la signature du jeton, la vérification de son heure d’expiration et la garantie que le jeton a été émis par un serveur d’autorisation de confiance.

Les jetons d’accès doivent être transmis et stockés de manière sécurisée, car ils accordent l’accès à des ressources protégées. Ils ne doivent être utilisés que par les parties autorisées et protégés contre tout accès non autorisé ou toute falsification.