Visual RFC.
ALL RFCs / RFC 7519
Read the RFC ↗
RFC 7519 / IDENTITY & AUDIENCE

Who said it, and who is it for?

03

Issuer, subject, and audience describe different roles in a claim.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

RFC 7519 · § 4.1.3EXAMPLE
4 / 4
Who said it, and who is it for?One issuer asserts a subject and audience; a fork distinguishes the intended service from another service.The recipient is part of validationIssuersub: user-42aud: ordersordersbillingintendedsame tokenwrong audience → reject
04
Apply recipient checks.

The billing service cannot accept this token under the illustrated audience policy.

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
KEY POINT

A token for one service is not automatically valid at another.

  • When aud is present, a processor that is not an intended audience must reject the JWT.
  • aud can be a single string or an array of strings.
  • sub must be locally unique within its issuer or globally unique.
DETAILS

The examples simplify the wire representation. Follow the linked specification and application profile for implementation.

Read the RFC section ↗

Diagrams simplify the RFC. Read the linked sections for complete requirements.

Privacy
All chapters in this RFC
  1. A compact token comes apart
  2. Claims live on a timeline
  3. Who said it, and who is it for?
  4. Signing is not hiding
  5. Validation is a chain of checks
  6. Trust comes from outside the token

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