Yaron, Kaixuan, Yaron's operator experience is the most useful thing in this thread, and I want to build on it rather than restate it. An A to B to C topology where B is a broker, extending to A to B to C to D where subsidiaries run their own brokers, is the deployment reality, and both proposed countermeasures fail against it for the reasons Kaixuan gives: registering downstream clients at upstream authorization servers defeats the purpose of brokering, and broker-rendered consent screens add friction without giving the upstream AS anything it can act on.
The framing I would offer is that the upstream AS does not need the downstream client registered. It needs the delegation chain to be verifiable and the terminal authority to be a subset of what each hop actually held. Concretely, that means three properties rather than a registration requirement: 1. Each hop contributes a signed link naming the party it delegated to, so the chain is reconstructable by the terminal AS without prior knowledge of intermediate clients. 2. Authority at each hop is expressed as bounds, not parameters, so the terminal AS performs a subset check rather than trusting a broker's assertion of scope. We implement this on the resolver side and refuse on violation. 3. Reliance on the chain is emitted as an auditable event. With independent upstream authorization servers, each can honestly rely once, and a counter held by any single broker cannot distinguish that from replay. That is close in spirit to the delegation-chaining idea Kaixuan credits, and it complements token-exchange-style delegation at issuance time rather than competing with it. If it would help, I can write up the tenant-isolation variant we run, where each upstream is a separate trust domain with its own policy, as a concrete counterexample to the "register downstream clients" approach. On Sunday, August 23, 2026 at 9:34 PM UTC, [email protected] wrote: Dear Kaixuan, Thank you for the detailed response, I appreciate the feedback and discussion. My comments on the countermeasures offered come from 6 years of experience running an OAuth broker linking 10+ client applications to 10 upstream (CIAM) authorization servers, each run by a subsidiary (bank) for its customers. So an A --> B --> C relationship where B is our OAuth broker. Some subsidiaries also use their own OAuth broker, for example to broker onward across multiple upstream AS, according to customer segments, making it an A --> B --> C --> D relationship, with B & C acting as brokers. In our setup the terminal upstream authorization server needs to know the terminal downstream client, as an input to its authorization decisions: * Some users may use specific downstream client but cannot use others. * When a user may access multiple downstream clients, their resource permissions may differ. We solved this challenge in our setup using internal contracts whereby the broker is trusted upstream and shares information about its client. Registering every downstream client at every upstream authorization server would, in our case, mean 10x work. There might be larger federation networks where the impact is even more significant. That’s what I meant by defeating the purpose, having to maintain the relationship which today brokering handles. Furthermore, the proposed countermeasure of downstream clients providing OAuth brokers with their client credentials so brokers can act in their name, may introduce new security risks such as broker confused deputy, credential and configuration sprawl etc. My draft’s intention was to keep benefits of simpler architecture due to the separation of roles when using OAuth brokering, while providing upstream authorization servers verifiable attestation of the request’s delegation chain, to enable them to make their decisions. Note: good call on the draft’s resource parameter. It is indeed a reference to the original resource parameter, and not necessarily the OAuth request’s actual resource parameter. That said, I cannot see a valid reason why a broker should inform an upstream authorization server of a different resource value than the one it received, if that value is going to be used as the token’s aud value. Happy to keep the discussion going and review the new draft. Regards, Yaron ZEHAVI Classification: GENERAL From: LUO Kaixuan Sent: Sunday, August 23, 2026 1:11 PM To: Yaron ZEHAVI Cc: oauth ; Henrik KROLL ; Grese HYSENI ; Pedram Hosseyni ; Tim Würtele ; [email protected]; Louis Jannett Subject: Re: [OAUTH-WG] Shared Consent in Brokered OAuth You don't often get email from [email protected]. Learn why this is important This message is from an external sender - be cautious, particularly with links and attachments. Hi Yaron, Thanks for the email and the draft. The idea of delegation chaining during an interactive OAuth flow is very interesting, and it complements the token-exchange-style delegation work done at token-issuance time. I do think that the solution you proposed helps solve the shared consent security issue. Thank you! Regarding your concerns about our countermeasures: But the proposed solutions in the draft fall also short in my view: * Registering downstream clients at upstream authorization servers defeats the purpose of brokered OAuth flows. * Presenting users with consent screens from brokers adds friction and does not empower upstream AS to take informed decisions. I understand these concerns. I think the difference here is that whether the broker and upstream AS should be aware of the delegation chain at all. In the patterns we observed, the existence of the downstream clients is transparent to the upstream AS. The broker can also act as a "textbook" RFC6749-compliant AS and OAuth client toward the downstream client and upstream AS, respectively. Our proposed solutions are a best-effort approach given the constraints of real-world broker implementations. Registering downstream clients at upstream authorization servers defeats the purpose of brokered OAuth flows. On the first point, I'd push back a little. Despite the additional efforts of client registration, this approach still eases the development burden on downstream clients, and IMO does not defeat the purpose of brokered OAuth flow: · Brokers usually have pre-built integrations with many common IdPs/SaaS apps, so the downstream client only needs to talk to the broker to reach those upstream services. · Some brokers act more like "token vaults", helping downstream clients manage the full lifecycle of tokens (fetching, storage, refresh, etc.) and/or API calls toward the upstream AS/RS. Pretty much resembling the Backend-for-Frontend (BFF) or Token-mediating backend (TMB) patterns in OAuth. I think what we can add in the security BCP update draft, is to clarify that the two countermeasures apply when the upstream AS uses the client_id to make consent decisions, and acknowledge that there could be alternative ways to distinguish downstream clients (and the delegation chain), such as leveraging RAR authorization_details. Based on the feedback from Vienna, we will probably also move the brokered consent description in section 2.4 into a different document, which would allow for a more complete enumeration of brokers' threats. My two cents. (Cc Louis Jannett, who contributed to the section) Best, Kaixuan Luo PhD Candidate The Chinese University of Hong Kong ===== P.S. It might make sense to mention that the resource member in the authorization detail object is only a reference for the delegation chain, and does not replace the top-level resource parameter [RFC8707] in signaling the intended token audience: Your draft assumes that the protected resource named in the delegation chain is always the RS associated with the upstream AS (e.g., https://api-domain-1.example.com). https://datatracker.ietf.org/doc/html/draft-zehavi-oauth-authz-req-del-chain-00#appendix-A.1 However, a broker, when acting as an AS, may issue its own access_token with aud= to the downstream client. For example: * Brokered OAuth: the broker uses this token to lookup the original access_token issued to it by the upstream AS, and then forwards that original token to the "real" RS for API calls. * Brokered SSO: the broker uses this token to fulfill requests to its own /userinfo endpoint. So the resource member in the authorization_details object does not indicate the expected audience(s) of the tokens issued in brokered OAuth flows. Is that a correct reading? From: Yaron ZEHAVI > Date: Friday, August 7, 2026 at 21:23 To: Pedram Hosseyni >; Tim Würtele >; [email protected] >; [email protected] > Cc: oauth >; Henrik KROLL >; Grese HYSENI > Subject: [OAUTH-WG] Shared Consent in Brokered OAuth Dears, Thank you for considering the risks these flows present, as part of your "Updates to OAuth 2.0 Security Best Current Practice" draft. I have special interest in this topic since we operate a platform offering brokered redirect-based OAuth. In our case we solved it with internal contracts, providing an app_id inside login_hint, telling the upstream AS who the downstream client is. However, our solution does not offer internet-scale interoperability. But the proposed solutions in the draft fall also short in my view: * Registering downstream clients at upstream authorization servers defeats the purpose of brokered OAuth flows. * Presenting users with consent screens from brokers adds friction and does not empower upstream AS to take informed decisions. I believe an improved pattern could be an OAuth Authorization Request Delegation Chain: A request-time RAR object that conveys clear information about downstream clients and brokers, in a verifiable and tamper-resistant way: https://datatracker.ietf.org/doc/draft-zehavi-oauth-authz-req-del-chain/ The proposed solution doesn't include any new endpoints, AS metadata, grant types, error codes, token formats etc. Only an informative recommended RAR type with prescribed creation and validation processing rules. I'm aware of parallel work on the topic of actor delegation, relevant among others in AI and OBO use-case. As my proposal is aimed at request time, I believe it complements actor delegation work and does not compete with it. I welcome WG feedback on the proposal, especially: * Can it help solve the identified security issue? * Are further alignment and layering required with regards to actor delegation prior art? Regards, Yaron ZEHAVI This message and any attachment ("the Message") are confidential. If you have received the Message in error, please notify the sender immediately and delete the Message from your system, any use of the Message is forbidden. Correspondence via e-mail is primarily for information purposes. RBI neither makes nor accepts legally binding statements via e-mail unless explicitly agreed otherwise. Information pursuant to § 14 Austrian Companies Code: Raiffeisen Bank International AG; Registered Office: Am Stadtpark 9, 1030 Vienna, Austria; Company Register Number: FN 122119m at the Commercial Court of Vienna (Handelsgericht Wien). Classification: GENERAL This message and any attachment ("the Message") are confidential. If you have received the Message in error, please notify the sender immediately and delete the Message from your system, any use of the Message is forbidden. Correspondence via e-mail is primarily for information purposes. RBI neither makes nor accepts legally binding statements via e-mail unless explicitly agreed otherwise. Information pursuant to § 14 Austrian Companies Code: Raiffeisen Bank International AG; Registered Office: Am Stadtpark 9, 1030 Vienna, Austria; Company Register Number: FN 122119m at the Commercial Court of Vienna (Handelsgericht Wien).
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
