Français

oidc
oauth
jwt
jeton opaque

Jeton opaque vs JWT

Comprendre les différences entre les jetons opaques et les JWT, leurs cas d'utilisation, et comment ils sont validés dans les systèmes basés sur l'OIDC.

Simeng

Developer

8/30/2024

Arrêtez de perdre des semaines sur l'authentification des utilisateurs

Lancez des applications sécurisées plus rapidement avec Logto. Intégrez l'authentification des utilisateurs en quelques minutes et concentrez-vous sur votre produit principal.

Commencer

Dans Logto, en tant que plateforme CIAM basée sur l’OIDC, les jetons d’autorisation jouent un rôle crucial dans la sécurisation des interactions utilisateur et la gestion de l’accès aux ressources. Parmi les différents types de jetons utilisés pour l'autorisation, les jetons opaques et les JWTs (JSON Web Tokens) sont les plus importants.

Nous avons reçu plusieurs questions de notre communauté, telles que : Quelle est la différence entre un jeton opaque et un JWT ? Pourquoi ne puis-je pas décoder le jeton d'accès que j'ai reçu, et pourquoi la longueur du jeton semble-t-elle courte ? Cet article de blog vise à clarifier ces concepts et à vous aider à comprendre les distinctions entre les jetons opaques et les JWTs, leurs cas d'utilisation, et pourquoi vous pourriez rencontrer des comportements différents en travaillant avec eux.

Qu'est-ce qu'un jeton opaque ?

Un jeton opaque est un type de jeton d'accès qui, comme son nom l'indique, est opaque ou non transparent pour le client ou toute partie externe. Cela signifie que le jeton lui-même ne contient aucune information lisible sur l'utilisateur ou l'autorisation accordée.

Lorsque vous recevez un jeton opaque, il apparaît souvent comme une suite apparemment aléatoire de caractères, et toute tentative de le décoder ne donnera pas de données significatives.

Voici un exemple de jeton opaque :

Étant donné que le contenu réel du jeton n'est connu que du serveur d'autorisation qui l'a émis, pour valider un jeton opaque, le client doit le renvoyer au serveur, qui vérifie ensuite son authenticité et détermine les autorisations associées. Cette approche garantit que les informations sensibles restent cachées, offrant une couche de sécurité supplémentaire, mais elle nécessite également une communication serveur supplémentaire pour valider le jeton.

Avantages :

sécurisé : Les jetons opaques ne divulguent aucune information sensible au client. Le contenu du jeton est seulement connu du serveur d'autorisation.
révocable : Étant donné que le jeton est stocké sur le serveur, et que le seul moyen de le valider est via le point de terminaison d'introspection sur le serveur d'autorisation, le serveur peut facilement révoquer le jeton si nécessaire et empêcher un accès non autorisé.
petite taille : Les jetons opaques sont généralement plus courts que les JWTs, ce qui peut être bénéfique pour les considérations de performance et de stockage.

Inconvénients :

étatful : Les jetons opaques nécessitent que le serveur d'autorisation maintienne un état pour valider le jeton, ce qui peut introduire une complexité et une surcharge supplémentaires.
performance : La nécessité d'une communication serveur supplémentaire pour valider le jeton peut affecter les performances, surtout dans des scénarios de trafic élevé.

Qu'est-ce qu'un JWT ?

Contrairement aux jetons opaques, un JWT (JSON Web Token) 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, chacune encodée 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 informations sur l'utilisateur ou l'autorisation—telles que l'ID utilisateur, le temps d'expiration, et les portées. Comme ces données sont encodées mais non crypté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. Selon la spécification et 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 assurer qu'il n'a pas été altéré.

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

Cependant, cette commodité s'accompagne également de la responsabilité d'assurer que les claims du jeton ne sont pas excessivement exposées, car elles sont visibles pour quiconque ayant accès au jeton. De plus, les JWTs ont généralement une durée de vie courte, et le temps d'expiration est inclus dans les claims du jeton pour s'assurer que le jeton n'est pas valide indéfiniment.

Avantages :

sans état : Les JWTs sont autonomes et ne nécessitent pas de maintien d'un état côté serveur pour être validés.
compatibilité inter-services : Les JWTs peuvent être facilement partagés et vérifiés entre différents services, ce qui les rend idéals pour les systèmes distribués.
extensible : Le payload d'un JWT peut contenir des claims personnalisés, permettant une autorisation flexible et un partage d'informations.
standard : Les tokens JWT suivent un standard bien défini (RFC 7519), les rendant largement soutenus et interopérables.

