logo
GeekFormat

Décodeur, Vérificateur et Générateur JWT

Encoded Token172 charsMis à jour 2026-07
header
payload
signature
Valid JWTHS256
Secret38 chars
Header
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}
Claims details4 items
sub· Sujet1234567890
name· NameJohn Doe
admin· Admintrue
iat· Émis à151623902218/01/2018 09:30:22
Header details2 items
algHS256HMAC (symétrique)
typ· TypeJWT
All operations run locally in your browser; the Token and key are never sent to any server.

Établi JWT en ligne gratuit : décodez, vérifiez et générez des JSON Web Tokens. Prend en charge 13 algorithmes (HS256 / RS256 / ES256 / PS256 / EdDSA, etc.). Clés PEM et JWK. Génération automatique de paires de clés. exp/iat/nbf analysés automatiquement. 100% côté client — le token ne quitte jamais votre navigateur.

Recommandations connexes

Cas d'utilisation

  • Décoder JWT en ligne : divisez rapidement un token lors du débogage de connexion OAuth 2.0 / OIDC pour inspecter l'algorithme du Header et les Claims du Payload
  • Vérifier les signatures JWT : utilisez un Secret / clé publique pour valider les signatures de token en temps réel et décider si un 401 est 'mauvaise signature', 'expiré' ou 'discordance d'algorithme'
  • Générer des JWTs de test pendant l'intégration : émettez un JWT dans le navigateur avec une paire de clés de test, sans avoir à demander au backend de modifier temporairement le code pour émettre un token
  • Conversion PEM ↔ JWK : l'IdP OIDC vous a donné du JWK mais le serveur a besoin de PEM (ou vice versa) — convertissez sur place au lieu d'écrire un script OpenSSL
  • Diagnostiquer 401 Unauthorized : parcourez l'expiration, la correspondance alg avec la passerelle, la correspondance de clé et le formatage PEM un par un
  • Comparer RS256 vs PS256 : de nombreux fournisseurs OIDC utilisent RS256 par défaut tandis qu'AWS SigV4 préfère PS256 — changez d'algorithmes avec la même paire de clés RSA et comparez les résultats
  • Apprendre le fonctionnement interne de JWT : changez l'alg, modifiez le Payload, échangez la clé dans le navigateur et regardez la signature se casser en temps réel — bien plus rapide que de lire le RFC

Fonctionnalités

  • Décoder + Vérifier + Générer en un seul endroit : collez un token pour séparer Header/Payload/Signature, changez d'algorithme et de clé pour vérifier la signature, modifiez les Claims et resignez pour produire un nouveau token — couvre toute la chaîne de dépannage JWT
  • 13 algorithmes pris en charge : HS256/HS384/HS512 (HMAC), RS256/RS384/RS512 (RSA-PKCS1-v1_5), ES256/ES384/ES512 (ECDSA), PS256/PS384/PS512 (RSA-PSS), EdDSA — couvre OAuth 2.0, OIDC, JWS, passerelles API et SSO d'entreprise
  • Formats PEM et JWK : les clés RSA, ECDSA et Ed25519 acceptent les chaînes PEM (avec en-têtes -----BEGIN PUBLIC KEY-----) et JSON JWK (champs kid/kty/n/e) — collez directement la sortie OIDC /.well-known/jwks.json
  • Multiples formes d'entrée pour le Secret HMAC : chaîne UTF-8 brute, octets hexadécimaux ou Secret encodé en Base64/Base64URL — changez en un clic, pour que 'ça ressemble au même mais la signature échoue' n'arrive jamais
  • Génération automatique de paires de clés : paires de clés RSA-2048, RSA-4096, P-256, P-384 et Ed25519 générées dans le navigateur, présentées aux formats PEM et JWK pour une utilisation immédiate dans les tests
  • Mise en évidence sémantique des Claims : exp / iat / nbf sont automatiquement convertis en temps lisible par l'homme avec l'état expiré / pas encore valide / émis mis en évidence ; alg / typ / kid dans le Header étiquetés individuellement
  • 100% côté client, zéro téléchargement : chaque analyse, vérification et signature s'exécute via l'API Web Crypto native du navigateur — les tokens, clés et payload ne quittent jamais le navigateur, conformément au principe de sécurité de 'ne jamais coller de tokens de production dans des outils en ligne aléatoires'
  • Copie en un clic : Header, Payload, Signature et le token nouvellement généré sont chacun copiables indépendamment pour la documentation, les tickets et les commandes curl

