How JWT Authentication Works: Headers, Payloads, and Security

JSON Web Tokens (JWT) are the standard method for user authentication in modern client-server architectures. By storing session parameters in a signed, stateless token, servers can authenticate requests without querying database records on every call. But how do these tokens work, and how can developers ensure they are secure?

1. What is a JSON Web Token?

A JWT is a compact, URL-safe container for sending claims between two parties. Typically, when a user logs in, the authentication server generates a JWT containing their user info and sends it back to the browser. The browser includes this token in the header of subsequent API requests, telling the system who the user is and what resources they can access.

2. The Three Parts of a JWT

A JWT string consists of three distinct segments separated by dots (.): the Header, the Payload, and the Signature.

• Header: Specifies the token type (usually "JWT") and the signature algorithm (e.g., HMAC SHA256 or RSA).
• Payload: Contains the claims, which are statements about the user (e.g., user ID, username, roles) and session parameters.
• Signature: Generated by encoding the header and payload strings, and signing them with a secret key or private certificate.

[Header]. [Payload]. [Signature]

3. How Signatures Prevent Tampering

It is important to remember that the header and payload of a JWT are not encrypted; they are simply Base64URL-encoded strings. Anyone can decode a JWT and read its claims using a simple client-side decoder.

However, the signature prevents users from tampering with the claims. If a user modifies the payload in their browser, the token's signature will no longer match. When the server validates the token, the signature check will fail, and the request will be rejected.

4. Token Expiration & Claims

A standard JWT payload contains registered claims that define token life parameters:

• exp (Expiration Time): The Unix timestamp when the token becomes invalid.
• iat (Issued At): The Unix timestamp when the token was created.
• sub (Subject): The unique identifier for the authenticated user.
• iss (Issuer): The identity of the authorization server that issued the token.

5. JWT Client Storage Security

Storing JWTs securely in the browser is critical. Storing them in localStorage leaves them vulnerable to Cross-Site Scripting (XSS) attacks. If an attacker injects malicious JS into your page, they can read the token and hijack the session. The most secure approach is storing tokens in HTTPOnly, secure cookies, preventing JS from reading the token values directly.