Complete Guide to JSON Web Token (JWT) and How It Works

Have you ever logged into a website by clicking “Login with Google” or “Sign in with Facebook,” without entering your password? Or used a web app that keeps you logged in even after closing your browser?

These seamless experiences often rely on JSON Web Tokens (JWTs) — a way to authorize users after they have been authenticated.

In today’s digital landscape, securing user identity and managing access is critical. JWT is a compact and secure method for transmitting claims between parties, typically used after authentication to handle authorization, session management, and secure API access.

But what exactly is a JWT, how does it work, and why is it important? This blog offers a comprehensive explanation.

Tokens are digital artifacts used in authentication systems to represent user identity. Instead of maintaining session state on the server, modern applications issue tokens to clients. These tokens are sent along with each request to authorize access to protected resources.

When a user makes an authenticated request, the token is included in the request header. The server verifies the token’s validity—typically by checking its signature and expiration time. If the token is valid, access is granted. This approach supports stateless and scalable systems, compared to traditional session-based models.

A JWT (JSON Web Token) is a compact, self-contained token used to securely transmit claims between parties. JWTs are digitally signed using a secret (with HMAC) or a public/private key pair (with RSA or ECDSA).

One of the main advantages of JWT authentication is that it doesn’t require storing session data on the server—making it ideal for distributed applications.

There are two main types of JWT based on how the payload is protected- JWS and JWE. Let’s learn more about them.

JWS is a type of JWT where the payload (data) is digitally signed, ensuring integrity and authenticity of the token.

• The payload is Base64URL encoded and signed using a secret or private key.
• It is not encrypted, meaning the contents can be read by anyone who has the token.
• Commonly used in authentication and authorization scenarios like OAuth 2.0 access tokens.

Use Case: Verifying that the data has not been tampered with.

JWE is a type of JWT where the payload is encrypted, ensuring confidentiality in addition to integrity.

• The entire payload is encrypted using a public key or shared secret.
• Only the intended recipient can decrypt and read the token contents.
• Less common than JWS, but ideal for sensitive data transmission.

Use Case: Protecting personal or confidential information during transit.

Feature	JWT (General)	JWS (Signed JWT)	JWE (Encrypted JWT)
Security Focus	Token Format	Integrity, authenticity	Confidentiality + integrity
Payload	Not specified	Base64URL encoded (readable)	Encrypted (not readable)
Signature	Optional	Required	Encrypted along with payload
Encryption	Optional	Not encrypted	Fully encrypted
Use Case	ID and Access Tokens	OAuth 2.0, OpenID Connect	Highly sensitive information

Note: JWT is the umbrella format. JWS and JWE are implementation types. The most commonly used JWTs in web apps are of the JWS type.

A JWT is composed of three parts:

1. Header
2. Payload
3. Signature

Each part is Base64URL encoded and separated by a period (.).

Example:

php-template

CopyEdit

<Header>.<Payload>.<Signature>

The header typically includes the token type and the signing algorithm being used.

json

CopyEdit

{

“alg”: “HS256”,

“typ”: “JWT”

}

The payload contains the claims—statements about an entity (usually the user) and additional metadata.

json

CopyEdit

{

“iss”: “https://lrSiteName.hub.loginradius.com/”,

“sub”: “{uid}”,

“jti”: “unique string”,

“iat”: 1573849217,

“nbf”: 1573849217,

“exp”: 1573849817,

“Key1”: “value1”,

“Key2”: “value2”

}

Standard JWT Claims

• iss (Issuer): Identifies the token issuer (e.g., your LoginRadius domain).
• sub (Subject): Identifies the user or entity to whom the token refers.
• jti (JWT ID): Unique identifier for the token, often used to prevent replay attacks.
• iat (Issued At): Timestamp of when the token was issued.
• nbf (Not Before): Specifies the time before which the token must not be accepted.
• exp (Expiration): Sets token expiration—once expired, access is denied.

Note: The payload is not encrypted by default, and can be decoded by anyone. Do not include sensitive information unless using an encrypted JWT (JWE).

The signature ensures the token has not been altered. It is created by signing the encoded header and payload using a secret or private key.

text

CopyEdit

HMACSHA256(

base64UrlEncode(header) + “.” +

base64UrlEncode(payload),

secret)

This helps validate the token’s integrity and authenticity.

JWT-based authentication typically follows this flow:

1. User Logs In

The user provides login credentials (e.g., username and password).

