OIDF · Final 2021 (errata revisions exist)
OpenID.CIBA
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
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.