Visual RFC.
ALL RFCs / RFC 8707
Read the RFC ↗
RFC 8707 / REQUEST A TOKEN FOR ITS TARGET

Select an audience at the token endpoint

03

A client can request a calendar token from a two-resource grant, then use the refresh token to request a contacts token under server policy.

DIAGRAMRead RFC section 2.2 ↗
RFC 8707 · § 2.2EXAMPLE
4 / 4
Select an audience at the token endpointThe stored original grant covers calendar and contacts. A code request selects calendar, then the server returns A-cal and refresh token R-full; the server maps calendar to audience urn:example:cal. A later refresh request selects contacts under the original grant and returns A-contacts. R-full is sent only client to authorization server, never to either API. Labels are fictional opaque tokens with explanatory audience metadata.Access token subset · refresh retains full grantClientAuth servertoken responseSelected response fields · fictional token value{"access_token":"A-contacts", "token_type":"Bearer","scope":"read"}A-contacts audience → contacts APIOriginal grant: calendar + contactsR-full remains bound to this full grantServer policy controls acceptable resource selections
04
Return a separate contacts access token.

The second token has a contacts audience. The first token’s audience did not expand, and the refresh token was not presented to contacts.

Source for this drawing: RFC 8707 · Read RFC section 2.2 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A key is different from permission.

An app, a person, and a server have different roles. Follow who asks, who grants permission, and who checks the credential. A key in the drawing is an analogy, not a literal protocol field.

Helpful first, if these ideas are unfamiliar

RFC 6749 OAuth 2.0 RFC 6750 Bearer tokens RFC 9700 OAuth security

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.

KEY POINT

Selecting one token audience does not shrink a returned refresh token’s original grant.

  • Resource applies to access token requests for all grant types. Acceptable values are at the authorization server’s sole discretion; for code and refresh grants its policy may limit values to the original authorized resources or a subset.
  • For a code request selecting a subset, the access token is based on that subset while any returned refresh token remains bound to the full original grant. Refresh tokens go to the authorization server, not to the APIs.
  • The authorization server SHOULD audience-restrict issued tokens. It can use the exact resource URI as the audience or map it to a more general URI or abstract identifier. A JWT aud claim or introspection aud member can convey that restriction; JWT is not required.
DETAILS

The sequence assumes an original grant for calendar and contacts and a policy allowing either separately. Opaque QA token labels are fictional. Audience/scope labels are explanatory metadata, not decoded or validated JWTs. No new code is redeemed a second time; the second request uses the refresh token. Client authentication, TLS, PKCE, refresh-token replay protection and token verification follow their applicable OAuth rules and are omitted from this resource-focused view.

Read the RFC section ↗

All chapters in RFC 8707

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 ↗