CIBA and FAPI-CIBA
for backchannel authentication

Nothing in this flow involves a redirect or a hosted authorization page. Your backend authenticates as a client, posts a backchannel authentication request carrying exactly one hint about the user, and receives a request handle along with how long the request lives and how often it may be polled.

A backchannel push starts the face check on the enrolled phone. SenseCrypt also emails the sign-in QR to the resolved person. Phone sign-in combines the live face check with a key bound to that enrolled device.

The client that opens the request never becomes the thing that authenticates. Every key and every signature involved in proving who the person is stays on their own handset, and the requesting service only asks and waits. That separation is the reason the pattern suits a terminal that a dozen people touch in a day.

This is where implementations differ most, and it is the difference that matters. An approval that needs only a tap can be worn down: send enough prompts to a tired person and one will be accepted. Here the prompt opens a face check that runs on the phone, and no accept button stands in for it.

It also removes the conversation an attacker needs. There is no code for a caller to talk somebody into reading out, and no approval a help desk can be persuaded to perform on someone's behalf. The 2023 MGM Resorts incident, where attackers reached an IT help desk by phone and impersonated an employee, with an about $100M reported impact, is the shape of attack this closes off.

The requesting station stays empty throughout. A shared terminal running this flow displays what it is told to display and waits for an answer, so when a shift ends there is nothing on it that belonged to the people who just left.

Three situations fit: the person is somewhere other than the client, the client has a screen nobody should trust, or the client has no browser whatsoever. Call center verification is the first, a shared terminal or point-of-sale confirmation is the second, and a backend step-up before a high-value action is the third.

Agent-assisted verification is the clearest example of the value. The agent starts a request and watches it succeed, and nothing reusable passes in either direction. Presence is proven on the customer's own handset, to the identity provider rather than to the agent, so a recording of that call holds nothing worth stealing.

It is worth being equally clear about where the flow is the wrong choice.

Your client is registered for exactly one delivery mode, and the registration decides the behavior rather than a parameter on the request. Poll and ping both end with your service collecting tokens at the token endpoint; push delivers them to your notification endpoint and forbids polling entirely.

Everything else is the platform you already have. A backchannel client is registered in the same place as everything else, inside one tenant, next to your OIDC applications and SAML service providers. Enrollment carries across: somebody who can already complete a browser sign-in is ready for a decoupled one with no further setup, and the resulting tokens carry the same claims, including the permissions your own API enforces.

Nothing here is billed as a separate product, because this is one protocol surface of the same tenant. Pricing is the platform's: one dollar per user each month at list, a floor of 20 seats, and a trial that runs 30 days without a card.