Ack, I have opened https://github.com/mcguinness/draft-mcguinness-oauth-resource-token-resp/issues/3 to discuss further and align on a solution.
Thanks, Karl On Sun, Mar 1, 2026 at 7:31 AM Filip Skokan <[email protected]> wrote: > To clarify; A single issued AT for both/simultaneous is not what I'm > describing. > > - Filip > > 1. 3. 2026 v 15:59, Karl McGuinness <[email protected]>: > > > 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]
