Hello OAuth Working Group,
I have had a few side discussions in different channels, but I wanted to bring this topic to the mailing list to get WG guidance on token caching and reuse when clients dynamically discover protected resources using the Protected Resource Metadata specification (RFC 9728) and subsequently request access tokens using Resource Indicators (RFC 8707).
In short, dynamic resource discovery today leaves clients without a reliable way to determine whether an access token issued for one endpoint can be safely reused for other endpoints on the same TLS host, even when those endpoints share an authorization server and audience. This is especially problematic as RFC 9728 Section 3.3 requires that when protected resource metadata is retrieved via a WWW-Authenticate: Bearer resource_metadata=… challenge, the resource value in that metadata MUST exactly match the URL the client used to access the protected resource; otherwise, the metadata must be ignored. This rule is important for preventing impersonation and metadata substitution attacks.
This ambiguity increases token request round trips for clients and requires authorization servers to understand how many endpoint-level resource identifiers map to a given audience. Related discussion of this ambiguity can be found in https://datatracker.ietf.org/doc/draft-mcguinness-oauth-resource-token-resp/
Example
Consider a resource server at https://api.example.com exposing protected endpoints such as /accounts, /transactions, and /profile.
If a client first calls https://api.example.com/transactions without a token, the resource server responds with a WWW-Authenticate challenge pointing to protected resource metadata whose resource value must be https://api.example.com/transactions. The client then requests an access token using that value as the resource indicator. While the authorization server may issue a token whose audience is valid for multiple endpoints (e.g. https://api.example.com), the client has no standardized way to determine which other endpoints, if any, can safely reuse that token.
Ideally, a client should be able to maintain a “token jar” keyed by authorization server + audience, allowing a single token to be reused across multiple endpoints on the same host that advertise the same authorization server and validates the same token audience.
Possible approaches
The following are some solutions that have been previously been discussed
Relax the resource-matching rule of RFC 9728 to the same TLS host
Permit the resource value in protected resource metadata to represent a higher-level audience for the resource server (e.g. https://api.example.com/), as long as it shares the same TLS host as the requested URL. This would preserve the origin security property while enabling clients to request and reuse tokens across multiple endpoints without enumerating every path. A client would continue to use the discovered resource value as the resource indicator but also be able to reuse a previously issued non-expired token for any protected resource that shares the same resource value on the same TLS host for a scope that was previously granted from the same authorization server. This would be a normative change to the Protected Resource Metadata specification (RFC 9728)
Use the realm parameter in HTTP Authorization Challto convey audience
Include a realm parameter in the WWW-Authenticate header (e.g WWW-Authenticate: Bearer realm="https://api.example.com" resource_metadata=…). As noted in RFC 6750, a realm can indicate a scope of protection similar to an HTTP authentication protection space. The protected resource metadata would continue to identify the specific endpoint as the resource value, while the realm would signal a broader audience that clients could use as the resource indicator in token requests. A client would use the realm parameter instead of the protected resource metadata resource value as the resource indicator and reuse a non-expired token for any protected resource that shares the same realm on the same TLS host for a scope that was previously granted from the same authorization server.
I would appreciate the WG’s guidance on which direction (or alternative) best enables interoperability and safe token reuse while fitting the intent of existing specs.
Thanks,
Karl
