Thanks for the comments Mike. RFC9728 along with CIMD ( https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/) enable clients to discover resources at runtime and dynamically obtain access tokens needed for a protected resource.
This is a significant shift in assumptions regarding how clients have historically been built. Developers previously needed to read API docs to determine how an authorization server + scopes map to the set of APIs offered by the service provider. A client SDK would then be built (or downloaded if an existing SDK was published) to obtain a refresh token/access token with the necessary scopes for its intended use cases, reusing access tokens for all required APIs. A client SDK such as an agent built for a dynamic model currently has no way to know the boundary of an access token. Every protected resource the client wants to interact with will have its own `resource` identifier published in the protected resource metadata as described in the proposal. The SDK can't a priori determine if 2 protected resources share the same audience, and therefore whether it can reuse an existing token or needs to request a new token. The net result is that the SDK must obtain a token for every unique resource it interacts with as noted in the proposal. This is not feasible in practice when interacting with large resource graphs due to user interaction (which may require front-channel authorization requests), performance and scale requirements. It also shifts a significant amount of volume to the Authorization Server that it previously wasn't expecting, likely hitting rate limits. The gap here is that with the existing specifications, a client can't determine at runtime which protected resources share the same token boundary (e.g audience) nor can it determine the result of requesting a token with a resource indicator (see https://datatracker.ietf.org/doc/draft-mcguinness-oauth-resource-token-resp/). This is further complicated by the fact that multiple authorization servers could be valid for a given protected resource, according to RFC 9728. These gaps significantly limit the intended use case of dynamic resource discovery 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. I disagree with this assessment. There is no requirement that the audience of an issued token must be 1:1 to the protected resource URL nor is there a requirement that the result of resource indicator request to an authorization server result in a 1:1 token audience (see https://datatracker.ietf.org/doc/draft-mcguinness-oauth-resource-token-resp/) . Many authorization servers today issue tokens with a wild-card audience (e.g https://api.example.com) and don't support fine-grained per-URL audiences. Instead they model scopes as a URI per resource type so that a single token can be used for multiple APIs and defer fine grained authorization requirements to the resource server. 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. The language around "multiple protected resources being hosted by the same resource server." in the draft proposal attempts to address the impersonation/phishing security considerations of a protected resource falsely publishing a `resource` value that the current RFC addresses with strict validation. It moves the root of trust to the TLS host the client is interacting with which the proposal maps to the "resource server" role in OAuth. The TLS Host needs to ensure that all metadata documents published for its protected resources accurately reflect the right boundaries. This is similar to how browsers leverage same-origin for CORS, cookies, etc which was purpose built for dynamic resource discovery. Note that my original post suggested an alternative approach that could also be explored if folks are interested. The protected resource metadata (and/or HTTP Authorization Challenge) could indicate an identifier to the client that it can use to correlate a set of resources to a token boundary. This wasn't explored because Aaron commented that relaxing validation in the current RFC aligns with the spirit of the specification of metadata not necessarily being per-object. I am not attending IETF 125 but I know Aaron is so hopefully folks continue the discussion there and report back any conclusions. Thanks, Karl On Tue, Feb 24, 2026 at 1:56 PM Michael Jones <[email protected]> wrote: > 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]> 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]
