I agree with the need to solve for this problem. This is not the first time that I've heard the feedback that the exact matching rule in RFC9728 is too strict. The example Karl gave is one, but another example is when making a request to a specific resource, e.g. ` https://example.com/photo/1024`, or to a URL with query strings. It quickly becomes impractical to require that the resource value in the metadata is an exact match of the URL the resource request was made to. Filip actually opened an issue about this in the spec, https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/issues/66 Unfortunately it was opened after RFC9728 was already in the publication queue.
I would be open to revising RFC9728 to relax this requirement to something like matching hostnames or prefix matching. It's not quite an errata, but maybe a RFC9728 bis? I've always thought of this as "Resource Server Metadata" analogous to "Authorization Server Metadata", rather than thinking about the metadata describing a particular resource like an individual object. That's why to me it feels within the spirit of the doc to correct the validation rule to match based on the resource server identity. Aaron On Fri, Jan 16, 2026 at 12:15 PM Karl McGuinness <[email protected]> wrote: > 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 > > 1. > > *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) > 2. > > *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 > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
