Aaron and I drafted an update to RFC9728 that relaxes the processing rules as discussed in this thread.
https://datatracker.ietf.org/doc/draft-mcguinness-oauth-rfc9728bis/ We would appreciate feedback from the WG on this proposal. -Karl On Fri, Feb 13, 2026 at 2:33 PM Aaron Parecki <[email protected]> wrote: > 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` <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]
