Platform

Platform overview How it works Authorization testing Evidence & reports Private scanning Integrations

Solutions

Security agencies Product teams Regulated industries Partner programme

Learn

Blog Knowledge hub Compare

Resources

Pricing Documentation FAQ Security & data What we haven’t proved

Company

About Contact Careers Sign in to the platform Start a $199 pilot

Home / Knowledge hub / JWT

Knowledge hub

JWT

A signed token a client carries to prove who is signed in.

What it means

A JSON Web Token is a compact, signed piece of data that a client sends with each request to say who it is. RFC 7519 defines the format. It usually carries a user id, sometimes a role, and an expiry time.

The signature proves your server issued it, so the server trusts the contents without a lookup. That is the appeal. Sessions mean a database hit on every request, while a token carries its own answer across as many services as need it.

Why it matters

The trade is revocation. A token stays believed until it expires, and there is no central list to remove it from. Signing somebody out, killing a stolen token or demoting a user takes effect only when the clock runs down. Long expiry, long window.

The signature carries the rest of the weight. If the key is weak, shared across environments or checked loosely, an attacker mints tokens claiming to be anyone. PortSwigger's classic case is a server that accepts alg set to none. RFC 8725 exists because these mistakes keep repeating.

How it shows up

Check that the server pins the algorithm and refuses anything else. Check that expiry is short with a refresh token behind it. Check that the signing key differs per environment and never sits in the repository. Check that a role claim means only what your access checks make it mean.

Remember the payload is encoded rather than encrypted. Anyone holding the token reads it in a second, so keep private data out of it. We test the login you actually shipped, and each finding arrives with the request, the response and the source line.

Questions people ask

JWT, answered

Should I use JWTs instead of sessions?

Only if you need what they give you. Tokens suit many services that all have to identify a caller without sharing a session store.

For a single server-rendered application, a session cookie is simpler and easier to revoke. Plenty of teams reach for tokens and inherit a revocation problem they never needed.

Can I revoke a JWT before it expires?

Not by itself. That is the trade you accepted when you chose a token nobody has to look up.

The practical answers are short expiry with refresh tokens, a denylist of token identifiers, or a version number on the user record that invalidates older tokens. Each one gives back a little of the statelessness you were buying.

Is the payload encrypted?

No. It is base64 encoded, which anyone can decode in a browser console. The signature stops somebody changing it, and nothing stops them reading it.

Keep personal data, internal identifiers and anything sensitive out of the claims.

What is the alg none attack?

An attacker changes the header to say the token is unsigned, then edits the payload to claim any identity. A server that trusts the header accepts it.

Fix it by pinning the algorithms you accept on the server side and rejecting everything else, which is what RFC 8725 recommends.

How long should a token live?

Short enough that a stolen one stops working quickly. Minutes for access tokens is common, with a longer refresh token that you can revoke.

Watch what happens on refresh too, since a refresh endpoint that never checks whether the account is still active undoes the whole arrangement.

Who else could mint your tokens?

We test the login you actually shipped: expiry, signature handling and what a token really buys whoever holds it. Findings arrive with the request and the source line. Ask about a pilot.

Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.