01
What CIBA changes
In a CIBA exchange the approval happens on a device other than the one that asked for it. The flow belongs to the OpenID Connect family and reuses the same token formats and the same verification rules, so what an application receives at the end is entirely familiar.
What changes is who initiates. A redirect flow assumes the person is sitting at the browser and pushes them toward the provider. CIBA reverses that: the application requests that the provider reach a named user, who responds on hardware already in their possession. No redirect occurs, and the screen waiting for an answer never has to be the screen where authentication happens.
That inversion is the whole value. It decouples the place where a decision is needed from the place where a person can safely prove who they are.
02
How the flow runs
An application opens a backchannel request that names the person it needs authenticated. The provider then reaches that person's registered device, holds the request open until the ceremony finishes, and hands tokens back once it has.
Because there is no redirect carrying state, the specification adds several pieces that the redirect flow receives for free from the browser. Each of them is worth implementing deliberately rather than copying from an example.
The request has to name its subject
The requesting application must identify the person in advance, using an identifier the provider recognizes. The flow is built to reach somebody already known rather than to discover who is at the other end, which is why it makes a poor general front door.
Delivery is by polling or by callback
Holding the request identifier, the client either polls the token endpoint or waits for a ping or a push once the person has answered. No browser resumes anything, since nothing was ever handed to one.
A binding message links the screen to the phone
A short value rendered on the requesting screen and again on the phone lets the person check that the request being approved is the one in front of them and not one a stranger opened elsewhere.
Refusal and timeout are ordinary results
The user can refuse, and a request times out when nobody answers. An integration that only handles the successful path will fail in production in ways that look like outages.
03
Where CIBA fits
The flow becomes the right choice whenever the person who has to authenticate is somewhere other than the screen waiting on the answer, and that covers far more of working life than a redirect flow assumes.
Shared hardware is the second case, and there the flow is simply the correct architecture. Equipment used by dozens of people has no business holding anyone's credential, and this pattern leaves the credential in a pocket while the shared screen waits for an answer.
Contact center verification
The agent triggers a verification mid-call, and the customer answers on their own handset. Because no code passes through the agent, no agent can be socially engineered into reading one aloud.
High-value approvals
A transaction above a threshold halts for an approval that happens elsewhere, on the account holder's own device, without relocating the entire checkout into a browser session.
Authenticate from displays without keyboards
Kiosks, shop-floor terminals and shared workstations get a real sign-in without a keyboard, without a shared account, and without storing anything about the user locally.
04
CIBA is not the same as proprietary push
The two are confused constantly, because both end with something happening on a phone. The difference is what the flow is and what it returns. CIBA is a specified OpenID Connect flow: the application receives a request identifier, the specification defines the polling and notification behavior, and the result is a standard token set that any conformant client can verify.
A proprietary push is usually a vendor notification that resolves to a yes or no inside a session the vendor controls, offered as a second factor bolted onto an existing login. It is not portable, it is rarely specified in public, and the approval it collects is a tap rather than an authentication.
The distinction matters when a provider is replaced. A CIBA integration is configuration against a standard, so the client code survives the change. A proprietary push integration is an SDK, and replacing it is a development project in every application that adopted it.
05
How SenseCrypt implements CIBA
SenseCrypt supports CIBA and FAPI-CIBA financial-grade flows. A live face check replaces tap-to-approve. The IdP validates the device-signed authentication result before returning the configured tokens.
That choice closes the failure mode push approval is known for. Nothing can be tapped by reflex, so an unexpected notification cannot be waved through into an account takeover. Approval demands the enrolled person in front of the enrolled device, which is a stronger statement than holding an unlocked phone.
Token delivery follows the specification: poll, ping, or push. An ordinary set of OIDC tokens arrives when the flow completes, which means the difference from a redirect integration sits entirely at the beginning of the ceremony.
The notification opens a face ceremony
Approval needs the enrolled person in front of the enrolled device. Holding an unlocked phone is not sufficient on its own, which is the entire point of using a biometric factor here.
Keep authentication on the enrolled phone
A shared workstation renders a request and then waits. It authenticates nobody, stores no credential and requires no enrollment, because the cryptography and the face check both take place on the worker's own phone.
Return standard OIDC tokens
However the ceremony began, the application finishes by verifying an ordinary OIDC token set through the same code path a redirect sign-in already uses.
No shared code is displayed
Nothing readable is presented for the user to relay to anyone. A caller pretending to be support has no value to ask for, which closes the most common CIBA social-engineering script.
06
Frequently asked questions
What does CIBA stand for?
Client-Initiated Backchannel Authentication. It sits in the OpenID Connect family and returns the same token formats a redirect flow returns.
How is CIBA different from an OIDC redirect?
A redirect flow authenticates the user in the browser that started the request. CIBA moves the ceremony to a separate registered device over a backchannel, so the screen needing the answer and the device proving identity can be different machines.
Is CIBA vulnerable to prompt fatigue?
Any flow reducible to a single tap is. SenseCrypt's implementation is not reducible to a tap: the prompt opens a face ceremony on the enrolled device, so an unexpected notification cannot be dismissed into an approval.
Can CIBA be used on kiosks and shared terminals?
That is one of its best applications. The shared screen holds no credential and needs no enrollment, and each worker authenticates on their own phone, which removes both the shared account and the residue left behind for the next person.
Does SenseCrypt support CIBA?
Yes. SenseCrypt supports CIBA and FAPI-CIBA for financial-grade backchannel authentication. A live face check authorizes the authentication response; token delivery follows the configured profile.