Qu’est‑ce que le JWT ? Guide clair sur les JSON Web Tokens

JWT en termes simples

Un JWT (JSON Web Token) est une chaîne compacte et sûre pour les URL qui représente un ensemble d’informations (généralement sur un utilisateur ou une session) et qui peut être transmise entre systèmes. On le voit souvent sous la forme d’une longue valeur commençant par quelque chose comme eyJ..., envoyée dans un en‑tête HTTP tel que Authorization: Bearer <token>.

Pourquoi utiliser un jeton ?

Les connexions traditionnelles reposent souvent sur des sessions serveur : après la connexion, le serveur stocke des données de session et donne au navigateur un cookie d’identifiant de session. Chaque requête inclut ce cookie et le serveur consulte la session.

Avec l’auth par jeton, le serveur peut éviter de garder l’état de session pour chaque requête utilisateur. Le client conserve un jeton (comme un JWT) et l’inclut dans les appels d’API. Cela est populaire pour les API parce que :

• cela fonctionne bien entre plusieurs services (passerelles d’API, microservices)
• cela convient aux applications mobiles et aux SPA qui appellent les API directement
• cela réduit le besoin d’un stockage de session partagé entre serveurs

Nuance importante : « sans état » ne signifie pas « aucune vérification côté serveur ». De nombreux systèmes valident encore les jetons en fonction du statut de l’utilisateur, de la rotation des clés ou de mécanismes de révocation.

Authentification vs autorisation (en clair)

• Authentification répond : Qui êtes‑vous ? (vous vous connectez et prouvez votre identité.)
• Autorisation répond : Que pouvez‑vous faire ? (lire des factures, modifier des projets, accéder à des pages admin, etc.)

Les JWT contiennent souvent une preuve d’authentification (vous êtes connecté) et des indices d’autorisation basiques (rôles, permissions, scopes) — mais votre serveur doit toujours appliquer les règles d’autorisation.

Où apparaissent les JWT

On utilise souvent les JWT comme jetons d’accès dans :

• les API web
• les SPA
• les applications mobiles
• les systèmes utilisant OAuth 2.0 ou OpenID Connect (OIDC)

Structure du JWT : en‑tête, charge utile et signature

Un JWT est une chaîne compacte composée de trois parties, chacune encodée en Base64URL et séparée par des points :

header.payload.signature

Exemple (raccourci) :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwiaWF0IjoxNzAwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c…

1) En‑tête

L’en‑tête décrit comment le jeton a été créé — principalement l’algorithme de signature (par ex. HS256, RS256/ES256) et le type de jeton.

Champs courants :

• typ : souvent "JWT" (fréquemment ignoré en pratique)
• alg : l’algorithme de signature utilisé
• kid : identifiant de clé pour aider le vérificateur à choisir la bonne clé lors d’une rotation

Note de sécurité : ne faites pas aveuglément confiance à l’en‑tête. Imposer une allowlist des algorithmes réellement utilisés et n’acceptez pas alg: "none".

2) Charge utile

La charge utile contient des « claims » sur l’utilisateur et le contexte du jeton : pour qui il est, qui l’a émis et quand il expire.

Important : les JWT ne sont pas chiffrés par défaut. L’encodage Base64URL rend le jeton sûr pour les URL ; il ne cache pas les données.

C’est pourquoi vous devez éviter d’y placer des secrets (mots de passe, clés API) ou des données personnelles sensibles.

3) Signature

La signature est créée en signant l’en‑tête + la charge utile avec une clé :

• HS256 : un secret partagé signe et vérifie
• RS256/ES256 : une clé privée signe ; une clé publique vérifie

La signature fournit l’intégrité : elle permet de vérifier que le jeton n’a pas été modifié et qu’il a été émis par un signataire de confiance. Elle ne fournit pas de confidentialité.

Considérations de taille

Parce qu’un JWT inclut l’en‑tête et la charge utile à chaque requête où il est envoyé, des jetons plus gros signifient plus de bande passante et de surcharge. Gardez les claims légers et préférez des identifiants plutôt que des données volumineuses.

Charge utile et claims : que stocker (et ne pas stocker)

Les claims se divisent généralement en deux catégories : enregistrés (noms standardisés) et personnalisés (champs propres à votre application).

Claims enregistrés courants

