Wiki · Concept · Last reviewed June 25, 2026

OAuth Identity Chaining

OAuth Identity Chaining preserves identity and authorization evidence when a client, service, or agent crosses from one OAuth trust domain into another.

Category: Concept Updated: June 25, 2026 Tags: AI agents, authorization, OAuth, identity chaining, audit trails

Definition

OAuth Identity Chaining is shorthand for the IETF Web Authorization Protocol Working Group draft titled OAuth Identity and Authorization Chaining Across Domains. The current datatracker record lists draft-ietf-oauth-identity-chaining-16, by Arndt Schwenkschuster, Pieter Kasselman, Kelley Burgin, Michael J. Jenkins, Brian Campbell, and Aaron Parecki, as an active Internet-Draft intended for Proposed Standard publication and in the RFC Editor queue.

The draft defines a way to preserve identity and authorization information when a request moves across OAuth trust domains. Instead of handing a broad token through every service, one domain can produce a JSON Web Token authorization grant, and another domain can validate that assertion before issuing an access token for its protected resource.

For AI agents, the useful idea is separation: original subject, acting client or workload, vouching authorization server, accepting authorization server, and final resource server should not collapse into one untraceable credential.

How It Works

The draft combines OAuth Token Exchange, standardized in RFC 8693, with the JWT authorization grant profile from RFC 7523. A client in trust domain A requests a JWT authorization grant from domain A's authorization server, then presents that grant as an assertion to domain B's authorization server, which can issue an access token for a resource in domain B.

RFC 8693 already gives OAuth deployments a token exchange request with fields such as subject_token, actor_token, resource, audience, and scope. RFC 7523 gives a way to use a JWT as an authorization grant at a token endpoint. The identity chaining draft profiles those pieces so a trust-domain boundary is crossed with explicit evidence rather than an opaque credential hop.

The draft also adds OAuth authorization server metadata for supported requested token types in identity chaining exchanges, so clients can discover whether a downstream domain supports the token type needed for the flow.

Agent Context

Agent systems make identity chaining important because one user request can become tool calls, service calls, queue jobs, and external API requests. A research agent may read from a document store, call a project tracker, run a build, and file an issue. A workplace assistant may cross between an employer identity provider, a SaaS tenant, and a vendor API. Each boundary can lose context if the design only forwards bearer tokens or service credentials.

Identity chaining is a counter-pattern to token smearing. The downstream service should not have to infer whether a request came from a human session, a scheduled workload, a delegated assistant, or a build pipeline. It should receive a token whose issuer, audience, resource, scope, subject, actor, and upstream assertion can be validated against policy.

This does not solve agent safety by itself. A valid cross-domain chain can still carry a bad instruction if a tool was prompt-injected, an approval was too broad, or a resource server accepts scopes without checking the action.

Governance and Safety

The governance value is that every cross-domain handoff becomes a policy checkpoint. Domain A decides whether the client may receive a JWT authorization grant. Domain B decides whether that assertion is trusted, whether the requested access token is appropriate, and whether the resource and scope fit the user, actor, client, and rule.

The governance risk is chain washing: a system can display a long chain of tokens and still hide the decision that mattered. Reviewers should ask whether each issuer is trusted, whether subject and actor semantics are preserved, whether the token is bound to the right audience or resource, whether replay is controlled, and whether logs connect the final side effect to the authorization event.

There is also a privacy risk. Chaining too little context creates accountability gaps; chaining too much context turns every downstream API into a surveillance sink. The design should carry the minimum claims needed for authorization and audit.

Defense Pattern

Source Discipline

Claims about OAuth Identity Chaining should cite the specific draft version, because the document is still an Internet-Draft until it becomes an RFC. A precise report should distinguish the base standards from the profile: RFC 8693 defines OAuth Token Exchange, RFC 7523 defines JWT bearer authorization grants and client authentication, and draft-ietf-oauth-identity-chaining-16 composes those pieces for cross-domain chaining.

Do not describe the pattern as single sign-on, token refresh, blanket federation, or proof that an agent had good intent. The source-backed claim is narrower: it is a protocol pattern for carrying and revalidating authorization evidence when a request crosses OAuth trust domains.

Spiralist Reading

Spiralism reads identity chaining as a discipline of remembering. A chain is useful only if it keeps the shape of responsibility visible as authority moves through systems.

The practical question is simple: when the downstream API accepted the call, could the organization still say who the request served, which actor carried it, which domain vouched for it, which domain accepted it, and what scope was actually granted?

Open Questions

Sources

Return to Wiki