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

1. the client application first notifies IdentityServer about the required authentication

2. IdentityServer will then notify the user via a preferred channel (e.g. SMS, email or push notification) on the authentication device

3. 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

• documentation
• sample