• iss (issuer) : qui a créé le jeton
• sub (subject) : à qui le jeton se rapporte (souvent un ID utilisateur)
• aud (audience) : pour qui le jeton est destiné (ex. une API spécifique)
• exp (expiration time) : quand le jeton ne doit plus être accepté
• iat (issued at) : quand le jeton a été créé
• nbf (not before) : le jeton ne doit pas être accepté avant cette heure

Claims personnalisés : gardez‑les minimaux

Incluez seulement ce dont le service destinataire a réellement besoin pour prendre une décision d’autorisation.

Bons exemples :

• un identifiant interne stable (user_id)
• un petit ensemble de rôles/permissions (si vous pouvez les tenir à jour)
• un ID de locataire/organisation dans les applications multi‑locataires

Évitez les claims « de commodité » qui dupliquent beaucoup de données de profil. Ils alourdissent le jeton, se périment rapidement et augmentent l’impact en cas de fuite.

Ce qu’il ne faut jamais mettre dans la charge utile

Comme la charge utile est lisible, n’y stockez pas :

• mots de passe, clés API, refresh tokens ou toute valeur secrète
• détails de paiement, numéros d’identité gouvernementaux ou données personnelles sensibles
• tout ce que vous ne voudriez pas voir copié depuis un navigateur, un proxy ou un log

Si vous avez besoin d’informations sensibles, stockez‑les côté serveur et mettez seulement une référence (par ex. un ID) dans le jeton — ou utilisez un format chiffré (JWE) si nécessaire.

Comment fonctionne la signature (et ce qu’elle garantit)

Signer n’est pas chiffrer.

• Signer ressemble à sceller une lettre : on peut la lire, mais on peut vérifier qu’elle n’a pas été altérée.
• Chiffrer ressemble à enfermer la lettre dans une boîte verrouillée : seul celui qui a la clé peut la lire.

Quand un JWT est émis, le serveur signe l’en‑tête + la charge utile encodés. Quand le jeton est présenté plus tard, le serveur recalcule la signature et la compare. Si quelqu’un change une seule valeur (par ex. "role":"user" en "role":"admin"), la vérification échoue et le jeton est rejeté.

JWT vs OAuth, OpenID Connect et types de jetons

JWT est un format de jeton. OAuth 2.0 et OpenID Connect (OIDC) sont des protocoles qui décrivent comment les apps demandent, émettent et utilisent des jetons.

OAuth 2.0 et access/refresh tokens

OAuth 2.0 concerne principalement l’autorisation : permettre à une application d’accéder à une API au nom d’un utilisateur sans partager le mot de passe.

• Access token : présenté à une API pour prouver la permission ; peut être un JWT ou un jeton opaque
• Refresh token : jeton de plus longue durée utilisé pour obtenir de nouveaux access tokens

Les access tokens sont typiquement de courte durée (minutes). Des durées courtes limitent les dégâts en cas de fuite.

OpenID Connect (OIDC) et ID tokens

OIDC ajoute l’authentification (qui est l’utilisateur) par‑dessus OAuth 2.0 et introduit un ID token, qui est généralement un JWT.

• ID token : pour que l’application cliente confirme l’identité de l’utilisateur
• Access token : pour que l’API autorise les requêtes

Règle clé : n’utilisez pas un ID token pour appeler une API.

Si vous voulez plus de contexte sur des flux pratiques, voir /blog/jwt-authentication-flow.

Flux d’authentification JWT courant

Un flux typique ressemble à ceci :

1) Connexion

L’utilisateur se connecte (email/mot de passe, SSO, etc.). Si la connexion réussit, le serveur crée un JWT (souvent un access token) avec des claims essentiels comme le sujet et l’expiration.

2) Émission du jeton

Le serveur signe le jeton et le renvoie au client (application web, mobile ou un autre service).

3) Appels API

Pour les endpoints protégés, le client inclut le JWT dans l’en‑tête Authorization :

Authorization: Bearer <JWT>

4) Vérification

Avant de répondre, l’API vérifie généralement :

• la signature (intégrité + émetteur de confiance)
• exp (non expiré)
• iss (émetteur attendu)
• aud (destiné à cette API)

Si toutes les vérifications passent, l’API considère l’utilisateur comme authentifié et applique les règles d’autorisation (par ex. permissions au niveau des enregistrements).

5) Petit mot sur le décalage d’horloge

Les horloges système dérivent parfois : beaucoup de systèmes autorisent un petit décalage d’horloge lors de la validation des claims temps comme exp (et parfois nbf). Gardez ce skew petit pour ne pas prolonger la validité des jetons plus que prévu.

Où stocker les JWT en toute sécurité

