Cybersecurity glossary
What is a JWT (JSON Web Token)?
Learn what a JWT (JSON Web Token) is, how header payload and signature work, where JWTs are used in OAuth and APIs, and which security practices keep token-based auth safe.
Definition
A JWT (JSON Web Token) is a compact, URL-safe token format that encodes JSON claims in a header and payload, typically protected by a digital signature or message authentication code so recipients can verify integrity and authenticity.
Why JWTs matter
Distributed applications need a portable way to carry authentication and authorization context. JWTs (JSON Web Tokens) provide a standardized, compact format for claims that can be verified without a central session lookup on every hop—when designed carefully.
JWTs power countless APIs and identity flows. They are also easy to misuse: putting secrets in readable payloads, skipping verification, or issuing tokens that live for weeks. Understanding the format is the first step to using it safely.
JWT structure
A common signed JWT looks like header.payload.signature, each part base64url-encoded.
Header
Metadata such as token type and signing algorithm (for example, RS256).
Payload
Claims about the subject, issuer, audience, expiry, roles, and custom attributes.
Signature
Integrity protection created with a secret or private key over header and payload.
Because the payload is only encoded—not encrypted—anyone holding the token can read claims unless JWE encryption is used.
How JWT authentication typically works
Issuer authenticates the user or client
An identity provider or auth service verifies credentials or an OAuth grant.
Token is minted
Claims are assembled and signed (or encrypted) into a JWT.
Client stores and sends the token
Browsers, mobile apps, or services send it as a bearer token—often in an Authorization header.
Resource server verifies
Signature, algorithm, issuer, audience, and time claims are checked before trust.
Authorization uses claims
Subject, scopes, roles, or tenant IDs drive access decisions.
Token expires or refreshes
Short lifetimes limit theft impact; refresh flows issue replacements under policy.
JWT vs server sessions
| Property | JWT access token | Server session |
|---|---|---|
| State | Often self-contained / stateless verification | Server stores session record |
| Revocation | Harder until expiry unless denylist/introspection exists | Immediate invalidation is straightforward |
| Scaling | Easy for many APIs verifying the same signature keys | Needs shared session store or sticky design |
| Payload visibility | Readable unless encrypted | ID reveals little; data stays server-side |
Security basics for JWT deployments
- Always verify signatures with an algorithm allowlist before trusting claims.
- Keep access tokens short-lived; prefer opaque refresh tokens with rotation.
- Validate iss, aud, exp, and tenant/user claims relevant to authorization.
- Store tokens carefully—HttpOnly cookies or secure native storage beat localStorage when XSS is a concern.
- Use asymmetric algorithms when many services must verify without sharing a symmetric secret.
- Minimize PII in payloads; remember JWTs are often logged accidentally.
- Plan revocation for compromised tokens: short TTL, introspection, or blocklists.
- Follow RFC 8725 JWT best current practices in design reviews.
The practical takeaway
A JWT is a signed (and optionally encrypted) JSON claims token used widely for API and identity assertions. It is a format—not a complete security architecture.
Use JWTs when portable, verifiable claims help your architecture, and pair them with strict verification, short lifetimes, careful storage, and solid authorization. For attack patterns against weak implementations, see the JWT Attacks glossary entry.
Related security terms
JSON Web Token (JWT) Attacks
Common ways flawed JWT validation leads to authentication bypass.
OAuth 2.0
A framework that often issues JWT access tokens or ID tokens.
OpenID Connect (OIDC)
An identity layer that commonly uses JWT ID tokens.
Session Management
Alternative and complementary approaches to maintaining login state.
Frequently asked questions
What is a JWT in simple terms?
A JWT is a small text token that carries information about a user or client—such as an ID and expiry—and usually includes a signature so a server can tell the data was not altered.
What are the three parts of a JWT?
A typical signed JWT has three base64url sections separated by dots: header, payload (claims), and signature.
Is a JWT encrypted?
Not by default. Standard signed JWTs (JWS) are readable by anyone who has the token. Encrypted JWTs use JWE when confidentiality of claims is required.
What is the difference between HS256 and RS256?
HS256 uses a shared secret for HMAC. RS256 uses an RSA private key to sign and a public key to verify, which fits distributed verification better.
Where are JWTs commonly used?
API bearer authentication, OAuth access tokens, OpenID Connect ID tokens, and service-to-service assertions.
Should JWTs replace server sessions?
They can, but are not automatically better. Stateless JWTs complicate revocation; many systems use short-lived JWTs plus refresh tokens or server-side session stores.
What claims are most important?
Common registered claims include iss (issuer), sub (subject), aud (audience), exp (expiration), nbf (not before), and iat (issued at).
References
Explore authoritative guidance and frameworks related to jwt (json web token).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.