Comment utiliser

  1. Collez ou tapez le token : déposez la chaîne JWT dans la zone de saisie ; l'outil sépare automatiquement Header, Payload et Signature et affiche chacun en JSON formaté
  2. Sélectionnez l'algorithme : basculez entre HS256 / RS256 / ES256 / PS256 / EdDSA ; l'outil déduit de Header.alg et signale toute discordance
  3. Importez une clé : collez un Secret HMAC, une chaîne PEM ou un JSON JWK ; pour les algorithmes asymétriques, cliquez sur 'Générer une paire de clés' pour obtenir une clé de test immédiatement
  4. Vérifiez ou resignez : en mode Decode, vérifiez avec une clé publique et voyez '✅ signature valide / ❌ signature invalide' ; en mode Encode, modifiez les Claims et signez avec une clé privée pour produire un nouveau token

FAQ

Quelles sont les trois parties d'un JWT ?

Une chaîne JWT se compose de trois segments `Header.Payload.Signature`, chacun encodé en Base64URL. Le Header déclare l'algorithme (par exemple, HS256, RS256) et le type de token (typ: JWT) ; le Payload porte les Claims de l'utilisateur, les champs communs sont sub (ID utilisateur), iat (heure d'émission), exp (heure d'expiration), nbf (pas avant), aud (audience), iss (émetteur) ; la Signature est le résultat de la signature des deux premiers segments avec une clé, son but est la 'détection de falsification' pas la 'prévention d'écoute'.

Puis-je modifier le Payload après avoir décodé un JWT ?

Vous pouvez le voir et le modifier, mais **vous ne pouvez pas le falsifier**. Une fois que vous changez le Header ou le Payload, la Signature originale devient immédiatement invalide et le serveur la rejettera. Pour que le token modifié redevienne utilisable, vous devez **le resigner** avec le même algorithme et la bonne clé — c'est la raison pour laquelle cet outil fournit 'décoder + modifier + générer' en un seul endroit : décodez pour jeter un coup d'œil, modifiez ce que vous voulez et générez un nouveau token pour les tests immédiatement, sans avoir à demander au backend d'émettre temporairement.

Quelle est la différence entre HS256, RS256, ES256, PS256 et EdDSA ?

HS256 utilise HMAC avec un Secret partagé (symétrique), rapide mais nécessite une gestion sécurisée du Secret ; RS256 utilise des clés RSA privée/publique (asymétrique), adapté aux situations où le signataire et le vérificateur sont séparés ; PS256 utilise un remplissage RSA-PSS, plus sécurisé que RS256 ; ES256 utilise une courbe elliptique P-256, des signatures plus courtes et de meilleures performances ; EdDSA (normalement Ed25519) est très rapide et déterministe, recommandé pour les nouveaux protocoles comme OAuth 2.1.

Pourquoi mon JWT affiche-t-il une signature invalide ?

Les causes les plus courantes sont que la clé, le format du Secret, l'algorithme ou l'encodage Base64URL ne correspondent pas exactement. Un espace supplémentaire, un saut de ligne PEM, confondre Base64 avec Base64URL ou que le serveur utilise RS256 tandis que l'outil utilise HS256 fera échouer la vérification. Utilisez cet outil pour changer d'algorithmes et de formats de Secret et tester un par un.

La même clé RSA peut-elle vérifier RS256 et PS256 ?

Non. RS256 et PS256 utilisent des schémas de remplissage différents (PKCS1-v1_5 vs PSS). Même si la clé RSA est la même, ils ne peuvent pas se vérifier de manière croisée. Le signataire et le vérificateur doivent utiliser le même algorithme.

Qu'est-ce qu'une attaque alg:none ?

Un attaquant change le Header en `{"alg":"none"}` pour dire au serveur de ne pas vérifier la signature, ou change RS256 en HS256 et utilise la clé publique comme Secret HMAC pour tromper le serveur. Le serveur doit utiliser une liste blanche d'algorithmes (par exemple, `algorithms: ['RS256']`) et ne doit pas faire confiance au Header.alg du token pour décider de l'algorithme de vérification.

Comment convertir entre PEM et JWK ?

PEM est le format classique OpenSSL avec des lignes BEGIN/END, courant dans les configurations héritées ; JWK est au format JSON, courant dans OAuth 2.0 / OIDC. De nombreux IdP OIDC publient des clés publiques sur `/.well-known/jwks.json`. Cet outil prend en charge les deux formats et peut basculer entre eux.

