Flow · user-delegated
User-delegated agent calling APIs
A human authorizes an agent (as an OAuth client) to call an API. OAuth 2.1 + PKCE + audience-restricted JWT access tokens. This is still the production default.
Actors
User · Agent (OAuth client) · Authorization server · Resource server
Sequence
- 1
User→Agent
Asks the agent to do something that needs an API
- 2
Agent→Authorization server
Authorization Code + PKCE (PAR if the request is rich). scope + resource=API URI
Browser or native-app redirect, or CIBA if the user is on another device
- 3
User→Authorization server
Authenticates (OIDC) and consents
- 4
Authorization server→Agent
Issues access token (RFC 9068 JWT) and optional refresh token
Prefer DPoP or mTLS binding so a stolen token is not enough
- 5
Agent→Resource server
Authorization: Bearer (or DPoP) with aud = this API
Caveats
The API sees a client_id and a user sub. It does not automatically see a distinct 'which agent instance' identity unless you put one in claims or use AAuth/WIMSE alongside.
Why this hop looks this way
This is still the production default. MCP HTTP is this pattern with RFC 9728 discovery bolted on the front. FAPI 2.0 is this pattern with PAR and sender-constraint made mandatory.
If you need the tool to know which binary called, add SPIFFE/WIMSE on the same request in a different header. If you need the tool to know a portable agent identity without a client_id, that is AAuth — a different flow.