Comprendre les tokens OpenID Connect et OAuth 2.0

OpenID Connect permet aux applications d’obtenir des informations sur l’utilisateur auprès d’un fournisseur d’identité (Identity Provider, IdP) de confiance. Son fonctionnement repose sur plusieurs types de jetons (tokens), chacun avec un rôle distinct. Dans cet article, nous explorons les différents tokens, leurs formats et leurs cas d’usage.

Les tokens dans OpenID Connect

OpenID Connect manipule principalement trois types de tokens :

• ID Token
• Access Token
• Refresh Token

Chaque token joue un rôle précis dans le processus d’authentification et d’autorisation. Voyons cela en détail.

Synthèse des cas d’usage des tokens OpenID Connect et OAuth 2.0

Access Token

Objectif

L’access token (jeton d’accès) sert à autoriser l’accès à des ressources protégées, comme des API. Il prouve que l’utilisateur a accordé la permission d’accéder à une ressource donnée.

Format

Le format de l’access token dépend de l’implémentation :

• Tokens opaques : ils ne sont pas lisibles par les clients et doivent être validés par le serveur de ressources.
• JWT : certaines implémentations utilisent le format JWT, lisible, qui contient des claims sur l’étendue de l’accès (scope), l’identité de l’utilisateur et les informations d’expiration.

Pour choisir entre JWT et tokens opaques dans un contexte machine à machine (M2M), consultez notre article JWT ou token opaque : quel est le meilleur choix pour le M2M ?.

Quand l’utiliser

Les access tokens sont destinés aux serveurs de ressources (API). Une application cliente inclut l’access token dans le header Authorization de la requête vers l’API, généralement sous la forme d’un Bearer token :

GET /api/resource HTTP/1.1
Host: api.example.com
Authorization: Bearer <access_token>

Le serveur de ressources valide le token pour s’assurer qu’il est actif et qu’il autorise bien l’action demandée.

Comment vérifier l’Access Token

Lorsque l’application cliente envoie un access token au serveur de ressources, celui-ci doit le valider. La validation peut se faire de plusieurs façons :

• Introspection : le serveur de ressources envoie une requête à l’endpoint d’introspection de tokens pour valider le token.
• Validation locale : le serveur de ressources valide le token localement avec la clé publique de l’IdP lorsque le token est au format JWT.
• Endpoint UserInfo : le serveur de ressources peut utiliser l’endpoint UserInfo pour récupérer des informations complémentaires sur l’utilisateur associé au token.

ID Token

Objectif

L’ID token est la pièce maîtresse d’OIDC. C’est un JSON Web Token (JWT) qui contient des claims sur la session d’authentification de l’utilisateur, comme son identité et la manière dont il s’est authentifié. L’application cliente l’utilise pour vérifier l’identité de l’utilisateur.

Format

L’ID token est toujours un JWT, composé de trois parties :

• Header : contient des métadonnées sur le token, comme l’algorithme de signature (par exemple RS256).
• Payload : contient des claims sur l’utilisateur et l’événement d’authentification, notamment :
  • sub : un identifiant unique de l’utilisateur.
  • iss : l’émetteur du token.
  • aud : l’audience à laquelle le token est destiné.
  • iat, exp : les horodatages d’émission et d’expiration du token.
  • nonce : une valeur qui associe le token à la requête d’authentification d’origine, afin d’empêcher les attaques par rejeu (replay).
• Signature : garantit l’intégrité et l’authenticité du token, signé par l’IdP avec une clé privée.

L’ID token peut contenir des claims supplémentaires, comme auth_time (moment de l’authentification) ou acr (authentication context class reference). Pour en savoir plus sur les claims standards de l’ID token, consultez notre article sur les claims standards OpenID Connect.

Quand l’utiliser

L’ID token est utilisé exclusivement pour l’authentification. Il ne doit pas servir à accéder à des API ou à des ressources. Par exemple, une application web peut s’en servir pour afficher le profil de l’utilisateur ou établir une session.

Le plus souvent, l’access token contient suffisamment d’informations pour identifier l’utilisateur. L’ID token reste toutefois utile lorsque l’application cliente doit vérifier l’identité de l’utilisateur ou obtenir des informations supplémentaires sur l’événement d’authentification (par exemple la méthode d’authentification utilisée). Lorsque l’access token n’est pas au format JWT, l’ID token est plus simple à lire et à analyser, puisqu’il est toujours un JWT.

Un exemple concret d’utilisation de l’ID token est le processus de step-up authentication. Pour savoir comment l’implémenter avec OpenID Connect, consultez notre article sur la Step-Up Authentication avec OpenID Connect.

Comment vérifier l’ID Token

Pour vérifier l’ID token, l’application doit le traiter comme un JWT : valider la signature et contrôler les claims. Elle doit aussi s’assurer que le claim iss correspond à l’IdP attendu, que le claim aud correspond au client ID (ou à la valeur attendue définie par le provider) et que le claim exp n’est pas expiré.

Pour en savoir plus sur la vérification d’un JWT, consultez notre article comment vérifier un JWT.

Refresh Token

Objectif

Le refresh token sert à obtenir de nouveaux access tokens sans obliger l’utilisateur à se réauthentifier. C’est particulièrement utile pour maintenir des sessions de longue durée.

Format

Les refresh tokens sont généralement des chaînes opaques, qui ne sont pas destinées à être analysées ou inspectées par le client. Contrairement aux ID tokens et aux access tokens, ce ne sont pas des JWT.

Quand l’utiliser

Les refresh tokens sont utilisés en arrière-plan pour renouveler les access tokens. Par exemple :

• L’utilisateur se connecte, et le client reçoit un access token et un refresh token.
• Lorsque l’access token expire, le client envoie le refresh token à l’IdP pour demander un nouvel access token.

Note : les refresh tokens doivent être stockés de manière sécurisée. S’ils sont compromis, ils peuvent permettre à un attaquant d’obtenir de nouveaux access tokens.

Durée de vie des tokens et considérations de sécurité

Durée de vie des tokens

Chaque token a une durée de vie propre, définie par l’IdP. Elle peut varier selon les exigences de sécurité de l’application.

• Access Token : durée de vie généralement courte pour limiter l’exposition en cas de fuite (par exemple 5 à 15 minutes).
• ID Token : durée de vie généralement courte (de quelques minutes à quelques heures), car il n’est utilisé que pendant le processus d’authentification.
• Refresh Token : durée de vie plus longue que les access tokens (de quelques jours à plusieurs mois) pour maintenir des sessions longues, mais il doit pouvoir être révoqué par le provider.

Lors de l’implémentation d’OpenID Connect, gardez à l’esprit les bonnes pratiques (best practices) de sécurité suivantes :

• Stockage sécurisé : stockez les tokens de manière sécurisée, par exemple dans des cookies HTTP-only ou des mécanismes de stockage sécurisés.
• Validation des tokens : assurez-vous que les tokens sont validés pour vérifier leur authenticité et leur intégrité.
• Utilisation de HTTPS : transmettez toujours les tokens en HTTPS pour éviter leur interception.
• Rotation des clés : effectuez régulièrement la rotation des clés cryptographiques utilisées pour signer les tokens.
• Scopes minimaux : ne demandez que les scopes nécessaires afin de limiter les capacités du token.

Ressources

• OpenID Connect Core 1.0 ID Token Validation