What Is JWT?

JWT, short for JSON Web Token, is a compact token format used to carry claims between systems. A JWT is commonly used for authentication, authorization, and API access because it lets one system issue signed identity data that another system can verify and trust if validation is done correctly.

You will see JWTs in web apps, APIs, mobile backends, single sign-on flows, and many OAuth or OpenID Connect deployments. For related background, see what is oauth and what is mfa.

How JWT works

A JWT is not a login by itself. It is a token issued after some form of authentication or trust decision.

A server issues the token

After a user signs in, an identity provider or application server may create a JWT containing claims about that user or session.

A JWT typically has three parts:

header.payload.signature

Those parts represent:

• Header: Metadata such as token type and signing algorithm
• Payload: The claims
• Signature: The cryptographic proof that the token was issued by a trusted source and not modified

The signed token is then returned to the client for later use.

The client stores and sends the token

The client, such as a browser, mobile app, or frontend application, sends the JWT with later requests. A common pattern is:

Authorization: Bearer <token>

This allows the client to access protected APIs without sending a username and password on every request.

The receiving service validates the token

When an API or application receives a JWT, it should validate more than just the signature. A proper validator generally checks:

• The signature is valid
• The token came from a trusted issuer
• The audience matches the intended service
• The token is not expired
• The token is valid for the current time window
• The claims are appropriate for the requested action

If validation passes, the service may use the claims to make access decisions.

The application uses the claims

Once validated, the token claims can help the application decide:

• Who the user is
• Which organization or tenant they belong to
• Which permissions they have
• Whether the request should be allowed

This is one reason JWTs are popular in distributed systems. Services can validate tokens locally instead of looking up session state from a central store every time.

What JWT is used for

JWTs are widely used in modern identity and application architectures.

Authentication state after login

After a successful login, a system may issue a JWT so the client can prove authenticated status on later requests.

Authorization and permissions

Claims inside the token may include roles, scopes, or permissions used by APIs to decide what actions are allowed.

API access

JWTs are especially common in API security because APIs often need a portable, signed way to receive identity and authorization context.

Single sign-on and identity federation

JWTs frequently appear in SSO environments, especially in OpenID Connect and related token-based identity flows.

Common JWT structure

Although implementations differ, many JWTs include standard claims such as:

• sub for the subject
• iss for the issuer
• aud for the audience
• exp for expiration
• iat for issued-at time

Applications may also include custom claims such as:

• Role names
• Tenant IDs
• Group memberships
• Application-specific permissions

These claims are useful, but they are only trustworthy if the token is properly validated.

JWT security risks

JWTs are common, but they are not automatically secure. Problems usually come from implementation mistakes, not from the format alone.

Weak or incorrect validation

A service can become vulnerable if it:

• Accepts tokens from the wrong issuer
• Skips audience validation
• Fails to check expiration
• Trusts claims before verifying the signature

Insecure token storage

If a JWT is stolen, it may be usable as a bearer token until it expires. That means insecure browser storage, exposed mobile storage, or leaked logs can create real risk.

For organizations managing many credentials and admin accounts around these systems, a password manager such as Try 1Password → can help reduce broader credential hygiene issues, though it does not replace proper token handling.

Overly long token lifetimes

Long-lived tokens increase the value of token theft. Shorter-lived access tokens and clear refresh-token controls are generally safer.

Misunderstanding token visibility

Because most JWTs are readable by anyone who has them, sensitive data should not be placed in the payload unless the design specifically protects it.

Poor revocation strategy

JWT-based systems can be harder to invalidate immediately than classic server-side sessions, depending on the architecture. That matters during logout, account disablement, and incident response.

When you will encounter JWT

You are most likely to encounter JWT in these situations:

• Single-page applications: Frontends call APIs using bearer tokens
• Mobile apps: Apps authenticate to backend services using signed tokens
• OAuth and OIDC deployments: Identity systems issue tokens after successful authentication
• API gateways: Gateways validate JWTs before allowing traffic to reach internal services
• Microservices: Services exchange identity and authorization context without traditional shared sessions

Security teams also encounter JWT during:

• Penetration tests
• Application security reviews
• Incident response
• Cloud and API architecture reviews

Common questions include:

• Can the token be tampered with?
• Is signature validation done correctly?
• Are issuer and audience checked?
• Can a stolen token be replayed?
• How quickly can access be revoked?

JWT vs session cookies

JWTs and traditional sessions solve similar problems in different ways.

Traditional session model

In a classic session model:

• The server stores session state
• The client keeps a session identifier
• The server looks up the session on each request

JWT model

In a JWT-based model:

• The token itself carries signed claims
• The receiving service validates the token
• The service can often make decisions without a server-side session lookup

In practice, many systems use a mix of both approaches.

JWT vs OAuth

JWT and OAuth are related, but they are not the same thing.

• JWT is a token format
• OAuth is an authorization framework

OAuth deployments may use JWTs, but OAuth does not equal JWT, and not every JWT is part of OAuth.

Bearer token

A bearer token grants access to whoever possesses it. Many JWTs are used this way, which is why token theft matters so much.

OpenID Connect

OpenID Connect is an identity layer built on OAuth 2.0. It commonly uses JWTs for ID tokens.

JWS and JWE

A signed JWT is commonly represented as a JWS. An encrypted token format is a JWE. Many people say “JWT” when they specifically mean a signed token, but encryption is a separate concept.

API security

JWTs are a major topic in API security because APIs often trust the claims in these tokens to decide what users and systems can do.

Final takeaway

JWT is a JSON Web Token, a compact signed token used to carry identity and authorization claims between systems. It is widely used in APIs, web apps, mobile apps, and modern login flows because it is portable and easy for distributed systems to validate.

The security value of JWT does not come from the token format alone. It comes from correct issuance, proper validation, secure storage, short lifetimes, and good revocation design. If a team treats any signed-looking token as trustworthy without those controls, JWT can become a security problem rather than a convenience.