Inconvénients :

exposition : Les claims dans un JWT sont visibles pour quiconque ayant accès au jeton, donc les informations sensibles ne devraient pas être incluses dans le payload.
grande taille : Les JWTs peuvent être plus gros que les jetons opaques en raison des informations supplémentaires qu'ils transportent, ce qui peut affecter la performance et les considérations de stockage. Les claims dans un token JWT devraient être réduits au minimum pour réduire la taille du jeton.
complexité de révocation : Étant donné que les JWTs sont sans état, ils sont généralement valides pour une courte période, et il n'y a pas de mécanisme intégré pour révoquer les jetons avant leur expiration, ce qui signifie qu'un token compromis peut rester valide jusqu'à son expiration.

Validation d'un jeton d'accès opaque

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 tokens émis et peut déterminer la validité du token en fonction de son stockage interne.

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

Validation d'un jeton d'accès JWT (hors ligne)

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

Le fournisseur de ressources pré-télécharge la clé publique du serveur d'autorisation à partir du point de découverte OIDC. La clé publique est utilisée pour vérifier la signature du jeton et garantir son intégrité.
Le client demande un jeton d'accès au serveur d'autorisation.
Le serveur d'autorisation émet un jeton JWT.
Le client envoie la demande d'accès à la ressource avec le jeton JWT dans l'en-tête.
Le fournisseur de ressources décode et valide le jeton JWT en utilisant la clé publique obtenue du serveur d'autorisation.
Le fournisseur de ressources accorde l'accès en fonction de la validité du jeton.

Cas d'utilisation dans l'OIDC

Dans le contexte de l'OIDC (OpenID Connect), les jetons opaques et les JWTs ont des finalités différentes et sont utilisés dans des scénarios distincts.

Jetons opaques

Récupération de profil utilisateur :

Par défaut, lorsqu'un client demande un jeton d'accès sans spécifier une ressource et inclut le champ 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 depuis le point de terminaison /oidc/userinfo de l'OIDC. Lors de la réception d'une requête 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.

Échange de jeton 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 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

ID token :

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

Le client peut valider l'ID token pour confirmer l'identité de l'utilisateur et extraire des informations utilisateur pour la personnalisation ou les fins d'autorisation. Le token d'ID est à usage unique et ne doit pas être utilisé pour l'autorisation des ressources API.

Accès aux ressources API :

Lorsqu'un client demande un jeton d'accès avec un indicateur de ressource 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 :

Le fournisseur de ressources peut valider la requête 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 : Assure que le jeton est destiné à la ressource spécifique.
scope : Vérifie les permissions accordées à l'utilisateur.

Conclusion

En résumé, les jetons opaques et les JWTs ont des finalités différentes dans les systèmes basés sur l'OIDC, avec les jetons opaques fournissant une approche sécurisée et étatful de l'autorisation et les JWTs offrant une alternative sans état et autonome. Comprendre les distinctions entre ces types de jetons et leurs cas d'utilisation est essentiel pour concevoir des mécanismes d'authentification et d'autorisation sécurisés et efficaces dans vos applications.

Découvrez plus de fonctionnalités de jetons d'accès dans Logto :

Essayez Logto aujourd'hui

Qu'est-ce qu'un jeton opaque ?#

Qu'est-ce qu'un JWT ?#

Validation d'un jeton d'accès opaque#

Validation d'un jeton d'accès JWT (hors ligne)#

Cas d'utilisation dans l'OIDC#

Jetons opaques#

JWTs#

Conclusion#

Qu'est-ce qu'un jeton opaque ?#

Qu'est-ce qu'un JWT ?#

Validation d'un jeton d'accès opaque#

Validation d'un jeton d'accès JWT (hors ligne)#

Cas d'utilisation dans l'OIDC#

Jetons opaques#

JWTs#

Conclusion#

Qu'est-ce qu'un jeton opaque ?

Qu'est-ce qu'un JWT ?

Validation d'un jeton d'accès opaque

Validation d'un jeton d'accès JWT (hors ligne)

Cas d'utilisation dans l'OIDC

Jetons opaques

JWTs

Conclusion

Qu'est-ce qu'un jeton opaque ?

Qu'est-ce qu'un JWT ?

Validation d'un jeton d'accès opaque

Validation d'un jeton d'accès JWT (hors ligne)

Cas d'utilisation dans l'OIDC

Jetons opaques

JWTs

Conclusion