Selecting the intended resource
The Scopes and audiences lesson gave the photo service a second API, the sharing API at https://share.photos.example, and gave the printer a reason to use it. It also showed where the usual way of choosing an audience runs out. A server that works out the audience from the requested scopes cannot do so when one request asks for scopes that belong to different APIs, and the JWT access token profile says it should refuse such a request rather than guess.
Inferring the audience from scopes has other limits as a service grows. Two APIs may each want a scope called read. One scope may make sense at several APIs. A server protecting dozens of APIs would need a rule for every combination, and the client would still have no way to say which API it meant. That lesson mentioned the way through: a request parameter with which the client names the API.
Naming the API
Resource indicators, published as RFC 8707 in February 2020, add one optional parameter to requests sent to the authorization server: resource. Its value identifies the protected resource where the client intends to use the token. In practice that is usually an API, named by its address.
In a request, scope says what kind of access the client wants and resource says where it will use it: the request-side counterparts of a token's scope and audience. Knowing the destination lets the server restrict the token's audience to that API. It also lets the server shape the token for its recipient: which format to use, which claims that API needs, whether to encrypt the token for it, and which of the granted scopes mean anything there.
Writing a resource value
A resource value must be an absolute URI, which means it includes a scheme such as https. It must not contain a fragment, the part after a #. It should not contain a query either, although the specification accepts that a few APIs use a query parameter as part of their identity.
The value identifies the API. It may also be the address where the API can be reached, and that is the usual choice: the client should send the most specific URI that covers the whole API it intends to use, which for most APIs is its base URI. If the sharing API lived at https://api.photos.example/sharing/ instead of on its own host, the resource value would include that path, so that it named the sharing API rather than everything on the host.
| Value | Assessment |
|---|---|
https://api.photos.example | Suitable. The base URI of the photo API. |
https://api.photos.example/albums/42 | Valid syntax, but it names one album rather than the API, so a server expecting the API's identifier will not recognize it. |
api.photos.example | Not allowed. Without a scheme, it is not an absolute URI. |
https://api.photos.example#photos | Not allowed. It contains a fragment. |
https://api.photos.example?version=2 | Discouraged. A query belongs only when it is part of how the API is identified. |
The client takes the value from the API's documentation or its own configuration and sends it exactly. https://api.photos.example and https://api.photos.example/ are different strings, and a server that compares values exactly will treat them as different resources.
In the token request
The parameter also works in token requests, whatever the grant type. There it names where the token being requested will be used. The printer's code exchange adds the same value and authenticates with its usual Basic header:
POST /token HTTP/1.1
Host: auth.photos.example
Authorization: Basic cGhvdG8tcHJpbnRlcjpkZW1vLW9ubHktbm90LWEtcmVhbC1zZWNyZXQ=
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&code=demo-code-7
&redirect_uri=https%3A%2F%2Fprinter.example%2Foauth%2Fcallback
&code_verifier=btl_training_verifier_for_one_attempt_only_2026
&resource=https%3A%2F%2Fapi.photos.exampleThe access token that comes back is the one Token formats and validation decoded, with "aud": "https://api.photos.example". The difference is how the server arrived at it: the printer asked for that audience instead of leaving the server to infer it from photos.read. For JWT access tokens, the JWT access token profile says the audience should be the same value as the requested resource.
Other grants work the same way. The printer's evening job from Client credentials could add resource=https%3A%2F%2Fapi.printlab.example to its token request at the print lab, so that the token names the lab's API.
A client can also leave the parameter out. The server may then treat the request as being for no particular resource or fall back to a default, often worked out from the scopes as the Scopes and audiences lesson described. A JWT access token always needs an audience, so a server issuing one must use a default when no resource is named. A server may instead require clients to name a resource and refuse requests that do not, with the error invalid_target. Which behavior applies is the server's policy, and its documentation tells clients what to send.
Naming one API is the simple case. Sending a preview of album 42 to your family takes tokens for two APIs from the same authorization.