JWT : qu'est-ce qu'un JSON Web Token, structure et utilisation

Qu'est-ce que JWT ?

JSON Web Token (JWT) est un standard ouvert (RFC 7519) qui définit un moyen compact et autonome de transmettre des informations entre parties sous la forme d'un objet JSON. Les informations dans JWT sont appelées claims — des déclarations sur le sujet (utilisateur) et des attributs supplémentaires. Chaque claim est une paire clé-valeur : identifiant utilisateur, rôle, date d'expiration, émetteur.

JWT est dit autonome car toutes les informations nécessaires à la vérification sont contenues dans le token lui-même. Le serveur n'a pas besoin d'accéder à une base de données ou à un stockage externe pour vérifier la validité du token — il suffit de vérifier la signature. Cette propriété rend JWT idéal pour les systèmes distribués et les architectures de microservices, où plusieurs services doivent authentifier des requêtes sans stockage de session partagé.

Selon Auth0, 2025, plus de 65 % des applications mobiles et web utilisent JWT comme format de token principal pour l'authentification API, dépassant les tokens opaques et les identifiants de session.

Structure de JWT : header, payload et signature

JWT se compose de trois parties séparées par des points : header.payload.signature. Chaque partie est un JSON encodé en Base64url. Examinons chaque partie en détail.

Header — algorithme et type de token

Header contient deux champs obligatoires : alg (algorithm — algorithme de signature) et typ (type — type de token, toujours «JWT»). L'algorithme peut être symétrique (HS256 — HMAC avec SHA-256) ou asymétrique (RS256 — RSA avec SHA-256, ES256 — ECDSA avec P-256). Les algorithmes asymétriques sont préférables car ils permettent au client de vérifier la signature sans posséder la clé secrète.

Exemple d'un header décodé :

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key-id-1"
}

Payload — claims et données

Payload contient des claims — des déclarations sur le sujet. Les claims sont divisés en trois types : enregistrés (iss, sub, aud, exp, nbf, iat, jti), publics (définis par le développeur dans le registre IANA) et privés (convenus entre les parties). sub (subject) est l'identifiant unique de l'utilisateur. exp (expiration) est l'horodatage d'expiration du token. iss (issuer) est l'émetteur du token.

{
  "sub": "user-abc-123",
  "iss": "https://auth.example.com",
  "aud": "my-mobile-app",
  "exp": 1812345678,
  "iat": 1812342078,
  "role": "premium_user"
}

Signature — vérification d'intégrité

Signature est créée en appliquant l'algorithme de signature à la concaténation du header et du payload à l'aide d'une clé secrète ou privée. La formule : HMACSHA256(base64UrlEncode(header) + «.» + base64UrlEncode(payload), secret) pour HMAC, ou RSASHA256(...) pour un algorithme asymétrique. Le destinataire calcule la signature de la même manière et la compare à celle reçue — si elles correspondent, les données n'ont pas été modifiées.

Comment fonctionne JWT : création et vérification

Le flux de travail avec JWT se compose de deux phases : la création (émission) du token par le serveur d'authentification et la vérification du token par le client ou le serveur de ressources. Le serveur d'authentification reçoit les identifiants de l'utilisateur, crée un payload avec des claims et le signe. Le JWT résultant est envoyé au client en réponse à une demande de connexion ou dans le corps de réponse OAuth 2.0 / OpenID Connect.

JWT dans l'authentification mobile

Dans les applications mobiles, JWT est utilisé de la manière suivante : après une connexion réussie, l'utilisateur reçoit un token d'accès au format JWT. L'application le stocke dans un stockage sécurisé (Keychain sur iOS, EncryptedSharedPreferences sur Android). À chaque requête à l'API, l'application ajoute l'en-tête Authorization : Bearer <token>. Le serveur API vérifie la signature JWT, extrait les claims et prend des décisions d'accès basées sur ceux-ci — sans interroger la base de données.

Selon Google Codelabs, 2025, l'utilisation de JWT dans Firebase Authentication réduit le nombre de requêtes au serveur d'authentification de 40 à 60 % par rapport aux tokens de session, car les données sont vérifiées localement sur chaque microservice. Ceci est particulièrement important pour les architectures à forte charge, où chaque milliseconde de latence impacte l'expérience utilisateur. À 50 000 requêtes par minute, le passage à JWT peut économiser jusqu'à 10 instances de serveur traitant les requêtes d'introspection.

