Feature Spotlight: Client Initiated Backchannel Authentication (CIBA)
While our V6 release is mostly about performance, stability and updates for the .NET 6 long term support version, we
added one big feature: CIBA (Client Initiated Backchannel Authentication).
The Problem
“Traditional” OpenID Connect authentication flows make the assumption that the client application and the “login page”
are executed on the same device.
For example, a user uses a web app in a browser, and that same browser is redirected for the user to login at
IdentityServer, and this all takes place on the user’s device.
There are scenarios where that assumption is not correct, e.g.:
- a user can use a kiosk at the public library to access their data, but they perform the actual login on their mobile
phone - a user is at the bank and the bank teller wishes to access the user’s account, so the user logs into their mobile
phone to grant that access - A user wants to use their smartphone to authorize a payment they are making at a point of sale terminal
Or more generally speaking, whenever you need to separate the device running the client (aka consumption device) and the
device running the authentication workflow (aka authentication device), a different approach is needed.
The Solution
CIBA specifies new flows
for exactly those purposes.
In a nutshell, with CIBA
a) the client application first notifies IdentityServer about the required authentication
b) IdentityServer will then notify the user via a preferred channel (e.g. SMS, email or push notification) on the
authentication device
c) after the user has finished the authentication workflow, the client application will receive the authentication
response including the requested tokens
In reality, this is an involved workflow – but we abstracted the moving parts into well-defined interfaces to help you
implement your logic securely. Please have a look at our
And feel free to contact us with any questions you might have!