JWTs : Qu'est-ce qu'il y a vraiment dans ces longues chaînes

Tu vois une chaîne comme eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U dans ton système d'authentification.

Qu'est-ce que c'est ? C'est un JWT—trois morceaux encodés en Base64 séparés par des points. Et tu peux le lire sans aucune clé spéciale.

Les trois parties

En-tête : Algorithme et type de token

{"alg": "HS256", "typ": "JWT"}

Charge utile : Les données réelles (revendications)

{"sub": "1234567890", "name": "John", "iat": 1516239022}

Signature : Vérification que rien n'a été altéré

Les JWTs ne sont pas chiffrés

C'est le point important. N'importe qui peut décoder un JWT et lire son contenu. Base64 est de l'encodage, pas du chiffrement.

Ne mets pas de secrets dans les JWTs. IDs utilisateur, permissions, temps d'expiration—OK. Mots de passe, cartes de crédit, données privées—jamais.

Revendications standard

iss — Émetteur. Qui a créé ce token.

sub — Sujet. Généralement l'ID utilisateur.

exp — Expiration. Timestamp Unix quand le token devient invalide.

iat — Émis à. Quand le token a été créé.

aud — Audience. Qui devrait accepter ce token.

Les revendications personnalisées fonctionnent aussi. Ajoute toutes les données dont ton application a besoin.

Comment fonctionnent les signatures

La signature prouve que le token n'a pas été modifié.

Le serveur crée le token → signe avec clé secrète → envoie au client. Le client renvoie le token → le serveur vérifie la signature → fait confiance au contenu.

Si quelqu'un change la charge utile, la signature ne correspondra pas. Le serveur le rejette.

Mais le serveur doit vérifier la signature. Les JWTs sans vérification sont du théâtre de sécurité.

Erreurs de sécurité courantes

Ne pas vérifier les signatures. Certains codes décodent les JWTs sans vérifier la signature. N'importe qui peut forger des tokens.

Utiliser des secrets faibles. secret123 n'est pas un secret. Utilise des chaînes longues et aléatoires.

Ignorer l'expiration. Vérifie toujours exp. Les tokens devraient avoir des durées de vie courtes.

Confusion d'algorithme. Le champ alg dit comment vérifier. Les attaquants peuvent le mettre à none et sauter la vérification si ton code fait confiance à l'en-tête.

Stocker des données sensibles. N'importe qui avec le token peut lire la charge utile. Garde les secrets côté serveur.

Quand utiliser les JWTs

Authentification sans état. Le serveur n'a pas besoin de stocker de sessions. Le token contient tout ce qui est nécessaire.

Microservices. Les services peuvent vérifier les tokens sans appeler le serveur d'authentification.

Single sign-on. Partager l'authentification entre domaines.

Quand ne pas utiliser les JWTs

Applications simples. Les cookies de session sont plus simples et plus difficiles à gâcher.

Besoin d'invalider immédiatement. Les JWTs sont valides jusqu'à expiration. Révoquer nécessite une infrastructure supplémentaire.

Charges utiles volumineuses. Chaque requête porte le token complet. Les gros tokens signifient plus de bande passante.

Tokens de rafraîchissement

Les tokens d'accès devraient avoir une courte durée de vie (minutes à heures). Les tokens de rafraîchissement obtiennent de nouveaux tokens d'accès sans ré-authentification.

Stocke les tokens de rafraîchissement en sécurité. Ils sont durables et puissants.

---

Les JWTs sont pratiques mais nécessitent de la prudence. Comprends ce qu'ils contiennent, vérifie les signatures correctement, définis des expirations courtes, et ne mets jamais de données sensibles dans la charge utile.