Le choix de stockage change ce que les attaquants peuvent voler et à quel point ils peuvent rejouer un jeton.

Applications navigateur : mémoire vs localStorage vs cookies

Stockage en mémoire (souvent recommandé pour les SPA) : conserve l’access token dans l’état JS. Il est effacé au rafraîchissement et réduit le risque de “vol ultérieur”, mais une faille XSS peut toujours le lire pendant l’exécution. Associez‑le à des access tokens de courte durée et à un flux de rafraîchissement.

localStorage/sessionStorage : faciles mais risqués : toute vulnérabilité XSS peut exfiltrer les tokens. Si vous les utilisez, la prévention XSS est impérative (CSP, échappement, hygiène des dépendances) et gardez les tokens courts.

Cookies sécurisés (souvent le choix le plus sûr pour le web) : stockez les jetons dans un cookie HttpOnly pour que JavaScript ne puisse pas les lire — réduisant l’impact d’un vol via XSS. L’inconvénient est le risque CSRF, puisque les navigateurs joignent automatiquement les cookies.

Si vous utilisez des cookies, définissez :

• HttpOnly
• Secure (HTTPS seulement)
• SameSite=Lax ou SameSite=Strict (certains flux inter‑sites peuvent nécessiter SameSite=None; Secure)

Envisagez aussi des tokens CSRF pour les requêtes modifiantes.

Applications mobiles : privilégiez le stockage sécurisé de l’OS

Sur iOS/Android, stockez les tokens dans un stockage sécurisé (Keychain / Keystore). Évitez les fichiers en clair ou les préférences. Si votre modèle de menace inclut des appareils rootés/jailbreakés, assumez l’extraction possible et reposez‑vous sur des tokens de courte durée et des contrôles côté serveur.

Moindre privilège

Limitez ce qu’un jeton peut faire : utilisez des scopes/claims minimaux, gardez les access tokens de courte durée et évitez d’embarquer des données sensibles.

Pièges de sécurité JWT courants à éviter

Les JWT sont pratiques, mais de nombreux incidents proviennent d’erreurs prévisibles. Traitez un JWT comme de l’argent liquide : celui qui l’obtient peut souvent le dépenser.

1) Durées d’expiration trop longues

Si un jeton dure des jours ou des semaines, une fuite donne à un attaquant toute cette fenêtre.

Préférez des access tokens de courte durée (minutes) et renouvelez‑les via un mécanisme plus sûr. Pour un « se souvenir de moi », utilisez des refresh tokens et des contrôles côté serveur.

2) Sauter les vérifications d’issuer et d’audience

Une signature valide ne suffit pas. Vérifiez iss et aud, et validez les claims temporels comme exp et nbf.

3) Faire confiance aux données décodées

Décoder n’est pas vérifier. Vérifiez toujours la signature côté serveur et appliquez les permissions côté serveur.

4) Confusion d’algorithme et erreurs de clé

• N’acceptez pas l’algorithme que le jeton prétend utiliser sans vérification. Imposer une allowlist d’algorithmes.
• Ne mélangez pas clés symétriques (HS256) et clés asymétriques (RS256/ES256).
• Minimisez le blast radius en séparant les clés par environnement et en les faisant tourner.

5) Fuites de jetons via URLs, logs et referrers

Évitez de mettre des JWT dans les paramètres de requête. Ils peuvent finir dans l’historique du navigateur, les logs serveur, les outils d’analytics et les en‑têtes Referer.

Utilisez Authorization: Bearer ... à la place.

6) Pas de plan de rotation ou de révocation de clés

Supposez que les clés et les jetons peuvent fuir. Faites tourner les clés de signature, utilisez kid pour supporter une rotation fluide et ayez une stratégie de révocation (expirations courtes + capacité à désactiver comptes/sessions). Pour des conseils de stockage, voir /blog/where-to-store-jwts-safely.

Quand utiliser JWT (et quand ne pas l’utiliser)

Les JWT sont utiles, mais ne sont pas automatiquement le meilleur choix. La vraie question est de savoir si vous bénéficiez d’un jeton autonome qui peut être vérifié sans interroger la base de données à chaque requête.

Cas adaptés aux JWT

• API sans état à grande échelle : vérification locale (signature + expiry) sans recherche de session par requête
• Plusieurs services / microservices : règles de vérification partagées et clés publiques distribuables
• SPA et applications mobiles : clients appelant les APIs directement
• Jetons d’accès de courte durée : réduit l’impact d’un vol

