Headless / async user-delegated

The agent runs without a browser on its own device. A human still has to approve, but on another device. CIBA is the OpenID answer; RFC 9470 steps up an existing grant; AAuth interaction relay is the person-server-shaped alternative.

When you see it

A nightly research agent that must confirm before sending mail, a factory-floor bot whose operator has a phone, a CLI agent started over SSH, any 'approve this tool on your phone' prompt. If there is no human at all, that is unattended batch — a different row.

Actors and trust

Agent (no browser)Agent instance
Confidential client at the OpenID provider, or an AAuth agent with a person server.
User on another deviceUser
Approves a binding message (CIBA) or completes an interaction URL (AAuth PS / RFC 9470).
OpenID provider or person serverOther
Authenticates the person and mints the grant the agent will present.
Resource serverResource
Still enforces audience and policy. CIBA is not a replacement for RS checks.

Topology

Headless agentOpenID provider / person serverUser (other device)API / tool

Headless agent→ CIBA backchannel authorize, or AAuth 401 + interaction →OpenID provider / person server
OpenID provider / person server→ Push / binding message / interaction URL →User (other device)
User (other device)→ Approve or deny →OpenID provider / person server
OpenID provider / person server→ Access token or aa-auth+jwt →Headless agent
Headless agent→ Call with the freshly approved grant →API / tool

Agent has no browser. The human approves on another device; the grant comes back on the back channel (CIBA) or via the person server (AAuth).

Primary

CIBA
OpenID Connect Core
Step-up authentication
RFC 9470 — existing grant is too weak or stale.

Optional

AAuthdraft / churn
Person-server interaction relay: the AAuth-shaped alternative when there is no OAuth AS in the hop.
FAPI 2.0
CIBA is commonly paired with FAPI-class APIs.
AIMS (agent auth BCP)draft / churn
Individual draft — expect churn.

Do not use

OAuth 2.1
Authorization-code redirect is the wrong grant when the agent has no browser. Use CIBA (or AAuth interaction), not a fake redirect.
Headless browser against the authorize endpoint
That is not a grant. It is scraping a login page.
Resource Owner Password Credentials
Never collect the user's password in the agent.

Why these, and not those

Authorization code needs a redirect user-agent the agent does not have. CIBA starts the grant on the back channel and pushes the human on an authentication device. RFC 9470 is for the case you already have a grant that is too weak or too stale for this tool. AAuth's person-server interaction relay is the same human-in-the-loop idea without an OAuth AS in the agent–resource hop: the PS parks the request, the person approves, the agent retries with an auth token. Do not automate a headless browser against an authorize endpoint, and do not stuff a user password into the agent.

Related flows

Sequence diagrams, not this topology cut. All flows