I’d discussed some of this 1:1 recently with Aaron (thanks Aaron!). Here are some of my thoughts. Note that I’m intentionally asking questions about the security assumptions and model that take a particular point of view, but I’d be open to being convinced that that I’m wrong.
In my current view of the situation, these are all distinct protected resources: https://api.example.com/accounts https://api.example.com/transactions https://api.example.com/profile Just like these are all distinct protected resources that might be hosted by the same resource server: https://example.com/tenant/11169c3e-4250-4f78-af6b-7db53dc64dcd https://example.com/tenant/ba26277e-fe1a-4c75-b526-cbf8838ad55a https://example.com/tenant/79e7e5bc-a8cb-40eb-80f8-72fe4a679562 The audience in the access token will scope the access token to a particular protected resource. The audience doesn’t utilize any form of wildcarding. Likewise, the WWW-Authenticate response will return information about the specific resource that was attempted to be accessed – for instance, https://api.example.com/profile or https://example.com/tenant/79e7e5bc-a8cb-40eb-80f8-72fe4a679562. Again, no wildcarding will occur. So the exact match required by RFC 9728 can be performed. All is good. The new draft talks about multiple protected resources being hosted by the same resource server. That’s an implementation detail that doesn’t have any impact on the protocol. Being hosted by the same resource server doesn’t mean that access to all the hosted protected resources is granted if it is to any of them. Wildcarding resource access decisions is a recipe for security breaches. We wrote what we wrote about using exact match in RFC 9728 for that reason. It’s the same reason, for instance that exact match is required for redirect_uri values by OpenID Connect. Hopefully we can discuss this in Shenzhen. Cheers, -- Mike From: Karl McGuinness <[email protected]> Sent: Tuesday, February 24, 2026 1:17 PM To: Aaron Parecki <[email protected]> Cc: [email protected] Subject: [OAUTH-WG] Re: Token Reuse with Protected Resource Metadata Challenges 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]<mailto:[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]<mailto:[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<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<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) 1. 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<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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