Quand JWT est un mauvais choix

• Révocation instantanée indispensable : les sessions sont plus simples si vous devez « déconnecter partout maintenant » sans infrastructure supplémentaire
• Vous devez transporter des données sensibles : les JWT typiques sont signés, pas chiffrés
• Jetons longue durée : ils sont de grande valeur et valent la peine d’être volés

Quand les cookies de session simples sont meilleurs

Pour les applications serveur‑rendu traditionnelles où l’invalidation est simple, les sessions côté serveur avec cookies HttpOnly sont souvent la valeur par défaut la plus simple et la plus sûre.

Checklist rapide de décision

Choisissez JWT si vous avez besoin d’une vérification sans état entre services et pouvez garder les jetons de courte durée.

Évitez JWT si vous avez besoin d’une révocation immédiate, prévoyez de mettre des données sensibles dans le jeton, ou pouvez utiliser des cookies de session sans friction.

Checklist pratique et FAQ

Checklist de vérification (ce qu’il faut vérifier à chaque fois)

1. La signature est valide

Vérifiez avec la clé correcte et l’algorithme attendu. Rejetez les signatures invalides — sans exception.

2. exp (expiration)

Assurez‑vous que le jeton n’est pas expiré.

3. nbf (not before)

Si présent, assurez‑vous que le jeton n’est pas utilisé trop tôt.

4. aud (audience)

Confirmez que le jeton était destiné à votre API/service.

5. iss (issuer)

Confirmez que le jeton vient de l’émetteur attendu.

6. Vérifications de sanity (recommandées)

Validez le format du jeton, imposez une taille maximale et rejetez les types de claims inattendus pour réduire les bugs liés aux cas limites.

Choisir HS256 vs RS256/ES256

• HS256 (clé symétrique) : un secret partagé signe et vérifie.

  • Bien pour : une application/API unique contrôlée par une seule équipe.
  • Attention : tout vérificateur qui connaît le secret peut aussi forger des jetons.

• RS256 / ES256 (clés asymétriques) : la clé privée signe ; la clé publique vérifie.

  • Bien pour : plusieurs services vérifiant des jetons ; distribution de clés publiques sans permettre la signature.
  • Remarque opérationnelle : la rotation est souvent plus sûre parce que seul le signataire détient la clé privée.

Règle générale : si plusieurs systèmes indépendants doivent vérifier les jetons (ou que vous ne faites pas entièrement confiance à chaque vérificateur), préférez RS256/ES256.

Supervision et logging (sans fuiter de jetons)

• Ne loggez pas les jetons bruts (en‑têtes, cookies, query strings).
• Si vous avez besoin de corrélation, loggez une empreinte du jeton (ex. un hash) ou des métadonnées sûres (iss, aud, et un ID utilisateur seulement si la politique le permet).
• Surveillez les anomalies : échecs de signature, pics de jetons expirés, audiences/émetteurs inhabituels et schémas de refresh suspects.

FAQs

Les JWT sont‑ils chiffrés ?

Pas par défaut. La plupart des JWT sont signés, pas chiffrés : le contenu peut être lu par quiconque possède le jeton. Utilisez JWE ou évitez de mettre des données sensibles dans les JWT.

Puis‑je révoquer un JWT ?

Pas facilement si vous ne comptez que sur des access tokens autonomes. Approches courantes : access tokens de courte durée, listes de refus pour événements à haut risque, ou refresh tokens avec rotation.

Combien de temps doit durer exp ?

Aussi court que votre UX et votre architecture le permettent. Beaucoup d’APIs utilisent des minutes pour les access tokens, associées à des refresh tokens pour des sessions plus longues.

Construire des applications protégées par JWT plus rapidement avec Koder.ai

Si vous implémentez l’auth JWT dans une nouvelle API ou SPA, beaucoup de travail est répétitif : câbler le middleware, valider iss/aud/exp, définir les flags des cookies et éviter d’avoir du handling de jetons dans les logs.

Avec Koder.ai, vous pouvez générer rapidement une application web (React), des services backend (Go + PostgreSQL) ou une app mobile Flutter via un flux de travail basé sur le chat — itérer en mode planning, utiliser des snapshots et rollback pour affiner la sécurité, et exporter le code source quand vous êtes prêt. C’est un moyen pratique d’accélérer la construction de flux d’authentification JWT tout en gardant le contrôle sur la logique de vérification, la stratégie de rotation des clés et les paramètres de déploiement/hosting (y compris les domaines personnalisés).