What is a JWT? A practical guide to token claims, trust and validation
Security and identity
JWT stands for JSON Web Token. It is a compact token format used to carry claims between parties, often in APIs, OAuth and OpenID Connect. A JWT can be signed so the recipient can check that it came from a trusted issuer and has not been altered, and it can also be encrypted when confidentiality is required. In practice, people often encounter JWTs as access tokens or ID tokens. But a JWT is not automatically secure because it is a token. Real security depends on validation, signing algorithms, issuer and audience checks, expiry, transport security, safe storage and key management.
What this means
Think of a JWT as a compact container for statements about a subject. Those statements are called claims. Common examples include who issued the token, who it is about, who it is intended for, and when it expires. Because the format is compact and URL-safe, it is useful in HTTP headers and API exchanges where systems need a lightweight way to carry identity or authorisation information.
That convenience is also what makes JWTs easy to misunderstand. A signed JWT is not secret. If somebody can see it, they can usually read its claims even if they cannot alter them successfully. Signing protects integrity and origin, not confidentiality. If you need the contents hidden, the token must be encrypted or the design should keep sensitive information out of the token entirely.
This distinction matters for leaders because JWTs often travel through systems people do not think about much: API gateways, browser storage, reverse proxies, mobile apps, logs, developer tools and third-party integrations. When teams say "it's secure because it's a JWT", the right response is to ask a different question: secure in what sense? Signed? Encrypted? Bound to the right issuer? Intended for this audience? Short-lived? Protected in transit? Stored safely? Those details decide whether the token is trustworthy or merely convenient.
Why it matters
JWTs matter because they sit in the middle of many modern access patterns without always being visible to decision-makers. If your business uses SSO, API integrations, an identity provider, service-to-service authentication, API gateways or AI-connected data tools, there is a good chance JWTs appear somewhere in the flow. Leaders may never decode one by hand, but they still need to understand the questions that make a JWT-based system safe or unsafe.
The attraction is obvious. A JWT can carry the information a service needs without requiring a central lookup for every request. That can make systems faster and easier to scale. It is particularly common when an authorisation server or identity provider issues a token and many downstream services need to evaluate it. A service can inspect a signed token, confirm the signature and key, check the issuer, confirm it is the intended audience, enforce expiry and then proceed.
The danger is just as practical. Because JWTs are easy to pass around, teams are tempted to treat them as trusted by default. Sensitive claims get packed into readable payloads. Expiry windows become too long. APIs accept tokens that were intended for different services. Old keys remain active. Logging systems capture tokens that were never meant to be exposed. Developers decode a token successfully and assume that means they validated it.
That matters in AI-enabled integrations too. If an assistant, tool runner or internal workflow service receives a JWT and uses it to call APIs or fetch internal content, then weak token validation can become a route to broad internal access. The organisation does not need everyone to become a cryptography specialist. It does need everyone approving these systems to understand that tokens are only as trustworthy as the rules around them.
How it works
A JWT usually has three parts separated by dots: a header, a payload and a signature. The header says things like the token type and algorithm. The payload contains claims. The signature, when present, lets the recipient verify that the token really came from the expected issuer and was not changed on the way.
Several claims come up repeatedly. The issuer claim identifies who issued the token. The subject says who the token is about. The audience says which relying party or service should accept it. The expiry claim says when it must no longer be processed. Other time-based claims can say when the token was issued or when it should first become valid.
Signed and encrypted JWTs are different tools. A signed JWT is useful when the recipient needs to trust integrity and origin. An encrypted JWT adds confidentiality so the claims are not visible to ordinary observers. Many teams only use signed JWTs and accidentally assume nobody can read them. That is why it is usually safer to avoid placing secrets, unnecessary personal data or business-sensitive detail in the payload unless there is a clear reason.
Validation is where the real work happens. The recipient must verify the cryptographic operation, ensure the algorithm is one it explicitly accepts, bind the keys to the correct issuer, enforce expiry, and check that the audience includes the current service. If it is handling different token types, it should also apply different validation rules so an ID token cannot be mistaken for an API access token just because both happen to be JWTs.
In OAuth and OpenID Connect, JWTs often appear as ID tokens and sometimes as access tokens. In internal architectures they may also be used between services. That does not mean every token in every system is a JWT. Some access tokens are intentionally opaque and require validation by lookup. That is often a design choice, not a deficiency.
Examples
A straightforward example is an API gateway in front of internal services. The identity layer issues a JWT access token after a user signs in. The gateway checks the signature, issuer, audience and expiry before forwarding the request. Downstream services receive only requests that already passed the front-door checks. That can be efficient and clean, provided the gateway's validation rules are actually strict.
A second example is SSO and OpenID Connect. A business application uses the corporate identity provider for sign-in and receives an ID token in JWT format. The application can use claims in that ID token to establish who the user is. Problems start when teams then present the same token to an API that was expecting a different audience or token type. This is one form of token confusion: the token may be perfectly valid, just not valid for this purpose.
A third example is service-to-service communication. A data processing service calls another internal API using short-lived JWTs issued by a central platform. That can work well because the receiving service can verify the token without storing session state. But if those tokens are long-lived, stored in logs or created with broad audience rules, the supposed convenience spreads risk across the estate.
A fourth example is an AI integration. An internal assistant calls a document API using a JWT-bearing access token from the identity platform. If the assistant is given a token with read access to a wide internal corpus and that token is accepted by several services without tight audience checks, the assistant may reach more information than intended. The token format itself is not the problem. Lax validation and wide scope are.
There is also a common anti-pattern at the browser layer. A team stores JWTs in easily accessible browser storage, includes too much user detail in the payload, and leaves the expiry long to reduce login prompts. That may feel user-friendly, but it expands the blast radius if a token is stolen through browser compromise, XSS or careless logging.
Common misunderstandings
The biggest misunderstanding is that "JWT" means "secure token". JWT is a format, not a guarantee. The token might be signed strongly, signed weakly, encrypted properly, readable by design, long-lived, expired, intended for another service, or accepted by a badly written validator. The label tells you very little on its own.
Another misunderstanding is that if you can decode a JWT, you have validated it. Decoding only reveals the claims. It does not prove the signature is valid, the issuer is trusted or the audience is correct.
Teams also confuse signed with encrypted. A signed token protects against undetected modification, but unless it is encrypted too, the claims are generally visible to whoever sees the token. That is why putting sensitive payload data in JWTs is often a design mistake.
A fourth misunderstanding is that a JWT should be accepted by any service in the same estate. The audience claim exists precisely to stop that kind of substitution. A token intended for one relying party should not become a universal pass.
Finally, some people believe JWTs make revocation irrelevant because expiry exists. Expiry helps, but if tokens are long-lived, poorly rotated or backed by stale keys, the organisation may still struggle to contain misuse quickly.
Risks and boundaries
Weak signature handling remains the classic JWT failure. Some attacks historically relied on libraries or applications accepting the wrong algorithm, accepting unsigned tokens, or confusing symmetric and asymmetric verification paths. The practical lesson is simple: applications should explicitly allow only expected algorithms and reject anything else.
Issuer and audience validation are equally important. If a recipient does not bind keys to the expected issuer, or if it accepts tokens without confirming that it is the intended audience, then a token issued elsewhere may be replayed or substituted in the wrong context. That is not an edge case. It is a recurring implementation mistake.
Token lifetime is another business risk. Long-lived tokens are attractive for usability and background processing, but they increase the value of theft. If a token can be replayed hours or days later, a small leakage event becomes a durable access problem. Shorter lifetime, careful refresh handling and prompt key rotation reduce that exposure.
Readable payloads create a quieter risk. Because signed JWTs are not secret by default, teams should avoid placing sensitive personal data, secrets, internal notes or other material in the claims unless there is a clear, justified reason. If the payload is visible in logs, browser tools or support traces, the organisation may expose information even when the signature is perfect.
Cross-token confusion is another boundary worth naming clearly. The same company may issue several kinds of JWTs for different uses. If validation rules are not mutually exclusive, a token created for login or one service can be misused somewhere else. In plain English: do not accept "any valid JWT"; accept only the exact kind of JWT your service expects.
JWTs also depend on transport and storage. A well-signed token can still be stolen if sent over weak transport or stored carelessly. For UK organisations dealing with personal data, that means JWT design should be considered alongside secure transport, storage, logging discipline and access governance rather than as a self-contained solution.
What to do next
Ask your teams where JWTs are being used and for what purpose. The first goal is not deep protocol analysis. It is simple visibility. Which systems issue them? Which services accept them? Are they ID tokens, access tokens, service tokens or something else?
Next, demand an answer on validation rules. Each receiving service should be able to state which issuer it trusts, which audience it expects, which algorithms are allowed, how expiry is enforced and how key rotation is handled. If the answer is "our library deals with that", the answer is incomplete.
Then review payload design. Make teams justify any personal data or sensitive business information placed in token claims. If the information does not need to travel with the token, it probably should not.
After that, look at lifetime and storage. Ask where tokens are stored, how long they remain usable, what happens when keys rotate, and what the incident response path looks like after a suspected leak. This is especially important for browser-based systems, mobile apps, API gateways and third-party integrations.
Finally, keep the language precise. When a supplier says they use JWTs, ask whether the tokens are signed or encrypted, whether the service validates issuer and audience, and whether the tokens are bearer tokens or bound more tightly. Those questions do not require leaders to inspect code. They do force better answers.
FAQs
Are JWTs only used with OAuth?
No. JWTs are common in OAuth and OpenID Connect, but they are also used in other identity and application designs wherever compact signed claims are useful. Equally, not every OAuth token is a JWT. Some systems use opaque tokens instead. The important point is not the brand of token but whether the relying service validates it correctly and whether the format suits the risk and architecture.
Should we put user roles and permissions inside a JWT?
Sometimes limited claims are useful, but teams should be careful. Roles and permissions inside a token can become stale, over-shared or visible to places that never needed them. If rights change frequently or the data is sensitive, a leaner token plus a controlled lookup can be a better design. Tokens should carry only what is genuinely needed for the use case.
Does encrypting a JWT solve all the risks?
No. Encryption helps protect confidentiality of the claims, but the recipient still needs to validate the cryptographic operations, issuer, audience, expiry and token type correctly. Encrypted tokens can also introduce processing complexity if teams assume decryption alone equals trust. In practice, encryption addresses one risk category. It does not remove the need for strict validation and disciplined key management.
Sources
RFC 7519 - JSON Web Token (JWT) (IETF). Core JWT definition, compact format and registered claims such as iss, sub, aud and exp.
RFC 8725: JSON Web Token Best Current Practices (IETF). Security best practice, algorithm verification, issuer and audience validation, cross-JWT confusion and weak signature risks.
RFC 9068 - JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens (IETF). Context on JWTs in OAuth 2.0 access-token usage.
Testing JSON Web Tokens (OWASP). Practical review points on exp, iat, nbf, signature verification, none algorithm misuse and secure transport.
NIST IR 8587 initial public draft, Protecting Tokens and Assertions from Forgery, Theft, and Misuse (NIST). Higher-level guidance on protecting tokens and assertions from forgery, theft, misuse and poor lifecycle controls.
API authentication and authorisation (NCSC). Practical context for JWTs as part of modern API and identity patterns.