OAuth 2.0, PKCE, JWT, JWK et JWKS apparaissent souvent dans la même architecture, mais ne désignent pas la même chose. Certains concernent l’autorisation, d’autres le format d’un jeton ou la représentation de clés cryptographiques.
GuideBonnes pratiquesIntermédiaire
OAuth 2.0, PKCE, JWT, JWK et JWKS : comprendre leurs rôles
Comprenez comment OAuth 2.0, PKCE, JWT, JWK et JWKS s’articulent sans les confondre : autorisation, jetons, clés publiques et vérification.
Afficher le sommaire
- OAuth 2.0 organise l’autorisation
- PKCE protège l’échange du code d’autorisation
- JWT est un format de jeton
- JWK et JWKS représentent des clés
- Comment les éléments s’enchaînent
- Confusions à éviter
- Un exemple de parcours OAuth avec PKCE
- Lire un JWT sans lui faire confiance
- Pourquoi un JWKS contient plusieurs clés
- Déboguer méthodiquement
- Checklist de validation
OAuth 2.0 organise l’autorisation
OAuth 2.0 est un cadre d’autorisation déléguée. Il permet à une application d’obtenir un accès limité sans demander à l’utilisateur de lui communiquer le mot de passe d’un autre service.
OAuth n’impose pas que chaque access token soit un JWT : le format du jeton est un choix distinct.
PKCE protège l’échange du code d’autorisation
PKCE ajoute une preuve temporaire au flux Authorization Code. Le client crée un code_verifier aléatoire et envoie un challenge dérivé. Lors de l’échange du code reçu, il doit présenter le verifier d’origine.
Le générateur PKCE permet de visualiser le couple verifier/challenge et la transformation S256.
PKCE ne chiffre pas un JWT et ne remplace pas TLS. Il protège une étape précise du flux d’autorisation.
JWT est un format de jeton
JWT définit une structure compacte composée de segments séparés par des points. Un JWT signé peut transporter des claims et une signature vérifiable.
L’inspecteur JWT, le décodeur JWT et l’encodeur JWT permettent d’examiner cette structure.
Décoder un JWT ne signifie pas vérifier sa signature. Le payload d’un JWT classique ne doit pas être considéré comme confidentiel simplement parce qu’il est encodé.
JWK et JWKS représentent des clés
JWK est une représentation JSON d’une clé cryptographique. Un JWKS est un ensemble de JWK, souvent publié pour permettre aux clients d’obtenir les clés publiques nécessaires à la vérification.
L’inspecteur JWK/JWKS aide à examiner type de clé, identifiants et paramètres.
Un en-tête JWT peut contenir un kid, utilisé pour sélectionner la clé correspondante dans un JWKS avant la vérification.
Comment les éléments s’enchaînent
- le client démarre un flux OAuth et crée les valeurs PKCE ;
- le serveur d’autorisation authentifie l’utilisateur et renvoie un code ;
- le client échange ce code avec le verifier PKCE ;
- le serveur renvoie des jetons, éventuellement des JWT ;
- le destinataire lit l’en-tête du JWT et choisit une clé dans le JWKS ;
- il vérifie la signature puis contrôle issuer, audience, expiration et autres règles.
Confusions à éviter
- OAuth n’est pas un format de jeton.
- PKCE n’est pas du chiffrement.
- Le payload d’un JWT n’est pas automatiquement confidentiel.
- Décoder n’est pas vérifier une signature.
- Un JWKS est un ensemble de clés, pas une liste de sessions.
L’essentiel est de distinguer protocole, conteneur et clés.
Un exemple de parcours OAuth avec PKCE
Imaginez une application cliente qui souhaite accéder à une API au nom d’un utilisateur. Elle crée d’abord un code_verifier aléatoire et en dérive un code_challenge. Le challenge part avec la demande d’autorisation, tandis que le verifier reste temporairement côté client.
Après authentification et consentement, le serveur d’autorisation renvoie un code. Pour l’échanger contre des jetons, le client doit présenter le verifier d’origine. Le serveur recalcule le challenge et vérifie qu’il correspond. Un code intercepté seul devient ainsi beaucoup moins utile.
Le jeton reçu peut être un JWT, mais ce n’est pas une obligation imposée par OAuth.
Lire un JWT sans lui faire confiance
Un JWT classique permet de décoder facilement son en-tête et son payload. C’est pratique pour examiner iss, aud, exp, nbf ou un kid. Mais cette lecture ne prouve pas que le contenu est authentique.
La validation doit notamment vérifier la signature avec la clé attendue, l’algorithme autorisé, l’émetteur, l’audience et les contraintes temporelles. Une application ne devrait pas accepter un algorithme simplement parce que le jeton l’annonce.
Pourquoi un JWKS contient plusieurs clés
Un serveur peut publier plusieurs clés, notamment pendant une rotation. Le kid présent dans l’en-tête d’un JWT aide le vérificateur à sélectionner la clé candidate dans le JWKS.
La rotation permet d’introduire une nouvelle clé avant de retirer l’ancienne, afin que les jetons déjà émis puissent encore être vérifiés pendant leur durée de vie prévue. Cela explique pourquoi « récupérer la première clé du JWKS » n’est pas une stratégie robuste.
Déboguer méthodiquement
Lorsqu’un flux échoue, séparez les étapes : vérifiez d’abord les URL et paramètres OAuth, puis la paire verifier/challenge PKCE, ensuite le contenu du jeton, et enfin la sélection de clé et la validation cryptographique.
Cette méthode évite de chercher un problème de JWT alors que l’échec se situe dans l’échange du code OAuth.
Checklist de validation
Pour PKCE, contrôlez l’aléa du verifier et la méthode de challenge attendue. Pour un JWT, contrôlez signature, algorithme, émetteur, audience et dates. Pour un JWKS, contrôlez l’origine du document, le kid et le type de clé.
Ces contrôles donnent à chaque élément sa vraie responsabilité et évitent de considérer « OAuth + JWT » comme une seule boîte noire.