JWT Tokens Explained: Structure, Security, and Use Cases

The Three Parts of a JWT

A JSON Web Token (JWT) is a compact, URL-safe string that carries a set of claims (statements) between two parties. It consists of three Base64URL-encoded parts separated by dots: header.payload.signature. A typical JWT looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Each part serves a specific purpose:

• Header: Specifies the token type (typ: "JWT") and the signing algorithm (alg: "HS256"). Common algorithms include HS256 (HMAC-SHA256), RS256 (RSA-SHA256), and ES256 (ECDSA-SHA256).
• Payload: Contains the claims — key-value pairs with data about the user or the token itself. Standard claims include sub (subject), iss (issuer), exp (expiration), iat (issued at), and aud (audience). Custom claims can be added for application-specific data.
• Signature: Computed by encoding the header and payload with the specified algorithm and a secret key (HMAC) or private key (RSA/ECDSA). The receiving server verifies this signature to confirm the token hasn't been tampered with.

JWTs are self-contained — all the information needed to verify the token is embedded within it. The server doesn't need to look up session data in a database to validate a JWT, which makes them ideal for distributed systems and stateless architectures.

Common Use Cases

JWTs are used across many areas of modern application development:

• API Authentication: After login, the server issues a JWT that the client sends with every API request — typically in the Authorization: Bearer header. The API verifies the signature and reads claims without querying a session store.
• Single Sign-On (SSO): OAuth 2.0 and OpenID Connect use JWTs as ID tokens and access tokens. A user authenticates once with an identity provider and receives JWTs that are trusted across multiple applications.
• Microservices: In a microservices architecture, a gateway service can issue a JWT that downstream services verify independently. No shared session database is needed across services.
• Information Exchange: JWTs can securely transmit signed claims between parties. Since the payload is Base64-encoded (not encrypted), anyone can read it, but only someone with the signing key can create a valid token.

Security Considerations

JWTs are powerful but come with security risks if misused. The payload is encoded, not encrypted — anyone who intercepts a JWT can decode it with a single Base64 decode. Never put secrets, passwords, or sensitive personally identifiable information in a JWT payload.

Key security practices:

• Always Verify the Signature: Skipping signature verification is the most dangerous JWT mistake. It allows attackers to forge tokens with arbitrary claims, including admin: true. Never use the none algorithm in production.
• Set Short Expiration: Use the exp claim to enforce token expiration. Access tokens should expire in minutes to an hour. Use refresh tokens with longer lifetimes to obtain new access tokens.
• Use Strong Keys: For HMAC (HS256), use keys at least 256 bits long. For RSA (RS256), use keys of at least 2048 bits. Rotate keys periodically.
• Prevent Algorithm Confusion: An attacker might switch the header from RS256 to HS256, causing the server to verify the RSA public key as an HMAC secret. Always validate the algorithm and reject unexpected values.
• Use HTTPS: JWTs sent in headers are vulnerable to interception over HTTP. Always transmit JWTs over encrypted connections.

JWT vs Session-Based Authentication

Traditional session-based auth stores a session ID on the client (usually in a cookie) and keeps session data on the server — typically in memory, Redis, or a database. Each request requires the server to look up the session. JWTs eliminate this server-side lookup, making them stateless.

• JWT Advantages: Stateless, works across domains and services, no server-side session store needed, natural fit for mobile apps and SPAs.
• Session Advantages: Immediate revocation (delete the session), smaller cookie size, server controls all data, no risk of token theft having long-lived consequences.
• JWT Disadvantages: Cannot be easily revoked before expiration, larger payload, requires key management, token leakage gives access until expiry.
• Session Disadvantages: Requires shared state across servers, database lookups on every request, harder to scale horizontally without a shared session store.

In practice, many applications use both: JWTs for stateless API access and server-side sessions for browser-based web apps. The right choice depends on your architecture, scalability needs, and security requirements.