Qu'est-ce que Jeton opaque?

Qu’est-ce qu’un jeton ?

Avant d’introduire les jetons opaques, il est important de comprendre ce qu’est un jeton :

Les jetons sont utilisés pour représenter et transmettre des informations sécurisées entre les parties, et ils soutiennent la grande majorité des processus d’ Authentification (Authentication) et d’ Autorisation (Authorization) qui se produisent sur Internet en coulisses. Les deux types de jetons les plus populaires dans les services web sont les JSON Web Token (JWT) et les jetons opaques.

Qu’est-ce qu’un jeton opaque ?

Les jetons opaques sont des jetons dans un format propriétaire auquel vous ne pouvez pas accéder et contiennent généralement un identifiant pour des informations dans le stockage persistant d’un serveur.

Un jeton opaque est une forme que peut prendre un jeton, et les jetons d’accès et les jetons de rafraîchissement peuvent exister sous forme de jetons opaques. Le format d’un jeton opaque est déterminé par son issuer, et il s’agit généralement d’une chaîne de chiffres et/ou de caractères utilisée pour aider l’issuer à récupérer et identifier certaines informations dans une base de données. Voici un exemple de jeton opaque :

M-oxIny1RfaFbmjMX54L8Pl-KQEPeQvF6awzjWFA3iq

D’autre part, le JWT est un autre format de jeton courant. C’est une chaîne JSON qui contient toutes les claims et informations, ainsi qu’une signature de l’issuer. Par défaut, il n’est pas chiffré, bien qu’il puisse être chiffré en utilisant la norme JSON Web Encryption (JWE) . Même si le JWT n’est généralement pas chiffré, cela ne compromet pas sa sécurité — la présence de la signature garantit l’intégrité du contenu du jeton, permettant une confiance totale dans les données à l’intérieur du JWT.

