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 [1] 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=<broker's RS> 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 <[email protected]>
Date: Friday, August 7, 2026 at 21:23
To: Pedram Hosseyni <[email protected]>; Tim Würtele
<[email protected]>; [email protected]
<[email protected]>; [email protected]
<[email protected]>
Cc: oauth <[email protected]>; Henrik KROLL
<[email protected]>; Grese HYSENI
<[email protected]>
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 [2].
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/
[3]
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
Links:
------
[1]
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-update-03#section-2.4
[2]
https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-update-03.html#name-shared-consent-in-brokered-
[3]
https://datatracker.ietf.org/doc/draft-zehavi-oauth-authz-req-del-chain/_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
