Separate permissions from destinations
04Requesting two scopes for two resources asks for each scope at each resource. It does not describe a different private scope list for each destination.
The response includes scope=read because it differs from read write. Omitting that change would violate the base OAuth response requirement.
Source for this drawing: RFC 8707 · Read RFC section 2.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.
Two scopes and two resources describe four requested combinations.
- The request semantics are the cartesian product: all requested scopes at all requested target services. The server may be unable or unwilling to fulfill that combination and can return invalid_target.
- To the extent possible, the server should downscope each token to permissions the respective resource can process and needs to know. This limits unnecessary cross-service disclosure; the RFC states this in lowercase should.
- When the issued scope differs from the requested scope, the server MUST include the effective scope in the response under RFC6749 §§3.3/5.1. A narrowed scope is not hidden from the client.
The matrix is a request, not proof of consent or a granted privilege. Separate branches show a rejected two-resource combination and a successful single-resource/read-only result under a chosen policy. The refresh token and other grant rules still bound the available authorization.
Read the RFC section ↗