Le navigateur peut-il vérifier directement les signatures JWT ?

Oui. L'API Web Crypto prend en charge HMAC, RSA, ECDSA, RSA-PSS et Ed25519 dans les navigateurs modernes, donc cet outil peut vérifier les signatures directement dans le navigateur sans télécharger le token.

Mon token est-il envoyé à un serveur ?

Non. L'analyse, la vérification et la signature se font dans le navigateur. Le panneau Network ne devrait afficher aucune requête contenant le token.

Puis-je stocker des données sensibles dans un JWT ?

Non. Le Payload est lisible par défaut (il suffit de décoder Base64URL). Les mots de passe, pièces d'identité, numéros de carte, clés API, Access Tokens ou Refresh Tokens ne doivent pas être placés dans un JWT standard. Si vous avez besoin de confidentialité, envisagez JWE (JSON Web Encryption).

Qu'est-ce que Décodeur, Vérificateur et Générateur JWT ?

JWT (JSON Web Token) est une norme ouverte définie par l'IETF dans la RFC 7519 (la RFC 7515 décrit la forme de signature JWS, la RFC 7516 décrit le chiffrement JWE, la RFC 7517 définit les clés JWK) pour transférer en toute sécurité des informations utilisateur 'affirmées' entre les requêtes HTTP, les flux OIDC et les appels de microservices. Une chaîne JWT standard se compose de trois segments encodés en Base64URL : Header (algorithme et type), Payload (Claims, les données utilisateur) et Signature (une signature basée sur une clé sur les deux premiers). Les trois segments sont joints par un point littéral `.`, par exemple `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`.

**JWT n'est pas du chiffrement.** C'est l'idée fausse la plus courante. Le Payload est en texte clair par défaut — n'importe qui peut le décoder avec Base64URL et lire le contenu. JWT fournit une **détection de falsification**, pas de la confidentialité : le serveur resigne Header.Payload avec la clé partagée et la compare à la Signature du token. Si elles correspondent, le token n'a pas été modifié en transit. C'est la métaphore du 'billet de train avec un tampon anti-contrefaçon' : l'inspecteur se soucie de savoir si le billet est authentique, pas si le code QR est illisible.

JWT divise clairement les responsabilités entre 13 algorithmes. **Famille HMAC** (HS256/HS384/HS512) utilise une clé symétrique à la fois pour signer et vérifier, rapide et simple, adaptée à un seul service ou à un cluster de confiance ; le secret doit avoir au moins la longueur du digest (par exemple, ≥ 32 octets pour HS256). **Famille RSA** (RS256/RS384/RS512) utilise RSASSA-PKCS1-v1_5, le schéma asymétrique le plus courant — les signataires détiennent la clé privée, les vérificateurs détiennent la clé publique. **Famille RSA-PSS** (PS256/PS384/PS512) utilise le remplissage RSA-PSS plus récent avec des garanties de sécurité plus fortes, préféré par AWS SigV4 et les fournisseurs d'identité OIDC modernes. **Famille ECDSA** (ES256/ES384/ES512) utilise des courbes elliptiques (P-256/P-384/P-521 respectivement) avec des signatures plus courtes et de meilleures performances. **EdDSA** (principalement Ed25519) est extrêmement rapide et déterministe (même message + même clé = même signature à chaque fois) et est l'algorithme recommandé dans OAuth 2.1 et les nouveaux protocoles.