1. Server Verifies Credentials

The server validates the credentials against its data store.

1. JWT is Issued

Upon successful login, the server issues a JWT signed with a secret/private key (post authentication).

1. Client Stores JWT

The client stores the token (e.g., in localStorage, sessionStorage, or a secure cookie).

1. Token Sent on Requests

The client attaches the token to the Authorization header (Bearer <token>) in future authorization/authentication API requests.

1. Server Validates JWT

The server checks the token’s signature, expiry, and validity.

1. Access is Granted

If valid, the user is granted access to protected resources.

This stateless model makes JWT ideal for scalable web and mobile apps.

OAuth 2.0 is an industry-standard protocol for authorization. It enables users to grant third-party apps access to their resources without sharing their credentials.

When integrated with JWT, OAuth 2.0 uses JWTs as access tokens to represent the user’s authorization.

JWTs are commonly used as OAuth 2.0 access tokens—but not required by the specification. Some providers use opaque tokens instead.

• JWTs are self-contained, carrying all claims.
• They are digitally signed, allowing recipients to verify them without contacting the issuer.
• They improve performance by eliminating database lookups during request processing.

To implement JWT with LoginRadius:

Step 1: Configure a JWT App

Set up a JWT app in your LoginRadius Admin Console. Follow the JWT Admin Console Configuration guide.

Step 2: Use APIs to Retrieve JWT

If you are directly implementing your Login forms or already have an access token or want to generate a JWT based on email/username/Phone number or a password, you can leverage the following APIs:

• JWT Token: This GET API is used to exchange access tokens with your JWT.
• JWT Token by Email: This API is used to get a JWT by Email and Password.
• JWT Token by Username: This API is used to get JWT by Username and password.
• JWT Token by Phone: This API is used to get JWT by Phone and password.

API Response Example:

json

CopyEdit

{

“signature”: “<JWTresponse>”

}

These tokens can then be used in your client app for authenticated requests.

To implement JWT securely, follow these key practices:

1. Keep Signing Keys Secure

Private keys or secrets used to sign JWTs must be stored securely.

1. Avoid Sensitive Data in Payload

Payload is only base64 encoded—not encrypted. Do not include passwords, PII, or credentials unless using encrypted JWT (JWE).

1. Limit Token Claims

Include only essential claims in the token to reduce size and exposure.

1. Use HTTPS

Always transmit JWTs over HTTPS to prevent man-in-the-middle attacks.

1. Set Short Expiry Times

Use short exp durations and implement refresh tokens to reduce impact if a token is compromised.

1. Implement Token Revocation

Use jti with a blacklist or maintain a revocation strategy for enhanced control.

JWTs offer numerous benefits in authentication systems:

• Stateless Authentication – No need to maintain session state on the server.
• Scalability – Suitable for microservices and distributed systems.
• Tamper Resistance – Digitally signed tokens ensure data integrity.
• Performance – Reduces server load and database dependencies.
• Cross-Platform Support – Easily used across web, mobile, and API ecosystems.
• Enhanced Security – Signed tokens ensure authenticity and tamper-proof data.
• Developer Convenience – Simplifies session management.

JWTs are widely adopted in OAuth 2.0, OpenID Connect, and API security implementations.

JWT authentication is a robust, efficient, and secure method for protecting web and mobile applications. By understanding its structure, use cases, and best practices, you can confidently implement JWTs in modern authentication systems.

Looking to implement JWT in your application? Check out the developer documentation to get started with seamless JWT integration using LoginRadius.

FAQ’s

1. What is the expiration time of JWT, and what is the measurement of time in JWT?

A: By default, the expiry time of a JWT is 600 seconds (10 Minutes). It is shown in the form of seconds in the JWT configuration. The expiry time can be set from 1 second to 2592000 seconds (30 days) as per your use case.

2. What is the difference between OAuth and JWT?

A: OAuth is an authorization framework, that allows third-party apps to access user data without exposing their credentials.JWT is used at the end of authentication to securely transmit user info (identity and authorization). Use OAuth for delegated access; use JWT for stateless authentication and API authorization (verifying within your own system).

3. How many types of JWT are there?

A: JWTs mainly come in two types, with one being JSON Web Signature (JWS) and JSON Web Encryption (JWE). In JWS, the token’s content is digitally signed to protect it from tampering during transmission between sender and receiver. While the data is secure from modification, its contents (claims) can still be visible to others.