JWT vs Session Token

JWT et Session Token résolvent le même problème — l'authentification des requêtes — mais diffèrent fondamentalement dans leur architecture. Session Token est une chaîne d'identification aléatoire qui fait référence aux données de session stockées sur le serveur (stateful). JWT est un token autonome contenant toutes les données en lui-même (stateless).

Avantages et inconvénients de JWT

JWT l'emporte dans les systèmes distribués : les microservices peuvent vérifier le token localement sans stockage partagé. Par exemple, dans une architecture à cinq microservices, chaque service vérifie JWT en 1–2 ms sans appel réseau, tandis qu'un session token nécessite une requête Redis centralisée à chaque demande, ajoutant 10–30 ms de latence. Cependant, JWT est difficile à révoquer — une fois émis, il est valide jusqu'à son expiration. Session Token est facile à révoquer en supprimant l'enregistrement de la BD ou de Redis.

Pour les applications mobiles, une approche combinée — JWT avec une courte durée de vie (15–30 minutes) et Refresh Token — offre un équilibre entre performances et sécurité. JWT est utilisé pour l'accès à l'API, tandis que le refresh token (généralement opaque) sert à obtenir de nouveaux JWT. Si un JWT est compromis, l'attaquant y a accès pendant 15–30 minutes ; si un refresh token est compromis, la session est bloquée par rotation et détection de réutilisation.

Sécurité de JWT

La sécurité de JWT dépend d'une implémentation correcte. La vulnérabilité la plus courante est l'attaque «alg none» : un attaquant modifie l'en-tête du token en «alg» : «none», et le serveur, sans vérifier l'algorithme, accepte le token falsifié. Protection : toujours vérifier que l'algorithme dans l'en-tête correspond à celui attendu (RS256, ES256), et rejeter les tokens avec alg : none.

Vulnérabilités courantes

Les vulnérabilités de JWT incluent également : clé secrète faible pour HMAC (cassée en minutes), fuite de clé privée (signer n'importe quelles données au nom du serveur), stockage de données sensibles dans le payload (JWT ne chiffre pas, il signe seulement), attaque par injection JWK header (injection d'une clé publique personnalisée). L'utilisation de bibliothèques fiables — Nimbus JOSE + JWT, jjwt (io.jsonwebtoken), PyJWT — réduit le risque d'exploitation de ces vulnérabilités.

Une mesure de sécurité supplémentaire est JWK Thumbprint (RFC 7638) : liaison d'une clé publique au token via une empreinte (thumbprint) dans l'en-tête. Si le serveur stocke l'empreinte attendue pour chaque client, l'injection JWK header devient impossible — le serveur rejette toute clé ne correspondant pas à celle enregistrée. L'OAuth Security Workshop 2025 recommande JWK Thumbprint comme protection obligatoire pour tous les JWT utilisés dans les applications financières et médicales.

Exemple de code : travailler avec JWT en Kotlin

La bibliothèque jjwt (auth0/java-jwt) permet de créer et vérifier des JWT dans une application Android en quelques lignes. Dans l'exemple ci-dessous, le serveur génère un token avec sub et role, et le client vérifie la signature. Pour le stockage sécurisé de la clé secrète sur le serveur, utilisez des variables d'environnement ou un HSM (Hardware Security Module) — stocker la clé dans le code ou un fichier de configuration est une grave erreur de sécurité.

Génération de JWT

val secret = "my-256-bit-secret-key-here"
val token = JWT.create()
    .withSubject("user-abc-123")
    .withIssuer("auth.example.com")
    .withClaim("role", "premium_user")
    .withExpiresAt(Date(System.currentTimeMillis() + 3600000))
    .sign(Algorithm.HMAC256(secret))

// Envoi du token au client
println("JWT : $token")

Vérification de JWT

fun verifyToken(token: String): Boolean {
    return try {
        val decoded = JWT.require(Algorithm.HMAC256(secret))
            .withIssuer("auth.example.com")
            .build()
            .verify(token)
        // Signature valide, claims extraits
        println("Subject : ${decoded.subject}")
        true
    } catch (e: Exception) {
        println("Token invalide : ${e.message}")
        false
    }
}