On this page
What does CIBA do?
CIBA is an authentication flow where the user approves a sign-in on a separate device. The full name is Client-Initiated Backchannel Authentication, and it belongs to the OpenID Connect family.
The unusual part is who starts it. In a normal OIDC flow the user is at the browser being redirected. In CIBA the application asks the identity provider to reach the user, and the user answers on a device they already hold. No redirect happens at all.
How does the CIBA flow work?
The application makes a backchannel request that names the user it wants authenticated. The identity provider contacts that user's registered device, waits for the outcome, and returns tokens to the application when the ceremony completes.
Because there is no redirect to carry state, the specification adds a few pieces that the redirect flow gets for free.
A login hint identifies the user
The application must already know who it is asking about, using an identifier the identity provider recognizes. CIBA reaches a known user rather than discovering one.
The client polls or is notified
The application either polls the token endpoint with the request identifier or is called back when the user has answered. Nothing resumes in the browser, because nothing left it.
A binding message ties the two ends together
A short value shown both on the requesting screen and on the user's device lets the user confirm they are approving the request in front of them, not one a stranger started.
Denial and expiry are normal outcomes
The user can refuse, and the request times out if nobody answers. Your integration has to handle both, not only the happy path.
Where do companies use CIBA?
CIBA earns its place when the person who must be authenticated is not sitting at the screen that needs the answer. That describes more of the real world than the redirect flow assumes.
It is also the honest answer for shared hardware. A device used by many people should never hold anybody's credential, and CIBA leaves the credential on the phone in the worker's pocket.
Contact center verification
An agent starts a check while on the call, and the customer proves who they are on their own phone. The agent never handles a code, so no agent can be talked into reading one out.
Point of sale and high-value approvals
A transaction over a threshold pauses for an out-of-band approval on the account holder's device, without moving the checkout into a browser.
Screens with no good input method
Kiosks, smart devices, and shared terminals get a sign-in without a keyboard and without holding anything about the user.
How does SenseCrypt use CIBA?
SenseCrypt supports CIBA, and the approval is a face ceremony rather than a button. The backchannel prompt opens the same device-bound check as a normal sign-in: the user looks at the camera on their enrolled phone, and the match runs there.
That choice removes the weakness push approval is known for. There is no approve control to tap by reflex, so an unexpected prompt cannot be dismissed into an account takeover.
The prompt starts a face check
Approval needs the enrolled person at the enrolled device. Possession of an unlocked phone is not enough on its own.
The screen in front of the user is not the trust anchor
On a shared workstation the station shows a request and waits. It never authenticates and it holds no credential, because the worker's own phone does the cryptography and the face check.
Standard tokens come back
Your application receives ordinary OIDC tokens at the end of the flow. The integration differs at the start of the ceremony, not at the end.
Frequently asked questions
What does CIBA stand for?
CIBA stands for Client-Initiated Backchannel Authentication. It is part of the OpenID Connect family.
How is CIBA different from an OIDC redirect?
An OIDC redirect uses the browser on one device. CIBA moves the approval to a separate, trusted device through a backchannel.
Does SenseCrypt support CIBA?
Yes. SenseCrypt supports CIBA. The user approves the sign-in by face login on a phone.
Related