Interactive delegated
Interactive user-delegated agent
/patterns/interactive-user-delegated
A human is in a product UI. The agent calls APIs as that user. This is still the production default: OAuth 2.1 authorization code + PKCE, OIDC for the user, audience-restricted access tokens.
When you see it
Chat UIs that connect Gmail or Jira, Copilot-in-the-IDE with a browser login, any SaaS 'enable the assistant' button that pops an authorization screen. The agent is an OAuth client; the human is the resource owner.
Actors and trust
User / resource ownerUser
Authenticates to the authorization server (OIDC). Consents to what this client may do.
Agent (OAuth client)Agent instance
Identified by client_id at this AS (or a CIMD URL). Not a portable agent identity. Public or confidential depending on the host.
Authorization serverOther
Issues the access token the API will accept. Often the company IdP or the API vendor's AS.
Resource server / APIResource
Trusts tokens from that AS, audience-restricted to itself (RFC 8707 / RFC 9068). Does not automatically learn which agent instance called.
Topology
- User (browser)→ Asks the product to call an API →Agent (OAuth client)
- Agent (OAuth client)→ Auth code + PKCE (PAR if the request is rich) →Authorization server
- User (browser)→ Authenticates (OIDC) and consents →Authorization server
- Authorization server→ Access token (and optional refresh) →Agent (OAuth client)
- Agent (OAuth client)→ Authorization: Bearer or DPoP; aud = this API →API / tool
Primary
- OAuth 2.1
- PKCE
- OpenID Connect Core
- Protected Resource Metadata
RFC 9728 — discover the AS from the API.
- Resource Indicators
RFC 8707 — aud = this API.
- OAuth Security BCP
RFC 9700 — the safety floor on top of RFC 6749.
Optional
- PAR
When the authorize request is large or must not hit the front channel.
- RAR
When scopes are too coarse for the tool call.
- DPoP
Sender-constrain without mTLS.
- mTLS sender-constrained tokens
Sender-constrain when the client already has a cert.
- JWT access tokens
- Client ID Metadata Documents
If the agent is not pre-registered at this AS.
- FAPI 2.0
High-risk APIs: PAR + PKCE + sender-constraint required.
- OAuth agent grantsdraft / churn
Individual draft: profile OAuth for agent clients without new endpoints.
- AIMS (agent auth BCP)draft / churn
Individual draft: BCP map, not a wire protocol.
Do not use
- AAuthdraft / churn
Not for this hop unless you are replacing the AS. AAuth p2p has no auth-code redirect.
- Resource Owner Password Credentials
Removed from OAuth 2.1; forbidden by RFC 9700.
- Bearer tokens
Bearer tokens exist, but unconstrained Bearer as the whole design is the 2012 default RFC 9700 is walking away from.
Why these, and not those
You have a browser and a human. Authorization code + PKCE is the OAuth 2.1 default; OIDC authenticates the user to the client; RFC 9728 tells the client which AS protects the API; RFC 8707 keeps the token from being replayed at a different API; RFC 9700 is the safety floor (no implicit, no password grant, exact redirects). PAR and RAR are for fat or fine-grained requests, not a different grant. DPoP or mTLS so a stolen access token is not enough. AAuth identity-based p2p is the wrong tool unless you are deliberately replacing the AS — it has no authorization-code redirect and no Bearer access token.
Related flows
Sequence diagrams, not this topology cut. All flows