A three-part, signed bearer token
A JWT (JSON Web Token, RFC 7519) consists of three Base64URL segments separated by dots: header.payload.signature. The header declares the signing algorithm (alg) and type (typ); the payload carries application-specific claims such as sub, exp, iat, iss, aud; the signature is produced over header + payload using HMAC (HS256) or an asymmetric algorithm (RS256, ES256).
Security notes: a verifier that accepts alg: none is catastrophic — always pin the expected algorithm. Keep token lifetime (exp) short, use a separate refresh token, and rotate keys periodically. See our REST API security guide for more.
About JWTs
Yes. Standard JWTs are signed (JWS) but not encrypted. Header and payload are plain Base64URL, readable by anyone. The secret is only needed to verify the signature. Use JWE if you need confidentiality, or simply do not put sensitive data in a token.
localStorage is accessible from JavaScript — an XSS lets the attacker steal the token. An HttpOnly + Secure + SameSite=Lax cookie is not accessible from JS and, combined with CSRF protection, is safer. Prefer HttpOnly cookies in production and use the Authorization header for non-SPA integrations.
Some old libraries trust the `alg` value from the header. An attacker can send a token with `alg: none` and no signature, bypassing verification. Mitigation: pin the expected algorithm in your verifier (allow-list) and always reject `none`.
JWS (JSON Web Signature) provides integrity and authenticity — the payload is readable. JWE (JSON Web Encryption) encrypts the payload so only the holder of the key can read it. A plain "JWT" is typically JWS; use JWE when you need confidentiality.
API security consulting
JWT configuration, OAuth2 flows, rate limiting and penetration testing — the KEYDAL team supports you end-to-end.