What is JSON Web Token (JWT) and How Does It Work Guide

• JWT Definition: JSON Web Token (RFC 7519) is a compact, self-contained standard for securely transmitting information as a JSON object.
• Anatomy: A JWT consists of three distinct parts separated by dots (.): Header, Payload, and Signature.
• Cryptographic Integrity: Digitally signed using HMAC algorithms or RSA/ECDSA public-private key pairs to prevent data tampering.
• Primary Use Cases: Widely adopted for stateless API authentication, OAuth2 authorization flows, and microservices session handling.

In modern web development, mobile applications, and microservices architectures, session management and user authorization rely on JWT (JSON Web Token). By providing a stateless authentication model, JWTs eliminate server-side session storage bottlenecks.

To decode and inspect JWT tokens during development, use our JWT Decoder tool. To understand the underlying cryptographic signing mechanics, read our guide on what is HMAC.

What is a JSON Web Token and How Does It Function?

JSON Web Token (RFC 7519) is an open industry standard for transmitting claims securely between two parties. Upon successful authentication (login), the identity server signs and issues a JWT token to the client.

The client includes this token in subsequent HTTP requests within the Authorization header using the Bearer scheme:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

The backend server verifies the token signature using a secret key or public key. If the signature is valid, access is granted without database session lookups.

The Three Components of a JWT Structure

A JSON Web Token string is constructed by concatenating three Base64URL-encoded strings separated by periods: Header.Payload.Signature. To learn more about encoding mechanisms, explore our guide on Base64 encoding.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFobWV0IiwiYXR0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

1. Header

The Header identifies the token type (JWT) and the cryptographic signing algorithm (HS256, RS256):

{
  "alg": "HS256",
  "typ": "JWT"
}

2. Payload

The Payload contains claims—statements about the user and entity state:

• Registered Claims: Pre-defined attributes like iss (issuer), exp (expiration time), sub (subject), and aud (audience).
• Public Claims: Custom names collision-resistant via IANA registries.
• Private Claims: Application-specific claims shared between parties (e.g., user ID, user roles).

{
  "sub": "usr-1001",
  "name": "Alex Morgan",
  "role": "admin",
  "exp": 1775000000
}

3. Signature

The Signature verifies that the message was not altered in transit. It is calculated by hashing the encoded header, payload, and secret key:

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret_key
)

Symmetric vs. Asymmetric Signing Algorithms

Developers choose between two main signing paradigms:

1. Symmetric Algorithms (HS256 - HMAC-SHA256): The signing and verification processes share the same secret key. Ideal for monolithic applications where the issuer and verifier share a single backend service.
2. Asymmetric Algorithms (RS256 - RSA / ES256 - ECDSA): The issuer signs the token with a private key, while verifiers validate it using a public key. This approach is recommended for distributed microservices architectures.

OAuth 2.0 and OpenID Connect (OIDC) Integration

In modern cloud architectures, JWTs form the foundation of OAuth 2.0 authorization framework and OpenID Connect (OIDC) identity layers. OIDC specifies ID Tokens formatted as JWTs to represent authenticated user identity across single sign-on (SSO) systems.

API Gateways evaluate access tokens at edge nodes using cached JSON Web Key Sets (JWKS), preventing authorization bottlenecks across internal services. This decoupled validation workflow enables horizontal scaling across distributed cloud clusters. Furthermore, central identity providers emit signed tokens that federate access seamlessly across multiple third-party API consumers.

Client Storage and Security Best Practices

How tokens are stored on web clients determines resistance against security vulnerabilities.

• LocalStorage / SessionStorage: Vulnerable to Cross-Site Scripting (XSS) attacks. Malicious scripts executing on the client can extract stored tokens.
• HttpOnly and SameSite Cookies (Recommended): Storing JWTs inside HttpOnly, Secure, and SameSite=Strict cookies prevents client-side JavaScript access, defending against XSS exploits.

Key security recommendations:

• Reject None Algorithm: Ensure server implementations reject tokens containing alg: "none".
• Enforce Strong Secret Keys: Use at least 256-bit entropy keys for HMAC signing.
• Set Short Expirations: Issue short-lived access tokens alongside secure refresh tokens.

Implementing token rotation ensures stolen credentials remain short-lived, upholding security posture across modern enterprise applications. Development teams must regularly conduct security audits to prevent authorization breaches and protect user data integrity. Software engineering teams must continuously maintain robust authentication mechanisms. Combining proper token storage with strict expiration rules minimizes operational vulnerabilities and protects user credentials effectively across distributed cloud networks. Adhering to these industry standards protects applications against identity theft and unauthorized access.

Frequently Asked Questions

Is JWT data encrypted or can anyone read its contents?

Standard JWTs are signed but unencrypted. Anyone can decode the Base64URL string to view claims; however, tampering invalidates the signature unless the secret key is known.

How is token revocation handled with stateless JWTs?

Because JWTs are stateless, immediate revocation requires maintaining token blacklists (using jti identifiers) or revoking parent refresh tokens in a database.

What is the difference between Access Tokens and Refresh Tokens?

Access tokens are short-lived credentials used to authorize API requests. Refresh tokens are long-lived credentials used exclusively to request new access tokens securely.