Client-Initiated Backchannel Authentication (CIBA)

Client-Initiated Backchannel Authentication (CIBA) is an OpenID Connect flow in which the application asks the authorization server to authenticate a user server-to-server, and the user approves on a separate device they registered earlier rather than through a browser redirect. It decouples the channel where something is being done from the channel where a person proves who they are, which makes authentication possible where no login screen can be presented at all: a service desk verifying a caller, a kiosk or point-of-sale transaction, a command-line tool, or an AI agent with no browser to redirect. CIBA is a final OpenID Connect specification with years of production use where a payment has to be confirmed out-of-band by the account holder, and it is now the mechanism organizations reach for when a human has to authorize an action that an autonomous process proposed.

What Changes When the Redirect Disappears

In redirect-based flows the browser is the trust channel: the authorization server recognizes the session, prompts whoever is there, and returns the outcome the same way. CIBA removes that channel, and three things have to take its place.

The client names the user up front with a hint — an identifier, a previously issued ID token, or a signed hint token — so it must already know whom it is asking about, and the authorization server resolves that hint to an account and to the authentication device bound to it. The client must also be a confidential client that authenticates on every request; CIBA has no public clients, because the ability to start an authentication ceremony for an arbitrary user is itself a privilege. Finally, the client polls for the result, or is notified, or has the tokens pushed to an endpoint it registered. Because two channels are now in play, a short human-readable binding message is carried through both, so the person approving on their phone can see that the request belongs to the transaction actually in front of them.

That inverts the usual direction of consent. The application initiates authentication on behalf of a user who is not present in it, and the user's device receives a prompt they did not trigger.

Controlling Who May Initiate

An unsolicited approval prompt is exactly the shape of a push-fatigue attack, so the interesting security properties of a CIBA deployment are on the initiation side rather than in the flow itself. Which clients may start a request should be an explicitly granted capability rather than a side effect of being registered, and it should be rate-limited per user, since a client that can supply hints can otherwise probe which accounts exist and how they respond. The specification's optional user code — a secret the user gives the client to demonstrate that the request is wanted — is the built-in answer where the user is present in the initiating channel, as at a service desk or a terminal.

What the approval screen shows matters as much as who triggered it. A bare accept-or-deny prompt trains people to accept; the binding message and the concrete parameters of the pending action are what make an unexpected prompt recognizable as one. Approval through a phishing-resistant authenticator such as FIDO2 Passkeys binds the decision to a device key rather than to a tap, which matters because CIBA moves the entire authentication event onto a channel the requesting application cannot observe.

Out-of-Band Approval for Agents

The human-in-the-loop checkpoint described by the AuthZEN Access Request and Approval Profile needs something to actually deliver the approval, and CIBA is the shipped mechanism for it. The IETF draft on AI agent authentication and authorization names it in its human-in-the-loop section for precisely this reason: the approval reaches the user without any credential reaching the agent.

The distinction it enforces is worth carrying into any agent design. A confirmation dialogue inside an agent framework is not authorization — it is a UI event, one that a compromised agent can fabricate and that an injected instruction can talk a user through. Authorization means the authorization server issued something narrower because it observed a human decision. CIBA converts the approval into that event, with the approving user's authentication recorded where the tokens are minted rather than asserted afterwards by the party that wanted the access.

Two limits shape how it is used. CIBA is initiated at the start of a request, so an agent that needs approval partway through a long-running task has to raise a new authorization request rather than interrupt the one it is in; the agent authentication draft flags out-of-band interaction at arbitrary execution stages as work still to be specified. And a checkpoint is only as meaningful as the request behind it — approving "everything this agent normally does" is ceremony, not control. Actions worth interrupting should be requested as narrowly as the surrounding token exchange and chaining machinery allows, which for Model Context Protocol deployments means per tool rather than per server.

Choosing Between the Approval Mechanisms

Three finalized mechanisms suspend a request until a person acts, and they are not interchangeable. The OAuth 2.0 Step Up Authentication Challenge applies when the right user is already in the channel but their authentication is too weak or too old, and the remedy stays in-band. The Device Authorization Grant applies when a browserless device needs a login and the user is standing at it, carrying a displayed code to a second device of their own choosing. CIBA applies when the user is somewhere else entirely and may not be the party that started the request at all. The question that selects between them is therefore who is present, in which channel, and whether the pending action needs stronger authentication of the same person or a decision from a different one.

Adoption Considerations

Whether CIBA is available at all is the first question, because the flow is an optional part of an authorization server rather than something every OpenID Connect deployment exposes. Several authorization servers implement it and its backchannel endpoints; some widely deployed workforce identity providers do not, and there a human-in-the-loop checkpoint has to be assembled from whatever push approval the platform offers — which returns the design to asserting that a person agreed rather than recording that the authorization server observed it.

CIBA is also a protocol answer that depends on a lifecycle prerequisite: every account that can be authenticated this way needs a registered authentication device, and the enrolment and recovery paths for that device become the weakest link in the flow — which puts identity proofing and service desk procedure inside the threat model rather than beside it. Operationally, the flow runs at human speed, so timeouts, expiry, and what the application does when nobody answers are product decisions and not protocol defaults. Polling is the simplest delivery mode to operate; the notification modes require the authorization server to reach a client endpoint, and in push mode that endpoint receives the tokens themselves and has to be protected accordingly.

The audit record deserves deliberate design, because the whole point of the flow is that a second principal was involved. A log entry stating that a token was issued does not say that a human agreed to something; the approver's identity, the initiating client or agent, and the binding message that was displayed are what make the approval reconstructable later. Where assurance requirements are high, the FAPI CIBA profile tightens client authentication and request signing and has a certification programme behind it, although the profile itself is an implementer's draft rather than final.

Summary

CIBA is mature technology being adopted for a new reason. As a general-purpose login flow it is the wrong default — the redirect-based flows are simpler and better understood — but as the way to obtain an authenticated human decision from someone who is not in the channel, it currently has no finalized competitor. Deployments should treat three things as the security-relevant surface: who may initiate a request, what the approving device displays before it accepts, and how narrowly the request behind the approval is scoped. Organizations building AI agent workflows that pause for human approval should reach for CIBA rather than build a confirmation step inside the agent, because only the former produces an authorization event that survives the agent being wrong.