Table of Contents
Client-Initiated Backchannel Authentication (CIBA) is a decoupled authentication flow that separates the device where a client application runs (the “consumption device) from the device where the user authenticates (the “authentication device”). Unlike typical OAuth and OpenID Connect (OIDC) flows that use browser redirects, CIBA enables direct backchannel communication between the client and the OpenID provider.
Using CIBA, authentication can be initiated by the client application without requiring user interaction on that same device. The authentication happens out of band on a separate device, usually the user’s smartphone. Decoupling the two devices creates flexible yet secure authentication options, particularly for out-of-band scenarios.
Main points
What is CIBA? A decoupled flow that allows clients (e.g., apps) to initiate authentication without user interaction on the consumption device (where the client application runs).
How CIBA works: The client sends a request to the OIDC provider, which then authenticates the user on their separate device.
Security and benefits: A financial-grade protocol, CIBA offers phishing-resistant defense against fraud while eliminating the need to share sensitive information.
In this article, we’ll discuss the core elements that make up CIBA, demonstrate a CIBA flow, examine some real-world use cases, and take a peek at CIBA’s future in authenticating agentic AI.
Core components of CIBA
Client-Initiated Backchannel Authentication consists of many key elements that work together to create a decoupled authentication flow. Because CIBA relies on the OIDC and OAuth 2.0 protocols, many of its constituent components require a working understanding of those frameworks.
Dive into beginner-friendly introductions to OpenID Connect and OAuth.
CIBA concepts from OIDC and OAuth
Tokens: ID tokens, access tokens, and (optionally) refresh tokens are an essential part of the CIBA flow.
Grant type: CIBA uses an extension grant type, which essentially adds support for non-standard scenarios.
Scopes: Mechanism that limits an application’s access to resources and actions. Apps must request at least one scope, and the access token it receives is limited to the scopes granted.
CIBA endpoints
Backchannel authentication endpoint: The server endpoint where clients directly send authentication requests. This is where CIBA begins, without any browser redirection.
Client notification endpoint: An endpoint the client registers for receiving notifications from the OIDC provider when using the ping or push delivery modes.
Three token delivery modes
CIBA implementations can use one of the following token delivery modes at a time:
Poll mode: The client checks the token endpoint at predefined intervals to see if authentication is complete.
Ping mode: The OIDC provider notifies the client when authentication is ready, then the client retrieves the tokens.
Push mode: The OIDC provider delivers tokens directly to the client notification endpoint.
User identifiers
CIBA requires the client to provide one (and only one) of three possible identifiers:
login_hint: A simple identifier like email, username, phone number, etc.login_hint_token: A deployment-specific token format with custom user identifiers.id_token_hint: A previously issued ID token from the OIDC provider.
Binding message
A binding message is an optional, human-readable identifier displayed on both devices to help users verify they’re approving the correct request. The message typically includes a unique code that differentiates this request from any others. This helps combat prompt or MFA bombing, which attempts to confuse users with illegitimate authentication requests.
Consumption device & authentication device
The separate devices involved in a CIBA flow are known as the consumption device and the authentication device. Because CIBA decouples authentication from the device requesting authentication (the consumption device), the authentication device is needed to confirm the user’s identity.
CIBA flow example: authenticating with a call center agent
Let’s say you’ve called your bank about a transaction and need to verify your identity with a call center agent. CIBA makes this process much more convenient.
Here’s how CIBA enables seamless authentication using the poll token delivery mode (one of the three possible modes that would be selected during implementation):
Initiation: You contact your bank about a recent transaction. Before continuing by discussing sensitive information, the call center (consumption device) initiates a CIBA flow by sending an authentication request to the OIDC provider with (for example) your phone number as the login hint and a binding message “Call Center Login.”
Acknowledgement: The OIDC provider immediately returns a unique transaction ID to the call center, acknowledging the request.
User notification: The OIDC provider sends a notification to your smartphone through a previously registered banking app.
Prompt: Your mobile app (optionally) displays a prompt showing the same binding message “Call Center Login”
Authentication: You authenticate on your smartphone using biometrics or a PIN, and approve the login request.
Approval: Your mobile app sends the approval code to the OIDC provider.
Token retrieval: The call center periodically polls the token endpoint using the transaction ID.
Token delivery: When authentication is complete, the OIDC provider returns the tokens to the call center system in response to a poll request.
Verification complete: The call can proceed now that the caller has been authenticated.
This example illustrates poll mode, which is one of the three possible token delivery options in CIBA. The client and provider would select a single mode during implementation (poll, ping, or push) based on their specific requirements.
CIBA in real-world scenarios
CIBA offers significant advantages over traditional authentication modalities, especially in circumstances where user interaction is hampered by device limitations or out-of-band environments. Below are several examples of common CIBA implementations, noting how the specification offers better security and user experience:
Point of Sale (PoS) authentication
Automation in retail is increasingly popular as companies look for ways to reduce staffing overhead. Self-service terminals capable of initiating CIBA flows allow customers to pick up items from a brick-and-mortar store without having to flag down an associate.
Picture a scenario where you’ve purchased an item with the “pick up in store” option. You arrive at the location, walk up to a PoS terminal, and enter a code or select your pickup from a list. Within moments, your smartphone receives a push notification to authenticate at the terminal, which then unlocks the container holding your purchase.
Call center authentication
Imagine you’ve called customer support at your bank, and you need to prove your identity to the representative on the line. Security questions are notoriously fallible (and risky to communicate to a potential fraudster), and “sending a one-time code” for the recipient to speak aloud is a notorious phishing technique. Users are reasonably reluctant to share personal information over the phone, but CIBA can solve this anxiety.
The call center agent can authenticate you by sending a push notification to your mobile banking app, where they verify your identity with on-device biometrics. This approach provides both a stronger security posture and better privacy because sensitive information remains unsaid.
Face-to-face authentication
Whether it’s a bank teller, pharmacy tech, or a doctor’s office that needs additional verification, CIBA turns in-person authentication into a quick and painless process. A passport or driver’s license is often seen as the ultimate form of ID, but documents can be copied or stolen, and employees can be socially engineered. Not so with CIBA.
CIBA’s decoupled authentication goes straight to the user’s most reliable possession factor: their smartphone. Because a customer’s identity is already confirmed on their device, and the process can leverage inherence factors like fingerprints and facial recognition, CIBA constitutes a highly reliable, financial-grade protocol for verification.
AI agent authentication
When an AI agent needs to make a transaction or access sensitive data on behalf of a user, CIBA provides the authentication backdrop necessary for “human-in-the-loop” approval without disrupting the agent’s workflow. Because authentication can take place asynchronously, the agent can carry on with other tasks rather than waiting for the user.
CIBA for agentic AI
As AI agents become more capable of acting on behalf of their users, traditional authentication modalities pose significant security risks. CIBA strikes a balance between security and user experience, offering a compelling “human-in-the-loop” mechanism for the emerging agentic AI ecosystem.
No credential sharing
With CIBA, users never need to share passwords with AI agents, eliminating a massive security risk. The authentication secrets remain on a user’s device and are never exposed during the process.
For example, if the AI agent is presented as an LLM (Large Language Model) via a chat interface, traditional methods would force a redirect for authentication, potentially having to enter their credentials or re-authenticate. With CIBA, the user can simply tap their smartphone and proceed.
Human approval/oversight
AI agents will eventually be quite clever, but for the short-term, they can’t be left to their own devices. For example, at the time of this writing, Claude Desktop in Computer Use mode could land on a website with a hidden prompt injection and be directed to take malicious action against the user. “Human-in-the-loop” refers to a security concept for agentic AI and tooling that recommends human approval for sensitive actions—like making a purchase, accessing sensitive information, or sending a Slack message to everyone in your organization.
Clear binding messages
In addition to looping in a human for approval, CIBA’s binding messages keep users apprised of their agent’s activity. Clear binding messages ensure that, if an agent wants to do something requiring extra authentication, you know exactly what it’s for.
In the not-to-distant future, you might ask your AI assistant to “Buy me a new pair of shoes,” and moments later receive a prompt with two options. Selecting one, you’ll then see the result of a CIBA flow: a binding message explaining the transaction and asking you to authenticate.
Reliance on proven standards
Rather than reinventing the wheel for agentic AI authentication, CIBA leverages established protocols that have been tested and validated over years of refinement. The underlying mechanisms of CIBA not only enable asynchronous workflows—meaning the AI agent can continue with other tasks while waiting for authentication—but they also ensure a high level of phishing-resistant security.
While some organizations have proposed new authentication protocols specifically for AI tooling and agents, the rationale is questionable: are AI agents really so different as digital denizens that we require a novel framework? No, say most identity providers, as they look to existing standards.
CIBA’s future as an out-of-band authenticator
As AI agents become more integrated into our daily lives, the need for secure delegation mechanisms will only grow more intense. CIBA is in a unique position to become the new standard for human-in-the-loop design philosophy within AI systems. Because it neatly balances rigorous security with usability, CIBA has already seen adoption across the financial sector—one of the most demanding industries when it comes to protecting user data and privacy.
For now, the specification remains a mostly scenario-specific method when other options fail; however, the incoming deluge of agentic AI apps is likely to turn the tide in favor of CIBA over most alternatives. The fact that financial institutions trust it with high-value transactions will certainly contribute to its perception. As AI agents begin handling more sensitive tasks across industries, CIBA’s proven approach to secure delegation is bound to see broader implementation.
For more identity concepts and developer news, subscribe to our blog or follow us on LinkedIn.
