JWT Basics: Understanding the Anatomy
A JSON Web Token (JWT) is a compact, self-contained way to transmit information between parties as a JSON object. It’s widely used in modern web applications for authentication and information exchange. Despite its simplicity, understanding its structure is key to using it securely and effectively.
The Three Parts of a JWT
Every JWT consists of three Base64Url-encoded segments separated by dots: header.payload.signature.
1. Header
The header typically contains metadata about the token, such as the signing algorithm (alg) and token type (typ). For example:
{
"alg": "HS256",
"typ": "JWT"
}2. Payload
The payload holds the actual claims—statements about the user and additional data. There are three types of claims:
- Registered: Standard claims like
iss(issuer),sub(subject),exp(expiration), andiat(issued at). - Public: Custom claims defined by the application (e.g.,
role,permissions). - Private: Agreed-upon claims between parties (use cautiously).
3. Signature
The signature ensures integrity. It’s created by encoding the header and payload, then signing with a secret or private key. The server verifies it using the corresponding public key or secret.
Why This Structure Matters
Because JWTs are stateless, the server doesn’t store session data—everything needed to verify authenticity is inside the token. This enables scalability but also demands caution: never put sensitive data in the payload, as it’s only encoded, not encrypted.
FAQ
What happens if the signature is missing?
If alg: none is used, the token is unsigned and should only be accepted in trusted
environments. Most systems reject it by default.
Can I trust the payload data?
Only if the signature is verified. Anyone can decode and read the payload, but only a valid signature proves authenticity.
How long should a JWT live?
Use short expiration (exp) times (e.g., 15–60 minutes) and implement refresh
tokens for long sessions.
Mastering JWT structure is the first step to building secure, scalable authentication systems.