JWT RFC 7519: JSON Web Token for identity and authorisation

CyberAgent

Platform for automated vulnerability assessment, threat intelligence and continuous security posture management.

Discover →

The need for portable tokens

Modern web applications need a stateless mechanism to transport identity and claims: a user authenticates, the server issues a token that the client presents with every request; the API verifies the token without consulting the DB. It must be signable, verifiable, compact, URL-safe.

The release

RFC 7519 (JWT) is published by IETF in May 2015. Editors: Michael B. Jones (Microsoft), John Bradley, Nat Sakimura. Part of the JOSE family (JSON Object Signing and Encryption):

• RFC 7515 — JWS (Web Signature)
• RFC 7516 — JWE (Web Encryption)
• RFC 7517 — JWK (Web Key)
• RFC 7518 — JWA (Web Algorithms)
• RFC 7519 — JWT

Format

A JWT is a string composed of 3 base64url-encoded parts separated by dots:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiQWRhIn0.SflKxwRJSMeKKF2...
↓ decoded
Header:    {"alg":"HS256","typ":"JWT"}
Payload:   {"sub":"123","name":"Ada","exp":1735689600}
Signature: HMAC-SHA256(base64url(header).base64url(payload), secret)

Claims

• Registered — iss (issuer), sub (subject), aud (audience), exp (expiration), nbf (not before), iat (issued at), jti (unique id)
• Custom — any JSON field

Algorithms

• HS256/384/512 — symmetric HMAC
• RS256/384/512 — asymmetric RSA (common in OIDC)
• ES256/384/512 — ECDSA on elliptic curves
• EdDSA — Ed25519 (more modern)
• PS256/384/512 — RSA-PSS
• none — historical vulnerability, always reject

Common vulnerabilities

• Alg confusion — none acceptance, RS256 → HS256 with public key as HMAC secret
• Weak secrets — HMAC with weak password
• No expiration — tokens valid forever
• Sensitive payload — signed but unencrypted JWT is readable; PII in payload dangerous
• No revocation — stateless = hard to revoke before expiration

Typical usage

• OpenID Connect — id_token is a JWT
• OAuth 2.0 — access tokens often JWT
• Stateless APIs — bearer token in Authorization: Bearer <jwt>
• Federated SSO — cross-domain assertions
• Short-lived signed URLs

Best practices

• Short access tokens (5-15 min), longer refresh tokens
• Asymmetric signing (RS256/EdDSA) for microservices
• JWKS rotation — public keys published with kid
• Do not put PII in the payload
• Reject alg: none explicitly
• For web sessions, consider opaque session cookies (safer than JWT in localStorage)

In the Italian context

JWT is foundation of:

• SPID/CIE — parts of flows
• Digital PA APIs — PagoPA, ANPR, INPS
• Italian B2B SaaS — REST API authentication
• PSD2 Banking API — stateless session state

References: RFC 7519 (May 2015). IETF JOSE working group. Michael B. Jones, John Bradley, Nat Sakimura. Format header.payload.signature base64url. HS256, RS256, ES256, EdDSA algorithms. RFC 7515-7519 JOSE family.