La sécurité est là où JWT trébuche en production. La OWASP JWT Cheat Sheet souligne au moins quatre règles strictes : (1) ne jamais mettre de mots de passe, de pièces d'identité, de numéros de carte ou de clés API en texte clair dans le Payload ; (2) le serveur **ne doit jamais faire confiance au champ alg** déclaré dans le Header du Token — il doit vérifier avec un algorithme codé en dur, sinon un attaquant qui réécrit l'en-tête à `alg: none` contourne tout (c'est la racine des CVE historiques comme CVE-2015-9235) ; (3) les secrets HMAC doivent être aléatoires et avoir au moins 32 octets, jamais des chaînes courtes ; (4) la vérification est plus que la vérification de signatures — vous devez également valider `exp` (expiration), `nbf` (pas avant), `iss` (émetteur) et `aud` (audience). Cet outil met en évidence chacun de ces Claims dans l'interface utilisateur pour que vous puissiez dire d'un coup d'œil si un échec est un problème de signature, un problème de timing ou un problème de Claims.

JWT n'est pas un remplacement pour les sessions. Les sessions stockent l'état de l'utilisateur sur le serveur (Redis ou une base de données) ; JWT emballe l'état dans le token. Les architectures de microservices, les API sans état, les clients mobiles et les configurations avec beaucoup de CORS bénéficient de JWT ; les systèmes d'entreprise traditionnels et les flux qui nécessitent une révocation instantanée (par exemple, 'expulser cet utilisateur maintenant') sont encore mieux servis par les sessions. Cet outil couvre à la fois le débogage JWT pur et les étapes d'analyse de Token / vérification de signature / modification de Payload d'une migration de session vers JWT.

Code Examples

50 lignes de Node.js : signature et vérification HS256 écrites à la main

javascript

Distille le mécanisme central de JWT : encode le Header et le Payload en Base64URL, puis applique HMAC-SHA256 à la chaîne `header.payload`. En production, utilisez une bibliothèque comme jsonwebtoken ou jose — cet extrait existe pour rendre les échecs de signature débogables.

const crypto = require('node:crypto')

function b64url(input) {
  return Buffer.from(input)
    .toString('base64')
    .replace(/\+/g, '-')
    .replace(/\//g, '_')
    .replace(/=+$/, '')
}

function hmacSign(data, secret) {
  return b64url(crypto.createHmac('sha256', secret).update(data).digest())
}

function sign(payload, secret) {
  const header = b64url(JSON.stringify({ alg: 'HS256', typ: 'JWT' }))
  const body = b64url(JSON.stringify(payload))
  const signature = hmacSign(`${header}.${body}`, secret)
  return `${header}.${body}.${signature}`
}

function verify(token, secret) {
  const [h, p, s] = token.split('.')
  const expected = hmacSign(`${h}.${p}`, secret)
  const a = Buffer.from(s)
  const b = Buffer.from(expected)
  return a.length === b.length && crypto.timingSafeEqual(a, b)
}

const SECRET = 'my-super-secret-key'
const payload = { userId: 42, role: 'admin', exp: Math.floor(Date.now() / 1000) + 3600 }
const token = sign(payload, SECRET)

console.log(token)
console.log(verify(token, SECRET))       // true
console.log(verify(token, 'wrong-key'))  // false

Côté navigateur : API Web Crypto pour la signature HMAC

html

L'idée centrale du front-end de cet outil : utilise crypto.subtle natif du navigateur pour la vérification HMAC, RSA, ECDSA, RSA-PSS et Ed25519 — aucune bibliothèque tierce nécessaire. Déposez ceci dans n'importe quelle page HTML pour créer des tokens HS256.

<!doctype html>
<html>
  <body>
    <pre id="out"></pre>
    <script>
      const out = document.getElementById('out')

      const b64url = buf =>
        btoa(String.fromCharCode(...new Uint8Array(buf)))
          .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')

      const b64urlStr = str => b64url(new TextEncoder().encode(str))

      async function sign(payload, secret) {
        const header = b64urlStr(JSON.stringify({ alg: 'HS256', typ: 'JWT' }))
        const body = b64urlStr(JSON.stringify(payload))
        const data = new TextEncoder().encode(`${header}.${body}`)

        const key = await crypto.subtle.importKey(
          'raw',
          new TextEncoder().encode(secret),
          { name: 'HMAC', hash: 'SHA-256' },
          false,
          ['sign']
        )

        const sig = await crypto.subtle.sign('HMAC', key, data)
        return `${header}.${body}.${b64url(sig)}`
      }

      ;(async () => {
        const token = await sign({ user: 'alice', role: 'admin' }, 'browser-demo-secret')
        out.textContent = token
      })()
    </script>
  </body>
</html>

Node.js : vérifiez RS256 avec jose (la bonne façon)

javascript

Utilisez une bibliothèque mature comme jose, jsonwebtoken ou PyJWT en production — n'écrivez jamais la vôtre. Cet extrait montre comment jose vérifie un token RS256, affiche la raison de l'échec en cas d'erreur (discordance d'alg, mauvaise signature, expiré, kid non trouvé, etc.).

import { jwtVerify, importSPKI } from 'jose'
import { readFile } from 'node:fs/promises'

const token = 'eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.payload.signature'
const publicKeyPem = await readFile('public.pem', 'utf8')

try {
  const { payload, protectedHeader } = await jwtVerify(
    token,
    await importSPKI(publicKeyPem, 'RS256'),
    {
      issuer: 'https://idp.example.com',
      audience: 'my-app',
      algorithms: ['RS256'],     // critique : la liste blanche d'algorithmes bloque les attaques alg:none et de substitution HS256
    }
  )
  console.log('alg =', protectedHeader.alg)
  console.log('sub  =', payload.sub)
} catch (err) {
  console.error('verify failed:', err.code, err.message)
  // commun : ERR_JWT_EXPIRED / ERR_JWS_INVALID / ERR_JWS_SIGNATURE_VERIFICATION_FAILED
}

Python : analysez un token et affichez ses Claims avec PyJWT

python

La façon la plus courante de déboguer JWT côté Python. decode() de PyJWT valide exp / nbf / iat par défaut et renvoie le résultat sous forme de dict simple.

import jwt

token = 'eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxw'

# Analyser (sans vérification de signature, regardez simplement le Header et le Payload)
print(jwt.get_unverified_header(token))
# {'alg': 'HS256', 'typ': 'JWT'}

print(jwt.decode(token, options={'verify_signature': False}))
# {'sub': '1234'}

# Vérification complète
claims = jwt.decode(
    token,
    'my-super-secret-key',
    algorithms=['HS256'],
    audience='my-app',
    issuer='my-service',
)
print(claims['sub'])

Supported Video Formats

FormatMIMEBrowser supportWhen to use
HS256 / HS384 / HS512HMAC + SHA-256/384/512UniversalAlgorithme à clé symétrique. Le même Secret signe et vérifie, simple et rapide, adapté aux clusters de services à l'intérieur d'une limite de confiance. Le Secret doit avoir au moins 32 octets aléatoires.
RS256 / RS384 / RS512RSASSA-PKCS1-v1_5 + SHA-2Web Crypto APIL'algorithme asymétrique le plus courant. Signez avec la clé privée, vérifiez avec la clé publique. Par défaut pour la plupart des IdP OIDC, passerelles API et SSO d'entreprise.
PS256 / PS384 / PS512RSA-PSS + SHA-2Web Crypto APIRSA-PSS est le remplacement mis à jour et plus sécurisé de RS256. AWS SigV4, AWS Cognito et les fournisseurs OIDC modernes ont tendance à le préférer. saltLength doit être spécifié explicitement.
ES256 / ES384 / ES512ECDSA + P-256/P-384/P-521Web Crypto APISignatures à courbe elliptique. Signatures courtes (ES256 n'est que de 64 octets), performances rapides, JWTs plus petits. Apple Sign in with Apple utilise ES256 par défaut.
EdDSA (Ed25519)Ed25519 / Ed448Web Crypto APIAlgorithme de signature haute performance de nouvelle génération. Signatures déterministes (même message + même clé produisent toujours le même résultat), pas de risque de réutilisation de nonce, recommandé par OAuth 2.1.

Output Example

A real MP3 file encoded to a Data URI — copy-ready:

Header (Base64URL):  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Payload(Base64URL):  eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzE2MjM5MDIyfQ
Signature:           kZJfaYjK3iCkVFL5EL9zGRZ5SmD8_x2h6B5c7pVFfVGo

Header décodé:
  {
    "alg": "HS256",
    "typ": "JWT"
  }

Payload décodé:
  {
    "sub": "1234567890",
    "name": "Jane Doe",
    "iat": 1716239022        // 2024-05-20 14:23:42 UTC
  }

Privacy & Security

Cet établi JWT s'exécute à 100% dans votre navigateur, soutenu par l'API Web Crypto native du navigateur. Le token que vous collez, le Header, le Payload, la Signature, le Secret HMAC, toute clé privée RSA/ECDSA, toute paire de clés générée et chaque calcul de signature/vérification restent sur votre appareil — ils ne voyagent jamais vers un serveur, ne sont jamais journalisés, jamais analysés et jamais mis en cache. La page peut être utilisée hors ligne une fois chargée. Meilleures pratiques : ne collez jamais de tokens de production à longue durée de vie ou de clés privées de production dans aucun outil en ligne, y compris celui-ci. Cet outil est approprié pour le débogage, les tests d'intégration, l'apprentissage et la création de tokens de test — les secrets de production et les clés privées doivent être gérés dans un environnement contrôlé et local.

Authoritative References

Troubleshooting

Signature invalide : 'signature is invalid'

Le token et la clé de vérification ne correspondent pas. Les causes habituelles : (1) la clé du serveur et la clé que vous avez collée dans l'outil sont différentes (le plus courant) ; (2) la clé contient des caractères invisibles (espace de fin, saut de ligne, caractère de largeur nulle) ; (3) Base64 et Base64URL sont mélangés ; (4) le mauvais algorithme est sélectionné (Header dit HS256, le serveur vérifie comme RS256, ou vice versa). Vérifiez d'abord que la clé correspond octet par octet : faites attention aux sauts de ligne de fin de PEM, aux espaces de fin de Secret HMAC et aux valeurs `k` de JWK qui peuvent avoir été mal décodées par URL. Confirmez que l'algorithme dans l'outil correspond au Header.alg du token. Utilisez la fonction de décodage plus vérification de cet outil pour reproduire l'erreur exacte et confirmer qu'elle se produit entre 'décodage réussi' et 'vérification échouée'.

HTTP 401 Unauthorized : Token expiré ou iat dans le futur

La vérification de signature a réussi, mais `exp` est dans le passé (Token expiré), `nbf` est encore dans le futur (Pas avant), ou `iat` est postérieur à l'heure actuelle du serveur (souvent dû à une désynchronisation d'horloge). Un autre cas courant est un `aud` (audience) discordant : le token a été émis pour l'App A mais est validé par l'App B. Utilisez la zone de Claims mis en évidence de cet outil pour repérer l'état de exp / nbf / iat d'un coup d'œil. exp rouge = expiré, veuillez réémettre. nbf rouge = pas encore valide, vérifiez si iat est une heure future. aud rouge = mauvaise audience, vérifiez que le serveur a la bonne audience configurée.

Erreur d'importation PEM ou JWK

PEM a des lignes blanches supplémentaires ou manque des marqueurs d'en-tête/pied (`-----BEGIN PUBLIC KEY-----`) ; JWK manque des champs requis (`kty` / `n` / `e` / `kid`) ; la valeur `k` de JWK manque de remplissage Base64URL (doit être rempli de `=` ou strictement sans `=`) ; une clé privée RSA est importée comme clé publique ; une clé privée Ed25519 (graine de 32 octets) est fournie comme 64 octets. Réexportez un PEM PKIX standard avec `openssl rsa -in key.pem -pubout -outform PEM` ou `openssl ec -in key.pem -pubout` ; pour JWK, utilisez la sortie brute du point de terminaison OIDC Discovery `/.well-known/jwks.json` au lieu de l'encoder à la main. Cet outil détecte automatiquement les en-têtes PEM, le remplissage manquant et les champs JWK manquants et affiche une suggestion.

Échecs de signature entre RS256 et PS256 entre langages

RS256 utilise RSASSA-PKCS1-v1_5, PS256 utilise RSA-PSS. Les deux **ne peuvent pas se vérifier de manière croisée** — un token signé avec RS256 par une clé RSA donnée échouera toujours la vérification PS256, et la signature peut différer en longueur de quelques octets. Assurez-vous que le signataire et le vérificateur utilisent le même algorithme. AWS SigV4 utilise PS256, la plupart des IdP OIDC utilisent RS256. RSA-PSS a également un paramètre `saltLength` — OpenSSL utilise 32 par défaut, jose utilise 32, `rsa.PSSOptions{SaltLength: rsa.PSSSaltLengthEqualsHash}` de Go est l'équivalent correct. Verrouillez cela avant les tests d'intégration entre langages.

Attaque alg:none et attaque de substitution de clé HS256

Le serveur choisit un algorithme de vérification basé sur l'alg déclaré dans le Header du token. Un attaquant réécrit l'en-tête à `alg: none` (pas de signature) ou réécrit un token RS256 en HS256 (utilisant la clé publique comme si c'était un Secret HMAC partagé) et contourne la vérification. Les CVE historiques comme CVE-2015-9235 (jsonwebtoken) et CVE-2022-23529 (plusieurs bibliothèques Node) remontent à ce modèle. Le serveur doit appliquer une liste blanche d'algorithmes — par exemple `algorithms: ['RS256']` — et ne doit jamais laisser le token dire au serveur quel algorithme utiliser. L'interface de cet outil affiche à la fois Header.alg et l'algorithme que vous avez réellement sélectionné, et signale les discordances : c'est en soi une démonstration en direct de 'le client ne doit pas faire confiance à Header.alg'.