What Exactly Is a JSON Web Token?
Defined formally under RFC 7519, a JSON Web Token is a compact, URL-safe means of transferring claims between two parties. Unlike traditional session-cookie authentication where the server stores user session data in a database or Redis cache, JWTs are stateless: the token itself contains all the identity information (claims) the server needs.
When a user logs in, the authorization server signs a JWT and delivers it to the client. On subsequent requests, the client passes this token (typically in the HTTP Authorization: Bearer <token> header). The server validates the cryptographic signature without querying a session database, making JWTs popular for distributed microservices and mobile applications.
The Three Parts of a JWT: Header, Payload & Signature
In its compact form, a signed JWT consists of three strings separated by dots (.):
Algorithm & Typ
Specifies the token type (typ: "JWT") and the cryptographic signing algorithm (such as alg: "HS256" or alg: "RS256").
The Claims
The heart of the token containing claims about the user (e.g. sub, username, roles) and timestamps (exp, iat).
Cryptographic Proof
Computed by hashing the header and payload with a secret or private key. Proves the token was not altered in transit.
The Biggest Misconception: Encoding vs. Encryption
⚠️ Base64URL Encoding Provides ZERO Secrecy
Many developers mistakenly believe that because a JWT looks scrambled, its contents are private. In truth, Base64URL is simply an encoding format (like translating text into binary or hex). Anyone with access to the token can decode it in milliseconds.
Standard Registered JWT Claims You Must Know
RFC 7519 defines seven standard registered claim names. While none are strictly mandatory, using them ensures interoperability across authentication frameworks:
| Claim | Full Name | Meaning & Example |
|---|---|---|
| iss | Issuer | Who created the token (e.g. https://auth.silixen.shop/). |
| sub | Subject | Whom the token represents (e.g. user ID usr_948274). |
| aud | Audience | Who is allowed to accept the token (e.g. https://api.silixen.shop). |
| exp | Expiration Time | Unix epoch seconds after which the token must be rejected. |
| nbf | Not Before | Unix epoch seconds before which the token must not be accepted. |
| iat | Issued At | Unix epoch timestamp when the token was created. |
| jti | JWT ID | Unique nonce identifier used to track tokens or prevent replay attacks. |
Top 4 Security Best Practices for Developers
- Never store sensitive secrets in claims: Do not place passwords, credit card numbers, or social security numbers into JWTs.
- Always enforce an expiration (
exp): Access tokens should have short lifespans (typically 10 to 60 minutes). Use long-lived refresh tokens stored securely on the backend to issue fresh access tokens. - Reject
alg: none: Ensure your server-side verification library explicitly checks the algorithm and refuses unsigned tokens. - Store tokens in
HttpOnlycookies: Avoid storing access tokens in browserlocalStorage, where malicious third-party JavaScript or XSS attacks can read and exfiltrate them.