An Introduction to Client Initiated Backchannel Authentication (CIBA)

Traditional OpenID Connect authentication flows in web and mobile applications rely on browser redirects. Users typically start the authentication process within the client application on their device, get redirected through their browser to the Identity Provider to authenticate, and finally return to the client application. This requires the user's primary device to both handle authentication and provide access to the client application.

Redirect flows work well when the same device can access both the client application and the Identity Provider and when the user initiates the authentication process. 

But what if you need to trigger the authentication from one device but complete it on another? For instance, in some situations, the client application is not controlled by the end user, but authentication is still required.

That’s where the new CIBA flow offers a solution.

What is CIBA?

CIBA (Client Initiated Backchannel Authentication) is an extension to the traditional OpenID Connect flows where the client application initiates the authentication process on behalf of the end user.

Unlike traditional flows, CIBA facilitates direct communication between the client application and the OpenID Provider, so there is no need for a browser at all. 

In other words, end-user interaction is not required to start the authentication process with CIBA. This opens new possibilities for secure and user-friendly authentication solutions.

Key concepts for understanding CIBA

Here are some helpful terms to keep in mind:

• Decoupled Authentication: CIBA separates (decouples) the device where the client application runs (“consumption device”) and the device where the user authenticates (“authentication device”).
  
  
• Consumption Device initiates the CIBA flow by sending an authentication request to the OpenID Provider.
  
  
• Authentication Device handles end-user authentication. It will receive notifications from the OpenID Provider, asking the user to approve or deny authentication requests.
  
  
• OpenID Provider (Authentication Server) manages user identities and handles authentication requests.
  
  
• Backchannel Communication: The OpenID Provider and the client application communicate via the backchannel. This means that only confidential clients (e.g. traditional server-based applications) are eligible to use CIBA.

When to use CIBA?

Some key use cases for CIBA include:

Proving your identity to a call center agent

This is a canonical example that highlights the advantages of the decoupled flow. When a call center agent needs to verify a caller's identity, they initiate an authentication request for the caller. The caller receives a notification on their authentication device—typically a smartphone—to confirm their identity.

Learn more about Caller authentication >

Point-of-sale (POS) terminals

POS systems can initiate a payment authorization, and the user will approve the transaction on their phone.

IoT (Internet of Things) devices 

IoT devices like smart TVs and appliances often lack convenient input methods. 

CIBA allows these devices to trigger an authentication on a user’s smartphone, which is more user-friendly. For example, a smart TV could prompt you to authenticate on your phone before accessing a streaming service. 

Another IoT use case is when you ask Alexa or Siri to make a purchase. Before completing the payment, your virtual assistant could use CIBA to verify that the correct person made a purchase request by sending a notification to your smartphone.

How CIBA works

Let’s now take a closer look at how the authentication process unfolds with CIBA:

1. Client application initiates an authentication request: The client application sends a CIBA authentication request to the backchannel authentication endpoint of the OpenID Provider’s Authorization Server. This request includes:
   
   
   • Client credentials for authentication
   • Scopes
   • A valid identifier of a user to be authenticated (email address, social security number, or any other unique identifier)
2. Authorization Server immediately responds with an Authorization Request Identifier: The unique auth_req_id will be used to track the authentication process.
   
   
3. User authentication: The Authorization Server uses the provided user ID to locate and prompt the user to authenticate on their authentication device.
   
   
4. Token issuance & delivery: Once the user successfully authenticates and grants consent (if applicable), the Authorization Server creates an ID Token, Access Token, and optionally a Refresh Token.
   
   The client can then use one of three modes to get tokens from the Authorization Server token endpoint:

• Poll: The client regularly checks for tokens. 
• Ping: The client fetches the tokens from the token endpoint upon receiving a notification from the OpenID Provider.
• Push: The OpenID Provider will deliver the tokens to the Client Notification Endpoint.

Introducing Swedish BankID phone authentication (powered by CIBA)

Swedish BankID phone authentication provides a secure method for user identification during telephone calls. It could work as follows: 

1. The user calls customer service at their bank (or other business).
2. The customer service agent enters the user’s SSN number in their system and initiates an authentication request to the user’s BankID app. 
3. The BankID app displays a phone icon and the company’s name, asking whether the user called the company.
4. The user responds: 
   • If Yes, they proceed to authenticate themselves with a security code or biometrics
   • If No, they can cancel the process.

Criipto Verify now delivers BankID phone authentication through CIBA.

Summary

CIBA lets developers build user authentication experiences suitable for scenarios where traditional redirect-based authentication is not possible.

Do you have a specific use case in mind? Reach out to us via email or Slack to discuss it, or share any thoughts or inquiries. We’d love to hear from you.