Delegated Agent OAuth Lab: Act for a User, No Password

Through delegated authorisation, not the user's credentials. The user signs in at the authorization server, approves specific permissions, and the agent receives a token limited to them. RFC 9700 says the password grant must not be used because it exposes the user's credentials to the client. The lab takes you through the choices that follow: flow, scope, lifetime, audience, binding, refresh, downstream calls and revocation.

RFC 8693 explains that with impersonation, the acting party is indistinguishable from the user in the token's context; with delegation, the actor keeps its own identity and it is understood that it acts for the user. The "act" claim expresses that delegation has occurred and names the actor. For agents, delegation keeps a record that software, not the person, did the thing.

So a token stolen from or sent to one service cannot be used at another. RFC 8707 lets the client name the resource it will use the token at, so the authorization server can restrict the audience, and RFC 9700 says each resource server must verify the token was meant for it. The MCP authorization draft requires the resource parameter, and the MCP security best practices forbid accepting tokens not issued for the server.

Only if the thief cannot also use the key. RFC 9449 sender-constrains tokens so that a token without the matching private key is rejected, in contrast to a bearer token that any holder can use. If the key sits in the same compromised sandbox, the benefit shrinks, so key placement matters.

Revoke the grant at the authorization server. RFC 7009 says a revocation request invalidates the token and, where applicable, other tokens based on the same authorization grant. Short-lived access tokens limit how long offline checks keep accepting an old one, and token introspection (RFC 7662) lets a resource server ask whether a token is currently active.

No. At our access date it is an Internet-Draft (draft-ietf-oauth-v2-1-17, dated 31 October 2026, expiring 4 May 2027). RFC 9700 is the published best current practice, and the lab cites the RFCs for requirements.

Only that it exists and what it covers: identity federation and assertions for people. It is background for the idea of one party vouching for an identity to another, and it does not set rules for AI agents, so the lab does not use it to justify agent design choices.

No. The organisation, assistant and services are invented. The lab quotes no real token, host or lifetime. Standards cited do not give token lifetimes in minutes, so the lab does not either.

Each of the 12 decisions scores 0 to 10 and the result is your share of the maximum, with a short band saying what it means. The debrief shows the source behind each rationale. Lines labelled PlayCISO practice are our reasoning, not a statement by a source.