Visual RFC.
ALL RFCs / RFC 7523
Read the RFC ↗
RFC 7523 / SIGNED STATEMENTS FOR OAUTH

A sealed note can still be read and copied

07

A signature detects changes. It does not hide the note or make its bearer the original holder. Permission is a separate decision.

RFC 7523 · § 7EXAMPLE
1 / 4 · Read the signed note

Signing provides a change check, not secrecy.

A signature is not a locked envelopeSigned noteClient can read it
Signed claimsReadable by the client

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.

4 / 4
04
Apply the permission policy

Server permission policy still decides which access, if any, to issue.

A sealed note can still be read and copiedServer permission policy still decides which access, if any, to issue.A signature is not a locked envelopeSigned noteClient can read itHTTPS channelProtects transitBearer holderOriginal holderServer policyRead allowed✓Token can be issued

Key idea: Protect delivery, share fewer claims, and check permission separately.

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.

Look up a term in the glossary ↗

Rules & examples

These reference examples may differ from the selected experiment.

  • Use encrypted channels to avoid disclosure. If the client must not see claims, encrypt the JWT for the authorization server as well. Include only the information necessary. A bearer assertion is not DPoP or a key-bound access token; optional replay defenses matter. This experiment assumes unused, in-time assertions, valid signatures, and no extra client login requirement; issuance still depends on server policy.

Bounded offline examples; crypto fixtures are separate from the selected trust and permission policy.

Sources
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
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.

All chapters in RFC 7523

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 ↗