On this page
What CIBA is
CIBA is Client-Initiated Backchannel Authentication, an OpenID Connect flow for the case where the thing that needs authentication is not the thing the user is holding. The client starts the request over the back channel, and the user answers on their own enrolled device.
It exists because not every sign-in begins in a browser. A support agent, a kiosk, a point-of-sale terminal, and a back-end job all need a person to prove presence without a redirect.
The client starts it, not the browser
There is no redirect and no authorization URL. Your service calls SenseCrypt directly, then waits for the result.
The user answers on the device they enrolled
The prompt lands on their own phone, and that phone is the trust anchor. This is why the flow still works when the requesting device belongs to nobody in particular.
How CIBA works
Your back-end client sends a backchannel authentication request. SenseCrypt notifies the user's enrolled device, and the user completes a face ceremony there, with the capture and the match running on the phone. On success, SenseCrypt issues the tokens to the client that asked.
Pay attention to what the user actually does on the phone, because this is where CIBA implementations differ most.
It is a face ceremony, not a tap
The push does not ask the user to approve a notification. It starts a device-bound face check, so a stolen unlocked phone does not carry an attacker through.
The requesting station never authenticates
On a shared terminal the station shows a QR code and waits. It holds no credential and performs no cryptography, because the worker's own phone does all of it.
Nothing is typed anywhere
There is no password and no shared code in the flow, so nobody can be talked into reading one out. That is the usual failure of phone-based approvals.
Where CIBA earns its place
CIBA is the right flow when the person and the client are not in the same place, or when the client has no screen worth trusting. Shared workstations are the clearest case: the terminal is public, and you do not want it holding anything at all.
It is also the honest answer for support desks. An agent can trigger a verification and see it succeed without ever hearing something they could reuse.
Shared and public terminals
The station shows a code and waits. Nothing about the worker lives on it, so the next shift inherits a clean device.
Agent-assisted verification
The agent starts the request and the customer proves presence on their own phone. No secret passes between them in either direction.
Clients with no browser
Terminals, kiosks, and back-end services can require a human decision without embedding a web view or storing a credential.
How to turn CIBA on
Register a backchannel client, start a request from your service, and poll for the result. It uses the same registration model as the rest of the platform and the same enrollment, so a user who can already sign in by face can already answer a CIBA request.
CIBA is one surface of the identity provider, not a separate product with its own bill.
One registration model
A backchannel client sits alongside your OIDC and SAML applications, in the same console, under the same tenant.
The same roles apply
Tokens issued through CIBA carry the roles SenseCrypt resolves at sign-in, and your application enforces them exactly as it does for a redirect flow.
Try it on the 30-day trial
No card is needed. List price is one dollar per user per month, with a 20-seat minimum.
Frequently asked questions
What is CIBA authentication?
CIBA is Client-Initiated Backchannel Authentication. A backend client starts the request. The user approves it on a separate device by face login.
How does the user approve a CIBA request in SenseCrypt?
The user gets a prompt on an enrolled device. The user approves by face login. Face matching runs on-device.
Is CIBA phishing-resistant?
Yes. The approval binds to the device. You enter no password and no shared code. So a phishing page has nothing to capture or replay.
Related