Check the names on the note
04Who wrote it? Who is it about? Which server should receive it? Those are three separate labels.
iss names the issuer; sub names who the statement is about.
Offline worked example. Only the public signature/MAC fixtures receive real local cryptographic checks. Other trust, grant, clock and permission inputs are selected teaching cases.
What happens if you change this?
Predict whether the request will pass. Change one choice to see why; use Restart to restore the original example.
Missing required claims and exact-name mismatches stop this check.
Key idea: The audience identifies this server; the subject’s meaning depends on the job.
Terms
- assertion
- A statement another system can check; here it is carried as a JWT.
- authorization grant
- Evidence supporting a request for an access token.
- client authentication
- Checking which app made the request.
- token endpoint
- The server address where an app requests tokens.
- JWT
- JSON Web Token: a compact container for named statements.
- issuer
- The system that created the statement.
- subject
- Who or what the statement is about.
- audience
- The intended receiver of the statement.
- claim
- A named piece of information inside the JWT.
- signature
- A checkable result over bytes made with a secret signing key.
- MAC
- A check over bytes made with a key shared by the parties.
- RS256
- A secret signing key makes a checkable signature; a matching shareable key checks it.
- HS256
- A shared secret lets either party make and check a result over the bytes.
- exp
- Required ending time for using this JWT.
- nbf
- Optional time before which this JWT must not be accepted.
- iat
- Optional time when the JWT was issued.
- jti
- Optional identifier for this JWT; a server may remember it to detect reuse.
- scope
- The named permission requested, such as reading pictures.
- bearer assertion
- A statement usable by someone who possesses it, without proving possession of a separate signing key on each request.
Rules & examples
The audience identifies this server; the subject’s meaning depends on the job.
These reference examples may differ from the selected experiment.
- iss, sub, aud and exp are required. With no overriding application profile, compare issuer and audience using simple string comparison. aud must include the authorization server’s configured identity; the token endpoint URL MAY be that identity but need not be. For client authentication sub MUST equal client_id. Grant subjects may identify a person, delegate, or a pseudonymous/anonymous principal. Other JWT validation remains required.
Bounded offline examples; crypto fixtures are separate from the selected trust and permission policy.
iss, sub, aud and exp are required. With no overriding application profile, compare issuer and audience using simple string comparison. aud must include the authorization server’s configured identity; the token endpoint URL MAY be that identity but need not be. For client authentication sub MUST equal client_id. Grant subjects may identify a person, delegate, or a person or other subject using a substitute name. Other JWT validation remains required.
Sources
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.