Contrairement au JWT, qui contient toutes les informations nécessaires pour être validé directement à la ressource protégée, les jetons opaques ne peuvent pas être validés directement par la ressource. Au lieu de cela, ils nécessitent une validation par l’issuer du jeton opaque (généralement le Serveur d'autorisation (Authorization server) ). Ce processus de validation est généralement appelé Introspection de jeton (Token introspection) .

Qu’est-ce qu’un JWT ?

Contrairement aux jetons opaques, un JWT est un jeton autonome et sans état qui transporte des informations dans un format structuré et lisible.

Un JWT est composé de trois parties : un header, un payload et une signature, chacun encodé en Base64URL.

Voici un exemple de JWT :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

• Le header contient des informations sur le type de jeton et l’algorithme utilisé pour la signature. Par exemple, {"alg": "HS256", "typ": "JWT"}.
• La section payload contient des claims — des morceaux d’informations sur l’utilisateur ou l’autorisation — tels que l’ID utilisateur, le temps d’expiration et les scopes. Étant donné que ces données sont encodées mais non chiffrées, quiconque possède le jeton peut le décoder pour voir les claims, bien qu’il ne puisse pas les modifier sans invalider la signature. En fonction de la spécification et de la configuration du serveur d’autorisation, divers claims peuvent être inclus dans le payload. Cela donne au jeton sa nature autonome. Par exemple, {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}.
• La signature est générée en combinant le header, le payload et une clé secrète en utilisant l’algorithme spécifié. Cette signature est utilisée pour vérifier l’intégrité du jeton et s’assurer qu’il n’a pas été altéré.

Les JWT sont couramment utilisés car ils peuvent être vérifiés localement par le client ou tout service, sans avoir besoin d’interagir avec le serveur d’autorisation. Cela rend les JWT particulièrement efficaces pour les systèmes distribués, où plusieurs services pourraient avoir besoin de vérifier l’authenticité du jeton de manière indépendante.

Cependant, cette commodité s’accompagne également de la responsabilité de s’assurer que les claims du jeton ne sont pas excessivement exposés, car ils sont visibles par quiconque a accès au jeton. De plus, les JWT sont généralement de courte durée, et le temps d’expiration est inclus dans les claims du jeton pour s’assurer que le jeton n’est pas valide indéfiniment.

Validation des jetons d’accès opaques

Un jeton d’accès opaque est validé en le renvoyant au serveur d’autorisation pour vérification. Le serveur d’autorisation maintient l’état des jetons émis et peut déterminer la validité du jeton en fonction de son stockage interne.

1. Le client demande un jeton d’accès au serveur d’autorisation.
2. Le serveur d’autorisation émet un jeton opaque.
3. Le client envoie la demande d’accès à la ressource avec le jeton opaque dans l’en-tête.
4. Le fournisseur de ressources envoie une demande d’introspection de jeton au serveur d’autorisation pour valider le jeton.
5. Le serveur d’autorisation répond avec les informations du jeton.

Validation des jetons d’accès JWT (hors ligne)

Un jeton d’accès JWT peut être validé hors ligne par le client ou tout service qui a accès à la clé publique du jeton.

1. Le fournisseur de ressources pré-récupère la clé publique du serveur d’autorisation à partir de l’ Découverte OpenID Connect (OIDC) (OpenID Connect Discovery) . La clé publique est utilisée pour vérifier la signature du jeton et garantir son intégrité.
2. Le client demande un jeton d’accès au serveur d’autorisation.
3. Le serveur d’autorisation émet un jeton JWT.
4. Le client envoie la demande d’accès à la ressource avec le jeton JWT dans l’en-tête.
5. Le fournisseur de ressources décode et valide le jeton JWT en utilisant la clé publique obtenue du serveur d’autorisation.
6. Le fournisseur de ressources accorde l’accès en fonction de la validité du jeton.

Cas d’utilisation dans OIDC

Dans le contexte de l’OIDC ( OpenID Connect (OIDC) ), les jetons opaques et les JWT servent à des fins différentes et sont utilisés dans des scénarios distincts.

Jetons opaques

1. Récupération du profil utilisateur :

Par défaut, lorsqu’un client demande un jeton d’accès sans spécifier de ressource et inclut le scope openid, le serveur d’autorisation émet un jeton d’accès opaque. Ce jeton est principalement utilisé pour récupérer des informations de profil utilisateur à partir du point de terminaison /oidc/userinfo de l’OIDC. Lorsqu’il reçoit une demande avec le jeton d’accès opaque, le serveur d’autorisation vérifie son stockage interne pour récupérer les informations d’autorisation associées et vérifie la validité du jeton avant de répondre avec les détails du profil utilisateur.

2. Échange de jetons de rafraîchissement :

Les jetons de rafraîchissement sont conçus pour être échangés uniquement entre le client et le serveur d’autorisation, sans avoir besoin d’être partagés avec les fournisseurs de ressources. En tant que tels, les jetons de rafraîchissement sont généralement émis sous forme de jetons opaques. Lorsque le jeton d’accès actuel expire, le client peut utiliser le jeton de rafraîchissement opaque pour obtenir un nouveau jeton d’accès, garantissant un accès continu sans ré-authentifier l’utilisateur.

JWTs

1. Jeton ID :

Dans l’OIDC, le jeton ID est un JWT qui contient des informations utilisateur et est utilisé pour authentifier l’utilisateur. Généralement émis en même temps que le jeton d’accès, le jeton ID permet au client de vérifier l’identité de l’utilisateur. Par exemple :

// Payload décodé d'un jeton ID
{
  "iss": "<https://auth.wiki>",
  "sub": "1234567890",
  "aud": "client_id",
  "exp": 1630368000,
  "name": "John Doe",
  "email": "[email protected]",
  "picture": "<https://example.com/johndoe.jpg>"
}

Le client peut valider le jeton ID pour s’assurer de l’identité de l’utilisateur et extraire des informations utilisateur pour la personnalisation ou à des fins d’autorisation. Le jeton ID est à usage unique et ne doit pas être utilisé pour l’autorisation des ressources API.

2. Accès aux ressources API (en utilisant le jeton d’accès) :

Lorsqu’un client demande un jeton d’accès avec un Indicateur de ressource (Resource indicator) spécifique, le serveur d’autorisation émet un jeton d’accès JWT destiné à accéder à cette ressource. Le JWT contient des claims que le fournisseur de ressources peut utiliser pour autoriser l’accès du client. Par exemple :

// Payload décodé d'un jeton d'accès JWT
{
  "iss": "<https://auth.wiki>",
  "sub": "1234567890",
  "aud": "<https://api.example.com>",
  "scope": "read write",
  "exp": 1630368000
}

Le fournisseur de ressources peut valider la demande en vérifiant les claims :

• iss: Confirme que le jeton a été émis par un serveur d’autorisation de confiance.
• sub: Identifie l’utilisateur associé au jeton.
• aud: S’assure que le jeton est destiné à la ressource spécifique.
• scope: Vérifie les permissions accordées à l’utilisateur.

Voir aussi

• JSON Web Token (JWT)