OIDF · Final 2021 (errata revisions exist)
OpenID.CIBA
OpenID Connect Client-Initiated Backchannel Authentication Flow — Core 1.0 (OpenID.CIBA) is OIDF Final, Final 2021 (errata revisions exist). This is the existing standard for human-in-the-loop approval when the agent is unattended. If a vendor says 'async authorization for genAI', they are often wrapping CIBA.
At a glance
Actors
Animated sequence · CIBA
Backchannel grant, not a redirect
Client-Initiated Backchannel Authentication: the client has no browser. It POSTs a backchannel authentication request, gets auth_req_id, and waits. The user is notified, authenticates, and consents on the authentication device. Token delivery is poll by default; ping and push are alternatives named in Why — the wait is not skipped.
Now · 1/9· Discover· OpenID CIBAYou are here
Client (agent)→OpenID provider·POSTs a backchannel authentication request: login_hint, scope, binding_message
The client POSTs the backchannel authentication endpoint with a hint for which user, the scope, and a binding_message the user will see.
Why There is no front-channel redirect. The client is unattended. This is not the authorization endpoint used by code+PKCE.
The unattended desk phones the notary instead of sending the owner a browser link.
Solid = from the spec
CIBA authenticates and consents a grant. It does not replace resource-server policy. XAA is a different control for pre-approved app connections. Poll is the default delivery shown; ping and push change who speaks first, not whether the user must finish.
Sequence above; this list is the same hops for reading and search. Each row is one message.
Client (agent)→OpenID providerOpenID CIBAPOSTs a backchannel authentication request: login_hint, scope, binding_message
OpenID provider→Client (agent)OpenID CIBAReturns auth_req_id (and expires_in, interval)
OpenID provider→User (auth device)OpenID CIBANotifies the authentication device with the same binding_message
User (auth device)→OpenID providerOpenID CIBAAuthenticates on the authentication device
User (auth device)→OpenID providerOpenID CIBAConsents — approves or denies — on the authentication device
Client (agent)→OpenID providerOpenID CIBAPolls the token endpoint: grant_type CIBA + auth_req_id — authorization_pending
Client (agent)→OpenID providerOpenID CIBAPolls again after the wait — the user has now consented
OpenID provider→Client (agent)OpenID CIBADelivers the tokens for that approved action
Client (agent)→Resource serverRFC 6750Calls the RS with the access token — never with auth_req_id
01
The client has an identifier for the user but the user is not in a browser in front of that client — they will authenticate and consent on another device. This is the existing standard for human-in-the-loop approval when the agent is unattended. If a vendor says 'async authorization for genAI', they are often wrapping CIBA.
Use CIBA for 'agent wants to do X while the user is away'; XAA for 'IT already authorized this app connection'; AAuth missions for natural-language, multi-resource intent; RFC 9470 when the RS demands stronger auth on an existing grant.
02
Consumption device (the agent) never sees the user's password. Authentication device (phone) is where the user actually authenticates. The OP binds them with auth_req_id and an optional binding_message so the user knows which action they are approving. Polling the token endpoint must be authenticated as the client.
03
Client POSTs to the backchannel authorization endpoint with a login hint, scope, optional binding_message and requested_expiry. OP returns auth_req_id. User is notified out of band. Client polls (or uses ping/push) the token endpoint with grant_type=urn:openid:params:grant-type:ciba until approved, denied, or expired. FAPI 2.0 Security Profile supports CIBA and notes that authorization-code and CIBA have been through detailed security analysis.
04
Flow 1
Agent POSTs backchannel authorize: login_hint, scope, binding_message describing the tool call, client auth.
OP returns auth_req_id (and expires_in / interval).
User sees a push with the binding message and approves or denies.
Agent polls token endpoint with grant_type CIBA + auth_req_id (slow_down / pending / denied / expired).
On success, ID Token + access token as in OIDC. Use the access token at the API, not the ID Token.
05
Authentication and consent, decoupled from the consumption device. The tokens that result are still OAuth/OIDC tokens (authorization + identity at the client).
06
CIBA is an OIDC authentication flow producing the same token types.
RS can demand CIBA-shaped re-auth via 9470 challenges.
Supported high-security profile for CIBA deployments.
Missions/interaction relay are the AAuth HITL analogue; CIBA is the OIDC one.
Orthogonal: preapproved connections vs per-action approval.
07
The user approves 'something' on the phone. For agent tool calls, the message must name the action.
auth_req_id without client authentication is stealable. Confidential client auth (or FAPI methods) on the token poll.
CIBA authenticates/consents a grant; it does not replace RS policy or audience checks.
08
OIDF Final 2021 (errata revisions exist). Stable. https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html
FAPI 2.0 Security Profile supports CIBA and notes that authorization-code and CIBA have been through detailed security analysis. Use CIBA for 'agent wants to do X while the user is away'; use XAA for 'IT already authorized this app connection'; use AAuth missions for natural-language, multi-resource intent.