RFC 7519, the IETF standard that defines JSON Web Tokens, notes in its introduction how to say the name: the pronunciation "is the same as the English word 'jot'." The rest of the document is about what a JWT carries and how a receiving system decides whether to believe it.

The definition in the abstract is short. A JWT "is a compact, URL-safe means of representing claims to be transferred between two parties." The RFC defines a claim as "A piece of information asserted about a subject." In practice that might be who the user is, which application the token is meant for, and when it stops being valid.

What a JWT looks like

A JWT "is represented as a sequence of URL-safe parts separated by period ('.') characters." In the signed form, using the JSON Web Signature compact serialization, there are three parts. The first is a header that names the algorithm used to protect the token. The second is the set of claims. The third is the signature, or a MAC (message authentication code), computed over the first two.

The worked example in RFC 7519 builds a token whose claims are an issuer of joe, an expiry time, and one custom value. Each part is base64url-encoded, then the three are joined with dots. The result is a long string beginning eyJ, which is a useful thing to recognise when a buyer pastes one into a chat.

Base64url is an encoding. Anyone holding the string can decode the header and claims back to readable JSON. Whether the contents are also hidden depends on how the token was built. The abstract says the claims can be "digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted." Signing goes through the JSON Web Signature structure, defined in RFC 7515, and encryption goes through a separate structure called JSON Web Encryption. A token that is signed and not encrypted can be decoded and read by anyone who holds it.

The claims you will hear named

RFC 7519 registers seven claim names. Each is optional, and a product decides which ones it uses.

iss is the issuer, the party that created the token.
sub is the subject. The RFC says it "identifies the principal that is the subject of the JWT."
aud is the audience, the recipients the token is intended for.
exp is the expiration time.
nbf is "not before", the time before which the token must not be accepted.
iat is the time the token was issued.
jti is a unique ID for the token.

Two of these carry hard rules. For exp, the token "MUST NOT be accepted for processing" on or after the listed time, though the RFC lets implementers allow "some small leeway, usually no more than a few minutes, to account for clock skew." For aud, a system processing the token must find itself in the audience list when the claim is present; otherwise "the JWT MUST be rejected."

The jti claim matters when a buyer asks about replay. RFC 7519 says it "can be used to prevent the JWT from being replayed." That is a capability. Whether a given product actually tracks token IDs is a question for its documentation.

Why a signature alone is not enough

The RFC's security section puts the core idea plainly: "The contents of a JWT cannot be relied upon in a trust decision unless its contents have been cryptographically secured and bound to the context necessary for the trust decision."

RFC 8725, the IETF's best-current-practice document for JWTs, describes what goes wrong when a token is trusted without those checks. It describes attacks where "the algorithm can be changed to 'none' by an attacker, and some libraries would trust this value and 'validate' the JWT without checking any signature." It describes another where an RSA algorithm value is swapped for an HMAC one so a library verifies against the wrong kind of key.

The fixes it requires are specific. Libraries "MUST enable the caller to specify a supported set of algorithms and MUST NOT use any other algorithms." When a token has an iss claim, the application "MUST validate that the cryptographic keys used for the cryptographic operations in the JWT belong to the issuer." Where one issuer creates tokens for more than one application, the receiving side "MUST validate the audience value."

Implementing these checks is engineering work. A rep only needs to know which ones a reviewer may name: algorithm, issuer, audience and expiry.

Where JWTs show up in a deal

JWTs appear inside other standards. The OpenID Connect ID token, which tells an application who signed in, is a JWT, as OpenID Connect Core defines it. For the login side of a deal, see how to answer SSO questions; access tokens are issued through the flow in what OAuth is.

Take a hypothetical company, Northwind, whose security review covers your API tokens. What the reviewer needs to know is whether a stolen token stays valid, and that depends on the exp values your product sets and on whether it can revoke a token before then.

Five things to check about your own tokens

The checks above become five questions about your product:

Which algorithm signs your tokens, and is the accepted set fixed on the server side?
How long until a token expires?
Are tokens signed only, or also encrypted?
What does the aud claim contain, and is it checked?
Is there a way to revoke a token before exp?

The fourth question maps to RFC 8725 section 3.9. The fifth has no answer in RFC 7519, which limits a token's life with exp and nbf but defines no way to revoke a token early.