Thanks for the feedback Filip. My intention was not to prevent an OP from issuing an access token for both userinfo and a requested `resource` which may be hosted in a different resource server. I think I was expecting userinfo to remain an implicit resource and not explicit in the token response.
I can see how the processing rules might be too strict if the OP wanted to return the userinfo resource as an additional value then what was requested. I will open a github issue for us to discuss further. I’m confident we can find the right language to support this use case. -Karl On Sun, Mar 1, 2026 at 5:02 AM Filip Skokan <[email protected]> wrote: > Hello Karl, > > This discussion has eluded my attention so far. > > 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/ > > > I took a look at this I-D after Aaron pointed it out to me in this thread > <https://mailarchive.ietf.org/arch/msg/oauth/TZmJLyi6HilyGfOBhRCkEfAhL2Y/> > from > today. It would appear we're looking at resource indicators from different > angles but came to a similar conclusion. > > I wanted to confirm the following: > > The processing rules laid out > in draft-mcguinness-oauth-resource-token-resp mean a client that wants both > user identity (through OIDC & UserInfo access) and resource-indicated API > access would be forced into two separate authorization requests, one with > scope=openid (no resource) and one with resource? It prohibits the AS > returning an AT usable at the userinfo endpoint (no resource indicator) > with an issued RT simultaneously able to be used with either no resource > (to refresh userinfo access), or the individual resource to get an AT for > those. > Even if we were to hypothetically assign a resource indicator to the > userinfo endpoint that the AS could indicate, the processing rules still > prohibit the client to continue if it gets a resource indicator from the AS > that it didn't ask for (even though technically it did, just not based on > the resource it used but based on the use of the openid scope). > > I'm thinking we could simultaneously define OIDC's interaction with > Resource Indicators such that if resource indicators are used the AS falls > back to including all scope-requested claims in the ID Token and that the > claims parameter userinfo attribute becomes void or an error condition. > i.e. Resource Indicators == No UserInfo AT. > > S pozdravem, > *Filip Skokan* > > > On Fri, 16 Jan 2026 at 21:15, 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]
