Back

Décodeur JWT

Les JSON Web Tokens (JWT) sont un moyen compact et sûr pour les URL de représenter des revendications entre deux parties. La plupart des JWT sont signés avec JWS (JSON Web Signature), ce qui garantit l'intégrité mais ne chiffre pas le contenu. Cet outil décode l'en-tête et la charge utile pour révéler les revendications, affiche les horodatages dans un format lisible et montre le statut d'expiration du jeton.

Specifications

Cas d'utilisation courants

  • Déboguer les flux d'authentification OAuth 2.0 et OpenID Connect
  • Inspecter les jetons d'accès et d'identité des fournisseurs d'identité (Auth0, Okta, Keycloak)
  • Vérifier que les revendications du jeton correspondent aux valeurs attendues lors du développement API
  • Vérifier l'expiration du jeton lors du dépannage d'erreurs "401 Unauthorized"
  • Comprendre la structure du jeton lors de l'intégration avec des services tiers
  • Auditer les jetons pour la revue de sécurité (algorithme, revendications, expiration)

Fonctionnalites

  • Décoder l'en-tête et la charge utile JWT (format JWS)
  • Afficher l'algorithme (HS256, RS256, ES256, PS256, EdDSA) et le type de jeton
  • Analyser les revendications enregistrées : iss (émetteur), sub (sujet), aud (audience), exp (expiration), nbf (pas avant), iat (émis à), jti (identifiant JWT)
  • Afficher le statut d'expiration avec compte à rebours lisible
  • Copier les sections décodées en JSON formaté

Exemples

Jeton d'accès OAuth 2.0

Essayer →

Un jeton d'accès typique avec des revendications standard incluant sujet, émetteur et expiration.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE5MTYyMzkwMjJ9.4S5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5

Conseils

  • Les jetons JWS (le type le plus courant) sont signés mais non chiffrés. Quiconque possède le jeton peut lire la charge utile en la décodant en Base64.
  • Les jetons JWE chiffrent la charge utile, mais sont moins courants. Cet outil décode les jetons JWS.
  • Vérifiez toujours les signatures côté serveur avant de faire confiance aux revendications. Cet outil affiche le contenu décodé mais ne vérifie pas les signatures.
  • L'algorithme "alg": "none" est un risque de sécurité et doit être rejeté par les serveurs.
  • Les algorithmes symétriques (HS256) utilisent un secret partagé ; les algorithmes asymétriques (RS256, ES256) utilisent des paires de clés publique/privée.
  • La revendication "exp" est un horodatage Unix en secondes. Vérifiez-la pour éviter d'accepter des jetons expirés.

Comprendre Décodeur JWT

JSON Web Tokens (JWTs) are the dominant token format for modern web authentication and authorization. A JWT is a compact, URL-safe string composed of three Base64url-encoded segments separated by dots: a header specifying the signing algorithm, a payload containing claims about the user or session, and a cryptographic signature that ensures the token has not been tampered with. This structure allows any party to read the token's contents by simple Base64 decoding, while only parties with the signing key can create or verify valid tokens.

Most JWTs use the JWS (JSON Web Signature) format, where the payload is signed but not encrypted. The header's "alg" field specifies the algorithm: symmetric algorithms like HS256 use a shared secret known to both issuer and verifier, while asymmetric algorithms like RS256 and ES256 use a private key for signing and a public key for verification. Asymmetric algorithms are preferred in distributed systems because the verification key can be shared publicly without compromising the signing key.

The payload contains registered claims defined by RFC 7519: "iss" (issuer), "sub" (subject), "aud" (audience), "exp" (expiration time), "nbf" (not before), "iat" (issued at), and "jti" (JWT ID). OAuth 2.0 and OpenID Connect layer additional claims for scopes, roles, and user profile information. The "exp" claim is critical for security — tokens without expiration or with excessively long lifetimes are a common vulnerability.

JWTs are used in OAuth 2.0 access tokens, OpenID Connect ID tokens, API authentication, and session management. Identity providers like Auth0, Okta, and Keycloak issue JWTs that applications verify without contacting the provider, enabling stateless authentication. However, this also means revocation is difficult — a compromised token remains valid until it expires, which is why short expiration times and token refresh flows are essential security practices.

Because JWS tokens are Base64url-encoded rather than encrypted, anyone who possesses the token can decode and read the header and payload. Sensitive information such as passwords, credit card numbers, and secrets should never be placed in a JWT payload. JWE (JSON Web Encryption) tokens do encrypt the payload, but they are far less common in practice. The distinction between encoding and encryption is one of the most important things to understand when working with JWTs.

The choice of signing algorithm has significant security implications. HS256 is a symmetric algorithm that uses a single shared secret for both signing and verification, making it simple to implement but requiring both parties to securely store the same secret. RS256 and ES256 are asymmetric algorithms that use a private key for signing and a public key for verification. In distributed systems, asymmetric algorithms are preferred because the public key can be shared openly — often through a JWKS (JSON Web Key Set) endpoint — without compromising the signing key. The "alg": "none" option signals an unsigned token with no signature at all, meaning anyone can forge tokens with arbitrary claims. A well-known attack involves changing the algorithm header to "none" and stripping the signature. Servers should always validate the algorithm against an allowlist and reject unsigned tokens.

Proper expiration handling is essential for JWT security. Applications should check the "exp" claim on every request before trusting the token. When a token expires, a refresh token (stored securely, often in an httpOnly cookie) can be used to obtain a new access token without requiring the user to log in again. Keeping access token lifetimes short — typically 5 to 15 minutes — limits the window of exposure if a token is compromised. Implementing token refresh proactively, before the access token actually expires, avoids user-facing interruptions in the application.

← Retour a tous les outils