TechCompare LogoTechCompare

JWT registered claims: iss, sub, aud, jti and what to check

After the signature passes, check iss and aud as carefully as exp. A valid token for a different service is still the wrong token.

RFC 7519 reserves seven short claim names so every library reads them the same way: iss (issuer), sub (subject), aud (audience), exp (expiration), nbf (not before), iat (issued at) and jti (JWT ID). All of them are optional in the standard. Profiles like OpenID Connect and the OAuth access token profile in RFC 9068 make several of them required.

By TechCompare · Updated

Topic
Registered claims
Token claims
Category
Fundamentals
How JWTs are built and read
Try the live JWT Decoder. Decode a token, read its time claims, and verify the signature in your browser.
Edit in the full tool

How this is calculated

iss is a string, usually the issuer's URL, and your verifier should compare it with an exact value, not a prefix. sub identifies who the token is about, often a user ID. It's only unique within one issuer, so store the iss and sub pair if you map tokens to accounts. aud names the service the token is for. It can be a string or a list of strings, and RFC 7519 says a service must reject a token whose aud is present but doesn't include it. Skipping the aud check is a common bug: a token meant for a low value app works against a sensitive API that trusts the same issuer. exp, nbf and iat are the time claims, written as seconds since 1970. jti is a unique ID for the token, which a server can store to stop a token from being replayed, like a one time link. Beyond these, providers add their own claims: scope or scp for OAuth permissions, azp and nonce in OpenID Connect ID tokens, and custom names like roles or tenant. Custom claims should use names that won't collide, like a URL, if the token crosses organizations. The JWT Decoder labels every registered claim and common OpenID Connect claim, and flags iss, sub, jti or aud values with the wrong type.

Verdict

Require exp, check iss against one exact value, check that aud includes your service, and only then read sub, scopes and roles. Treat every other claim as input from the issuer, not as proof of anything on its own.

More JWT scenarios

Decode vs verify
Anyone can read a JWT. Only a signature check with the right key tells you who wrote it.
View details ➜
exp, nbf and iat
The three time claims, what each one means, and how verifiers compare them with the clock.
View details ➜
Fixing jwt expired
Why fresh tokens fail with "jwt expired" and how clock drift, leeway and milliseconds cause it.
View details ➜

Related guides

JSON Schema validation
Describe the claims your service expects.
View guide ➜

Frequently asked questions

Which JWT claims are required?
None, in RFC 7519 itself. In practice you should require exp, and OpenID Connect ID tokens must include iss, sub, aud, exp and iat. RFC 9068 access tokens require iss, exp, aud, sub, client_id, iat and jti.
Can aud be a list?
Yes. aud can be a single string or an array of strings. A service accepts the token if its own identifier appears in the list.
Should I put user roles in a JWT?
You can, but remember they're frozen until the token expires. A user whose role was removed keeps it for the rest of the token's lifetime, so keep tokens short or check sensitive permissions on the server.

Related tools

Text Encoding Converter

Convert between Text, Base64, Binary, Hexadecimal, and Decimal formats.

Use tool ➜

Unix Timestamp

Convert between Unix timestamps and human-readable dates.

Use tool ➜

JSON Formatter

Validate, format, and minify JSON. Browse it as a tree, run JSONPath queries, compare two documents, or validate against a JSON Schema.

Use tool ➜