Dear OAuth Working Group, I am writing to share a potential security finding related to theact(actor) claim in RFC 8693 (OAuth 2.0 Token Exchange) that I believe warrants consideration, particularly as the working group advances specifications for agentic OAuth flows (draft-oauth-ai-agents-on-behalf-of-user, transaction tokens, etc.).
Summary
I may have identified a structural weakness I call"delegation chain splicing"--
a technique by which a compromised intermediary can present
mismatchedsubject_tokenandactor_tokeninputs to the token exchange endpoint from
different delegation contexts. The STS validates each token independently (per
Section2.1-2.2), finds both valid, and issues a new properly-signed token
asserting a delegation chain that never actually occurred.
The root cause is that RFC 8693 does not require cross-validation between
thesubject_tokenandactor_token-- specifically, there is no mechanism to verify
they belong to the same delegation flow, authorization session, or trust
context.
Why This Matters Now
While RFC 8693 Section4.1 correctly states that nestedactclaims are
"informational only" for access control, the proliferation of agentic AI
systems creates deployment contexts where delegation chain history is
increasingly relied upon for:
- Audit trail integrity (required under HIPAA, SOC 2)
- Policy enforcement ("was there a human in the loop?", "how many delegation
hops?")
- Anomaly detection and trust scoring
- Compliance reporting
Themay_actclaim (Section4.4) provides partial mitigation by restricting which
actors may exchange a token, but it validates the actor'sidentity, not that the
actor credential wasacquired within the same delegation context. It is also
optional -- there is no normative requirement that subject tokens
carrymay_actor that the STS enforce it.
The draft-oauth-ai-agents-on-behalf-of-user specification takes a step in the
right direction by binding the authorization code to the actor (Section5.5),
but this protects only the initial user-to-agent delegation. Subsequent
agent-to-agent token exchanges -- where chain splicing occurs -- remain
unaddressed.
Real-World Precedent
CVE-2025-55241 (Microsoft Entra ID, patched July 2025) demonstrated that actor
token validation failures have Critical-severity impact in production. That
vulnerability involved unsigned actor tokens enabling cross-tenant
impersonation -- a closely related class ofactclaim misuse.
Suggested Mitigations for Consideration
-
Cross-validation requirement:The STS should verify that theactor_tokensubject
matches an authorized next-actor declared in
thesubject_token(strengtheningmay_actfrom optional to normative).
-
aud/subchaining withinactclaims:Require that nestedactclaims include fields
forming a verifiable chain -- similar to what OIDC-A 1.0 specifies
fordelegation_chain, where theaudof step N must match thesubof step N+1.
-
Per-step delegation receipts:Each STS that performs a token exchange includes a
signed attestation of the delegation step, providing independently-verifiable
provenance.
Full Write-Up
A detailed write-up with three concrete scenarios (healthcare, multi-tenant
SaaS, CI/CD), mechanism description, conditions for exploitability, anticipated
counterarguments, and mitigations is attached.
This finding was independently validated by multiple analyses working from the
RFC 8693 specification text alone.
I welcome feedback and am happy to discuss further.
Best regards,
Chiradeep Chhaya
---------------------------------------------------------------
Note: This finding was identified during security research with the assistance
of AI tools (Claude by Anthropic and Gemini by Google), which were used for
collaborative analysis, adversarial review, and independent validation. I am
sharing it with the working group for independent validation and consideration
in ongoing specification work.
chain-splicing-writeup.pdf
Description: Adobe PDF document
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
