JWT Security 101: How to Decode, Inspect, and Verify Claims Client-Side

What Is a JSON Web Token (JWT)?

Defined by RFC 7519, a JSON Web Token is an open, compact, URL-safe container for transferring claims between two parties. JWTs are the dominant authentication mechanism in modern single-page applications (SPAs), microservice architectures, and OAuth 2.0 / OpenID Connect (OIDC) workflows.

A JWT consists of three distinct parts separated by dots (.):

Header.Payload.Signature

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE3MDAwMDAwMDB9.4pz-KE...

The Three Components of a JWT

1. The Header

The header describes the cryptographic metadata and token type:

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

• alg: The cryptographic signing algorithm (e.g., HS256, RS256, ES256).
• typ: Token type, typically "JWT".

2. The Payload (Claims)

The payload contains statements about an entity (usually the authenticated user) and additional session metadata.

Standard Registered Claims:

• iss (Issuer): Identifies the authority that issued the JWT.
• sub (Subject): Identifies the principal subject of the token (e.g., user ID).
• aud (Audience): Identifies the intended recipients or resource servers.
• exp (Expiration Time): Unix epoch timestamp after which the token must not be accepted.
• nbf (Not Before): Identifies the timestamp before which the token is invalid.
• iat (Issued At): Timestamp recording when the token was generated.

3. The Signature

The signature validates that the token was neither tampered with nor forged in transit. For HMAC-SHA256:

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

Critical JWT Security Pitfalls

1. The “None” Algorithm Attack

In early implementations of RFC 7519, servers supported unsigned tokens where "alg": "none". Attackers bypassed authentication by altering the payload to grant admin privileges and setting "alg": "none" with an empty signature. Modern verification libraries strictly whitelist approved algorithms (algorithms: ['RS256']).

2. Key Confusion (Asymmetric to Symmetric)

When an API verifies tokens using an asymmetric algorithm (like RS256), the server uses a public key to verify and a private key to sign. In key confusion attacks, an adversary changes the header to "alg": "HS256" and signs the token using the server’s publicly accessible public key as the HMAC secret! Vulnerable servers verifying with jwt.verify(token, key) mistakenly treat the public key string as a shared symmetric secret.

3. Leaking Production Secrets to Web Tools

Never paste live customer session tokens or sensitive API tokens into third-party servers. Using our Toolbox JWT Decoder ensures parsing executes purely in local browser memory.