A JWT (JSON Web Token) is a compact, digitally signed token that securely carries a set of claims — such as who a user is — between two parties. After you log in, a server can hand your application a JWT that says, in effect, "this is user Jordan, authenticated a moment ago, permitted to act as an editor." Your app then presents that token on later requests, and the server trusts it because the token is signed and any tampering would break the signature. JWTs are everywhere in modern web and API security precisely because they are small, self-contained, and easy to pass around in an HTTP header.
Why It Matters
Web servers often need to remember that you are logged in across many requests. One traditional approach keeps all session data on the server and hands the browser a reference to it, which means every request forces a lookup in a shared session store. That works, but it can become a bottleneck as systems scale across many servers.
JWTs offer a different model: put the essential facts inside a signed token the client carries. Because the token is self-contained and its integrity is verifiable through the signature, any server holding the right key can validate it without a central lookup. This stateless quality makes JWTs a natural fit for APIs and distributed systems where requests may hit different servers. They are also the standard format used by OpenID Connect for ID tokens, so understanding JWTs unlocks a large part of how modern identity works. That power comes with sharp edges, though — a JWT is only as trustworthy as the validation performed on it.
A Simple Analogy: A Festival Wristband
Think of a JWT like a tamper-evident festival wristband. When you enter, staff verify your ticket once and fasten a wristband that encodes what you paid for — general admission, VIP, backstage. For the rest of the event, any staffer can glance at the wristband and instantly know your access level without calling back to the box office. The wristband is built so it cannot be altered without visibly breaking. A JWT works the same way: it encodes your claims in a form that any server can read at a glance and verify has not been tampered with.
How It Works
A JWT has three parts, separated by dots, in the form header.payload.signature:
Header → which signing algorithm and token type
Payload → the claims (e.g. user id, role, expiry time)
Signature → a cryptographic seal over the header and payload
The header and payload are JSON that is encoded (not encrypted) into a URL-safe string, so anyone can read them. The magic is in the signature: the issuing server signs the header and payload with a secret key or private key. When the token comes back, a server recomputes the signature and compares. If they match, the token is authentic and unaltered; if even one character of the payload was changed, the check fails.
Two points follow directly. First, because the payload is only encoded, you must never place secrets in it — anyone can decode and read it. Second, because a valid signature is the whole basis of trust, servers must verify it correctly, insist on a strong algorithm, and honor the token's expiry time.
Key Things to Know
The three parts and their purposes are worth memorizing:
| Part | Contents | Protected by |
|---|---|---|
| Header | Algorithm and token type | The signature |
| Payload | Claims about the user | The signature |
| Signature | Cryptographic seal | The signing key |
The most important takeaway is that a JWT is signed, not encrypted by default. Signing proves the token is authentic and unchanged; it does not hide the contents. Treating the payload as private is a common and dangerous mistake — anyone who intercepts the token can read every claim inside it.
How Safeguard Helps
JWTs are created and verified through open-source libraries, and the history of these libraries includes some infamous vulnerabilities — accepting the insecure "none" algorithm, or confusing signing key types in a way that lets attackers forge tokens. A flaw in your JWT library can quietly enable full authentication bypass. Safeguard's software composition analysis inventories the JWT libraries in your project and flags any with known vulnerabilities so those weaknesses do not linger.
Because a raw findings list is hard to act on, Griffin AI surfaces the flaws that affect code your application actually runs and explains each in plain language. To learn the connected standards — OAuth, OpenID Connect, and single sign-on — the concepts library breaks them down simply. To see your own dependencies analyzed, create a free account, or build your foundations step by step in Safeguard Academy.
Frequently Asked Questions
Is a JWT encrypted?
By default, no. A standard JWT is signed, which guarantees it has not been altered and genuinely came from the issuer, but its header and payload are merely encoded and can be read by anyone who holds the token. If you need the contents kept confidential, a separate encrypted variant exists, but the common JWT you encounter should never carry secrets in its payload.
What are claims in a JWT?
Claims are the individual statements inside the payload, such as the user's identifier, their role, when the token was issued, and when it expires. Some claim names are standardized, while applications can add their own. Claims are what let a server make decisions from the token alone, which is why verifying the signature that protects them is essential.
Why should JWTs expire?
Because a token is trusted as long as its signature is valid, a token that never expires is effectively a permanent credential — dangerous if it is ever stolen. An expiry claim limits how long a leaked token remains useful. Short lifetimes, often paired with a refresh mechanism, keep the risk contained while preserving a smooth user experience.
What is the "none algorithm" vulnerability?
It is a classic JWT flaw where a token declares its signing algorithm as "none," meaning no signature at all. A library that honors this setting will accept unsigned tokens as valid, letting an attacker forge any claims they like. Reputable libraries now reject "none" and require an explicit, strong algorithm, which is why keeping JWT dependencies current matters so much.