oauth 2.0oidc

Qu'est-ce que Jeton opaque?

Un jeton opaque est une chaîne aléatoire et unique qui est dénuée de sens pour le client mais sert de clé de référence pour rechercher des données d'autorisation dans la base de données du serveur.

Qu’est-ce qu’un jeton opaque ?

Un jeton opaque est une chaîne aléatoire et unique qui est dénuée de sens pour le client mais sert de clé de référence pour rechercher des données d’autorisation dans la base de données du serveur.

Les jetons opaques sont généralement générés à l’aide d’un Générateur de nombres pseudo-aléatoires cryptographiquement sécurisé pour garantir leur imprévisibilité et leur sécurité, et leur format est déterminé par leur issuer (émetteur).

Voici un exemple de jeton opaque :

M-oxIny1RfaFbmjMX54L8Pl-KQEPeQvF6awzjWFA3iq

Quelle est la différence entre JWT (JSON Web Token) et jeton opaque ?

La principale différence réside dans la manière dont ces jetons gèrent et valident les informations d’autorisation :

Un jeton opaque est une chaîne aléatoire qui ne contient aucune information en elle-même. Le serveur doit interroger sa base de données pour récupérer toutes les données d’autorisation associées à ce jeton. Cela rend les jetons opaques complètement dépendants de l’authorization server (serveur d’autorisation) pour la validation et l’interprétation.

Le JWT est un jeton autonome qui contient toutes les informations nécessaires en lui-même.

Voici un exemple de JWT, c’est une chaîne encodée en base64 :

eyJhbGciOiJIUzI1NiIs.eyJzdWIiOiIxMjM0NTY3O.SflKxwRJSMeKKF2QT4f

Et il contient trois parties séparées par des points :

Header - Contient des informations sur le type de jeton et l’algorithme utilisé pour la signature. Par exemple, {"alg": "HS256", "typ": "JWT"}.
Payload - Contient des claims (revendications) — des informations sur l’utilisateur ou l’autorisation, comme l’ID utilisateur, le temps d’expiration et les scopes (périmètres). Tout le monde peut le décoder pour voir les claims car il est encodé mais non chiffré.
Signature - 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é.

Cette structure permet aux JWT d’être validés et utilisés sans interroger une base de données.

Pour plus d’informations détaillées sur les JWT, veuillez vous référer à JSON Web Token (JWT) .

Et consultez Jeton opaque vs JWT pour en savoir plus sur leurs différences en profondeur.

Comment valider un jeton opaque

Dans les systèmes simples, la validation des jetons opaques est généralement gérée directement par le serveur, qui interroge la base de données en utilisant le jeton opaque comme clé pour récupérer les informations d’autorisation associées.

Dans les systèmes multipartites introduisant OAuth 2.0, plusieurs resource servers (serveurs de ressources) (voir : Serveur de ressources (Resource server) ) peuvent avoir besoin de valider le même jeton opaque. OAuth 2.0 fournit un mécanisme standardisé de token introspection (introspection de jeton) pour cette validation :

Pour des informations détaillées sur l’introspection de jeton, veuillez vous référer à Introspection de jeton (Token introspection) .

Comment les jetons opaques sont-ils utilisés dans OIDC ?

Dans le contexte de OIDC ( OpenID Connect (OIDC) ), les jetons opaques servent des objectifs spécifiques dans différents scénarios :

Récupération de profil utilisateur

Par défaut, lorsqu’un client demande un access token (jeton d’accès) sans spécifier de ressource et inclut le scope openid, l’authorization server émet un jeton d’accès opaque. Ce jeton est principalement utilisé pour récupérer des informations de profil utilisateur à partir de l’endpoint /oidc/userinfo de OIDC (voir : Point de terminaison userinfo (Userinfo endpoint) ).

Échange de refresh token

Les refresh tokens (jetons de rafraîchissement) (voir : Jeton d'actualisation (Refresh token) ) sont généralement émis sous forme de jetons opaques car ils ne sont échangés qu’entre le client et l’authorization server. Lorsque le jeton d’accès actuel expire, le client peut utiliser le refresh token opaque pour obtenir un nouveau jeton d’accès sans ré-authentifier l’utilisateur.

Quels sont les avantages et les inconvénients des jetons opaques ?

Avantages

Sécurité : Les jetons opaques sont parfaits pour gérer des données sensibles comme les refresh tokens. Étant donné que le contenu est complètement aléatoire et dénué de sens, même si quelqu’un intercepte le jeton, il ne peut extraire aucune information utile. Cela les rend particulièrement précieux dans des scénarios de haute sécurité comme les transactions bancaires ou la gestion de données utilisateur sensibles.
Révocabilité : Le serveur peut invalider immédiatement un jeton opaque à tout moment. Cela est particulièrement utile lorsque vous devez rapidement supprimer l’accès d’un utilisateur. Contrairement aux JWT qui restent valides jusqu’à leur expiration, les jetons opaques peuvent être révoqués instantanément (voir : Limitations des JWT ).
Taille : Les jetons opaques sont généralement beaucoup plus courts que les JWT. Cette taille réduite diminue l’utilisation de la bande passante réseau et les besoins de stockage. Le bénéfice devient particulièrement notable dans les systèmes qui transmettent fréquemment des jetons, tels que les applications mobiles ou les appareils IoT.
Simplicité : L’implémentation des jetons opaques est simple. Vous générez une chaîne aléatoire et la stockez avec ses données associées. Il n’est pas nécessaire de gérer un chiffrement complexe ou une vérification de signature comme avec les JWT. Cette simplicité les rend idéaux pour l’authentification des systèmes internes.

Inconvénients

État : Chaque jeton opaque nécessite un stockage côté serveur. Cela crée une complexité supplémentaire dans les systèmes distribués car les données des jetons doivent être synchronisées entre plusieurs serveurs. Par exemple, si vous avez plusieurs serveurs d’authentification, ils doivent tous avoir accès à la même base de données de jetons ou au système de cache pour valider correctement les jetons.
Performance : La validation des jetons nécessite toujours une requête à la base de données ou un appel API. Dans les systèmes à fort trafic, ces requêtes supplémentaires à la base de données peuvent créer des goulots d’étranglement de performance. Par exemple, si votre système gère des milliers de requêtes par seconde, chacune nécessitant une validation de jeton, la charge supplémentaire sur la base de données devient significative.
Interopérabilité : Différents systèmes peuvent implémenter les jetons opaques de différentes manières. Cela peut causer des défis d’intégration lors du travail avec des services tiers ou différents authorization servers. Bien que des standards comme l’introspection de jeton OAuth 2.0 aident, vous pouvez toujours rencontrer des problèmes de compatibilité lorsque les systèmes utilisent différents formats de jetons ou méthodes de validation.