Introduction
JSON Web Tokens are widely used to carry identity and authorization information between an identity provider, an API gateway and application services. They appear in OAuth and OpenID Connect flows, session architectures, service-to-service calls and signed links.
A JWT is compact and easy to transport, but decoding it is not the same as trusting it. The utily.tools JWT Manipulator separates header, payload and signature, documents known claims and can sign or verify supported asymmetric algorithms for debugging.
Claims protected by a digital signature
A signed JWT, formally a JWS compact serialization, contains three Base64url segments separated by periods. The header describes the algorithm and key metadata. The payload contains claims. The signature protects the exact encoded header and payload against modification.
Registered claims include iss for issuer, sub for subject, aud for audience, exp for expiration, nbf for not-before and iat for issued-at. Their presence and meaning depend on the application profile. A valid cryptographic signature alone does not prove that the issuer, audience or lifetime is acceptable.
Technical foundations and behavior
Verification reconstructs the ASCII signing input header.payload, decodes the signature bytes and calls the algorithm with a trusted public key. The verifier must select allowed algorithms from configuration, not simply accept the alg value supplied by the token.
Base64url and JSON parsing
JWT uses - and _ instead of + and / and often removes padding. Each decoded segment must be interpreted as UTF-8 JSON. Malformed encodings and duplicate or unexpected header values should fail closed.
RSA and ECDSA signatures
RS256 uses RSA PKCS#1 v1.5 with SHA-256, while PS256 uses RSA-PSS. ES256 uses ECDSA over P-256; JWS stores its signature as fixed-width r || s bytes rather than the DER encoding used by many cryptographic libraries.
Validation policy
Production validation should require issuer and audience, check exp and nbf with a limited clock tolerance, restrict algorithms, select keys through a trusted kid/JWKS process and reject tokens intended for another context. Private keys must never be pasted into an untrusted environment.
Real-world applications
API access tokens
An API verifies the issuer, intended audience, expiration and signature before translating scopes into authorization decisions.
Identity debugging
A developer inspects aud, iss, roles and time claims to understand why a validly signed token is rejected by one service.
Key rotation
The kid header selects a public key from a JWKS while old keys remain available long enough to verify tokens issued before rotation.
Standards and deeper technical reference
Origin, standardization and the JOSE family
JSON Web Token was standardized by the IETF OAuth working group as RFC 7519 in May 2015. A JWT is a set of JSON claims carried inside a JSON Web Signature (JWS, RFC 7515), a JSON Web Encryption (JWE, RFC 7516), or a nested combination. JSON Web Key (JWK, RFC 7517) represents keys, and JSON Web Algorithms (JWA, RFC 7518) defines the original algorithm identifiers. RFC 8725 updates JWT with current Best Current Practice security guidance.
The media type is application/jwt. A common signed JWT uses JWS Compact Serialization: base64url(protected header) + period + base64url(payload) + period + base64url(signature). Base64url only makes the bytes transport-safe; anyone holding a normal signed JWT can decode its header and claims. Confidential claims require JWE or protection outside the token.
- JOSE header
- Metadata for cryptographic processing. alg selects the algorithm, typ can explicitly identify JWT, kid can select a key, and crit marks extensions that must be understood.
- JWT Claims Set
- The JSON object containing registered, public or private claims. A claim is data, not automatically a trusted authorization decision.
- Signing input
- The exact ASCII bytes of encoded protected header + period + encoded payload. Reformatting either JSON value changes the signature input.
- Nested JWT
- A JWT wrapped in another JWS or JWE, commonly sign-then-encrypt. Each cryptographic layer must be validated.
Registered JWT claims and validation semantics
RFC 7519 defines seven registered claims. None is universally mandatory; a token profile such as OpenID Connect or an internal authorization protocol decides which are required. NumericDate is seconds from 1970-01-01T00:00:00Z, ignoring leap seconds, and may be non-integer. Validators may allow a small configured leeway for clock skew but should not make expiry optional by accident.
Claims not understood by a generic JWT implementation are ignored, so business validation belongs to the consuming application. The IANA JWT Claims registry contains additional claims defined by later specifications; registration does not mean every token may use them with the same semantics.
| Claim | Meaning | Correct validation |
|---|---|---|
| iss | Issuer | Exact match against a configured trusted issuer; use it to select the correct validation policy and keys |
| sub | Subject | Interpret within the issuer namespace; often the stable principal identifier |
| aud | Audience | String or array containing the intended recipient; reject a token not addressed to this service |
| exp | Expiration time | Current time must be before exp, subject only to a small explicit clock-skew allowance |
| nbf | Not-before time | Do not accept before this instant, again with bounded skew handling |
| iat | Issued-at time | Use for freshness and anomaly checks; it is not expiry by itself |
| jti | JWT ID | Unique identifier that can support replay detection or revocation records when the profile requires it |
JWS signature and MAC algorithms
The algorithm value is attacker-controlled input until verification succeeds. The application must configure an allowlist and bind each key to one algorithm; it must never choose verification behavior solely from alg. The IANA JOSE registry is the live source for registration and implementation status. RFC 9864 now favors fully specified identifiers: the generic EdDSA identifier is deprecated in favor of Ed25519 or Ed448, and RFC 9964 adds optional post-quantum ML-DSA identifiers.
The table covers the principal standardized choices. Registered does not mean suitable for every deployment. Key size, library support, hardware, compliance and the token profile determine the acceptable subset.
| Identifier | Primitive and key model | Technical and operational notes |
|---|---|---|
| HS256 / HS384 / HS512 | HMAC with SHA-2; shared secret | Every verifier can mint tokens. Use a random secret at least as strong as the hash output and separate keys by context. |
| RS256 / RS384 / RS512 | RSA PKCS #1 v1.5 signature with SHA-2 | Public verification and broad interoperability. RSA keys should be at least 2048 bits; signatures are relatively large. |
| PS256 / PS384 / PS512 | RSA-PSS with SHA-2 and MGF1 | Probabilistic modern RSA signature padding. JOSE fixes salt length to the hash output length. |
| ES256 | ECDSA P-256 with SHA-256 | Compact 64-byte raw R||S JOSE signature. Nonce generation must be secure or deterministic. |
| ES384 | ECDSA P-384 with SHA-384 | 96-byte raw signature and higher security target; less universal than ES256. |
| ES512 | ECDSA P-521 with SHA-512 | Uses P-521 despite the name ES512; raw signature is 132 bytes. |
| Ed25519 / Ed448 | EdDSA with a fully specified parameter set | Deterministic modern signatures. These replace ambiguous EdDSA in updated JOSE registration. |
| ES256K | ECDSA secp256k1 with SHA-256 | Optional registration associated with ecosystems already using secp256k1. |
| ML-DSA-44 / 65 / 87 | FIPS 204 post-quantum signatures | Optional new JOSE algorithms with much larger keys and signatures; deploy only with explicit ecosystem support. |
| none | No signature or MAC | Unsecured JWT. Reject unless a narrowly defined profile explicitly requests and protects it by other means. |
A complete JWT validation pipeline
Parse with strict size and JSON limits; require the expected compact or JSON serialization; reject unsupported critical headers; select a trusted issuer policy; resolve a key through a preconfigured JWKS source; verify the signature with an algorithm allowlist; then validate iss, aud, time claims, token type and application claims. Authentication and authorization happen only after every applicable check succeeds.
RFC 8725 documents algorithm confusion, weak HMAC secrets, cross-JWT substitution, SSRF through jku or x5u, injection through kid, malformed elliptic-curve inputs and ciphertext-length leakage. Do not fetch arbitrary key URLs from a token. Cache and rotate trusted JWKS carefully, validate TLS, cap response size and handle unknown kid without creating a request flood.
JWT is not automatically revocable. Short access-token lifetime, refresh-token rotation, sender-constrained tokens, jti deny-lists and issuer-side session state address different replay and revocation requirements. Avoid putting secrets or unnecessary personal data in a signed token because copies can persist in logs, browser storage and telemetry.
Primary specifications and references
- RFC 7519: JSON Web TokenIETF / RFC Editor
- RFC 7515: JSON Web SignatureIETF / RFC Editor
- RFC 7518: JSON Web AlgorithmsIETF / RFC Editor
- RFC 8725: JWT Best Current PracticesIETF / RFC Editor
- IANA JOSE algorithm registryInternet Assigned Numbers Authority
- IANA JWT Claims registryInternet Assigned Numbers Authority
Conclusion
JWT combines compact JSON claims with a cryptographic integrity mechanism. Secure use requires more than decoding: algorithm restrictions, trusted keys and semantic claim validation are all part of verification.
My view is that JWT works well for bounded, interoperable claims but becomes risky when applications treat it as a magical session container. Inspect tokens with the utily.tools JWT Manipulator and continue with the JWE, Base64 and timestamp articles for the surrounding concepts.