Name the intended resource
01A resource indicator names the service where a client intends to use an access token. Scope separately describes the requested permissions.
This chosen deployment requires tenant=blue to identify the target. It exercises the recognized exception to SHOULD NOT, not a general ban or universal query policy.
Source for this drawing: RFC 8707 · Read RFC section 2 ↗
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
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A resource URI is an identifier, not an instruction to fetch it.
- A client MAY include resource. Its value MUST be an absolute URI and MUST NOT contain a fragment. A query SHOULD NOT be included, but a necessary application-scoping query is allowed.
- The client SHOULD choose the most specific URI for the complete API or resource set, normally its base URI. A tenant-specific path can prevent an overly broad audience.
- Multiple resource parameters MAY request multiple resources. An absolute identifier need not be an HTTPS locator; abstract identifiers require out-of-band validation of the endpoint to which a token is sent.
Four separate URI cases show a base HTTPS locator, an abstract URN, a forbidden fragment and a justified query exception. Relative references also fail the absolute-URI rule. Valid syntax never guarantees that an authorization server accepts or authorizes the target.
Read the RFC section ↗