How JWT Authentication Works: A Developer’s Guide

JSON Web Tokens, or JWTs, have become the dominant standard for stateless authentication in modern web applications. If you’ve ever logged into a single-page application or consumed a REST API with Bearer tokens, you’ve almost certainly used JWTs. This guide explains exactly how they work, what’s inside them, and how to use them securely.

What Is a JWT?

A JWT is a compact, URL-safe token that encodes a JSON payload as a Base64URL string. It’s commonly used to prove identity and pass claims between a client and a server without storing session data server-side. The token is self-contained — the server can validate it without any database lookup.

The Three Parts of a JWT

A JWT consists of three dot-separated parts: header.payload.signature.

Header

The header is a Base64URL-encoded JSON object specifying the token type and signing algorithm, such as HS256 (HMAC-SHA256) or RS256 (RSA-SHA256).

Payload

The payload contains claims — statements about the user and metadata. Standard claims include sub (subject/user ID), iat (issued at), exp (expiration), and iss (issuer). You can also add custom claims like roles or permissions. The payload is Base64URL encoded, not encrypted — never store sensitive data in a JWT unless you use JWE encryption.

Signature

The signature is created by hashing the encoded header and payload with a secret key. This is what prevents tampering — if someone modifies the payload, the signature will no longer match.

The Authentication Flow

The typical JWT authentication flow works like this: the user logs in with credentials, the server validates them and issues a signed JWT, the client stores the token (usually in memory or a secure cookie), and subsequent requests include the token in the Authorization: Bearer <token> header. The server verifies the signature on every request without touching a session store.

Access Tokens vs Refresh Tokens

Access tokens are short-lived (15 minutes to 1 hour) to limit damage from theft. Refresh tokens are longer-lived and stored securely (httpOnly cookie) to obtain new access tokens without re-login. When the access token expires, the client exchanges the refresh token for a new pair. Refresh tokens should be rotated on each use and invalidated on logout.

Common Security Mistakes

• Storing JWTs in localStorage (vulnerable to XSS)
• Using the none algorithm (disables signature verification)
• Not validating the exp claim server-side
• Using weak symmetric secrets
• Putting sensitive PII in the payload

HS256 vs RS256

HS256 uses a single shared secret for both signing and verification, making it suitable for single-service scenarios. RS256 uses a private key to sign and a public key to verify, enabling multiple services to verify tokens without ever having access to the signing key. RS256 is preferred in microservices architectures.

Inspect any JWT instantly. Use the JWT Decoder on devutilitypro.com to decode and inspect your token’s header, payload, and expiry claims — no backend required.