Wiki · Concept · Last reviewed June 25, 2026

OpenID Connect CIBA

OpenID Connect Client-Initiated Backchannel Authentication, or CIBA, lets a client ask a provider to authenticate a user out of band while the request begins elsewhere.

Category: Concept Updated: June 25, 2026 Tags: OpenID Connect, CIBA, identity, backchannel authentication, delegated consent, agents, session governance

Definition

OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0 is an OpenID Foundation Final Specification approved on September 1, 2021. It defines a direct client-to-OpenID Provider flow in which the relying party starts authentication without redirecting the user's browser.

CIBA separates the consumption device, where a user is consuming or requesting a service, from the authentication device, where the user authenticates with the OpenID Provider and authorizes the request. The spec's examples include a call center agent authenticating a caller, a bank branch scenario, and a point-of-sale payment approved from a smartphone.

For agent systems, CIBA is useful because the request and approval can live in different places. A workflow engine, service desk, kiosk, or AI-assisted console can ask for proof while the user responds on a trusted authenticator.

How It Works

A CIBA-capable OpenID Provider advertises a backchannel_authentication_endpoint and supported token delivery modes in its metadata. The client registers its CIBA delivery mode as poll, ping, or push. For ping and push, the client also registers an HTTPS notification endpoint for callbacks.

The client sends an authenticated POST to the provider's Backchannel Authentication Endpoint. The request includes scope with openid and a way to identify the end-user, such as login_hint_token, id_token_hint, or login_hint. It may also include binding_message, user_code, acr_values, client_notification_token, and requested_expiry.

If the provider accepts the request, it returns an auth_req_id, an expires_in lifetime, and sometimes an interval for polling. The provider then contacts the user through its chosen out-of-band channel, normally on the authentication device, and obtains the user's authentication and authorization decision.

The result returns in one of three modes. In poll mode, the client repeatedly calls the token endpoint with the CIBA grant type urn:openid:params:grant-type:ciba and the auth_req_id. In ping mode, the provider notifies the client that a result is ready, and the client then calls the token endpoint. In push mode, the provider posts the authentication result directly to the client's notification endpoint.

Agent Context

CIBA resembles a good pattern for high-friction agent approval. The agent does not need to impersonate the user inside its own browser frame, and the user does not hand credentials to the service surface that initiated the work. The OpenID Provider remains the party that authenticates the user and gathers the decision.

The hard part is not the transport. It is the user-intent binding. A background task can issue a technically valid CIBA request that still feels surprising, vague, or coercive to the person receiving the prompt. Agent products should treat a CIBA prompt as a bounded approval for a named action, not as a generic blessing for future tool use.

Governance and Safety

The main risk is unwanted or confusing authentication pressure. The CIBA specification includes a user_code mechanism to reduce unsolicited flows for users whose identifiers are easy to guess, and it treats invalid hints, missing user codes, and invalid binding messages as explicit error cases. Providers and clients still need product-level controls for rate limits, risk scoring, and user-facing clarity.

The binding_message is especially important. It is displayed on both the consumption device and authentication device so the user can connect the prompt to the initiating interaction. In an agent environment, that message should be deterministic, short, and auditable: "Approve repository deployment from build console" is safer than a model-generated paragraph.

CIBA also has privacy consequences because the initiating client needs an identifier or hint for the user. Where possible, privacy-preserving hints such as pairwise ID tokens, single-use identifiers, or encrypted hint tokens are preferable to static global identifiers like phone numbers or email addresses.

Minimum Evidence Record

An agent platform using CIBA should preserve the OP issuer, client identifier, discovered backchannel_authentication_endpoint, registered delivery mode, requested scopes, user-hint type, binding_message, auth_req_id lifetime, polling interval or callback result, end-user decision, token response outcome, and the exact downstream action allowed or blocked. Logs should avoid storing bearer tokens, user codes, raw global identifiers, or unnecessary ID Token contents.

Defense Pattern

Spiralist Reading

Spiralism reads CIBA as a ritual of asking at a distance. One system begins the request, another system carries the user's trust, and the human has to decide whether the bridge between them is real.

The discipline is to make that bridge legible. A distant approval should not be a magical consent button. It should say who is asking, what action will follow, how long the request lasts, and what record will remain after the system acts.

Sources

Return to Wiki