Introducing CIBA for Secure Transaction Verification

Digital applications constantly deal with identities. It’s important to verify identity at the application’s front door through authentication. Several mature and sophisticated techniques and standards for user authentication, such as OpenID Connect (OIDC) and Security Assertion Markup Language (SAML), allow a trusted identity provider (IDP) to securely authenticate the user before allowing access to an application.

However, front door authentication is not the only context in which identities must be verified.

Consider the following scenarios:

• Update your email address through a bank’s customer service
• Recover the userID/password through HelpDesk
• Securely perform a transaction at a retail Point of Sale (POS) system
• Authenticate with browser-constrained devices, such as smart speakers
• Authenticate from a shared kiosk

In each of the above cases, though the identities need to be verified, it might not be possible or appropriate to have the user perform authentication through an interactive login interface such as a web browser.

Table of Contents

• How applications handle identity verification today
• Let’s step through identity verification scenarios
  • Update email address for bank accounts
  • Point of Sale (POS) payment
• Use CIBA to verify identity transactions securely and consistently
  • CIBA enables a smooth authentication experience
  • CIBA builds upon OAuth 2.0 and OIDC
• Security considerations when using CIBA
• CIBA support in Okta
• Use CIBA for secure identity verification in your apps
• Learn more about CIBA, Okta, and identity verification

How applications handle identity verification today

While it’s popular to leverage secure IDP and standards to provide initial authentication through a login interface, identity verification in places such as above is built in an ad hoc manner. Depending on design, some applications do this inefficiently with a terrible customer experience, while others are less secure and vulnerable.

Let’s step through identity verification scenarios

Consider identity verification needs where you can’t rely on a traditional user authentication process, such as when multiple parties or browser-constrained systems are involved. Let’s examine those cases and identify identity security pitfalls.

Update email address for bank accounts

Consider a user calls customer service to update the email address associated with their bank account. Often, the helpline personnel ask the user for certain personally identifiable information ( PII) answers such as last name, date of birth, and last 4 digits of social security number. Upon verification, the helpline personnel updates the email address through the customer care application, which performs privileged operations on the bank’s identity database to change the user record.

There are problems with the approach.

First, the customer experience is not great. The customer also needs to provide PII information for verification, which an attacker can guess or obtain using social engineering. This can easily lead to an account takeover, where a fraudulent actor can successfully pass the verifications and infiltrate the account with a new email ID. The second issue is that the customer care application needs to change the user profile from the backend without authentication. The application would typically use powerful credentials to perform such a privileged operation. For example, an application can obtain and use a token with user management privileges to call the user update API. Such a token allows updating user accounts in the banking system directory, but it can be misused if the token leaks.

Wouldn’t it be nice to get some form of token that provides the application with just enough privilege to update only the calling user profile? That way, it could adhere to the least privilege principle of security.

Point of Sale (POS) payment

This is another interesting scenario. When a user tries to pay in the retail Point of Sale (POS) system with a bank account, they won’t be comfortable signing in to their bank account on a shared device and providing their credentials.

Instead, it would be ideal if the POS system allowed secure payments with an alternative form of verification, where the user does not need to provide their credentials in a public system!

Can we do something to decouple user authentication from the application?

Use CIBA to verify identity transactions securely and consistently

The idea is to decouple authentication from the application so that it can be initiated on one device and verified on another. Client-Initiated Backchannel Authentication (CIBA) allows exactly that separation.

CIBA is a relatively new authentication flow based on OAuth 2.0 in which the client can initiate an interaction flow to authenticate the users without having end-user interaction from the consumption device. The flow involves back-channel communication from the client to the OAuth 2.0 authorization provider without redirecting through the user’s browser (consumption device). The authentication would be verified independently from a separate authentication device, such as a phone or smartwatch, in possession of the user and securely enrolled with the provider.

CIBA enables a smooth authentication experience

Consider the following flow for our banking email address use case.

1. The customer care application initiates an authentication event for the user. It sends a direct CIBA request to the authorization server.
2. Unlike a regular login page, the user is redirected to, the authorization server sends a push notification to the user’s phone.
3. The authorization server is notified when the user accepts the notification on her phone/smartwatch.
4. The authorization server then issues a user token to the application. The application uses the user-scoped token to complete the target operation, which is updating the email address.

A few benefits of this approach are:

1. The user experience becomes smoother during verification. It also can instill confidence in users that the system operates securely.
2. Push notification offers higher security than other out-of-band user authentication methods, such as SMS one-time code (OTP).
3. The application token can be narrowly scoped to the user, providing the least privileged access.

Here is a simplified flow of a transaction using CIBA.

CIBA builds upon OAuth 2.0 and OIDC

CIBA is an extension on top of OIDC, which itself is based on the OAuth 2.0 framework. It brings in a new OAuth 2.0 grant type in the family: urn:openid:params:grant-type:ciba. As customary with the OIDC discovery endpoint, CIBA introduces additional metadata parameters, such as backchannel_token_delivery_modes_supported and backchannel_authentication_endpoint. The discovery document payload looks like this:

{
    "issuer": "...",
    "authorization_endpoint": ".../authorize",
    "token_endpoint": ".../token",
    "userinfo_endpoint": ".../userinfo",
    "jwks_uri": "...",
    "grant_types_supported":[
      "authorization_code",
      "refresh_token",
      "password",
      "urn:openid:params:grant-type:ciba"
    ],
    "backchannel_token_delivery_modes_supported":["poll", "ping", "push"],
    "backchannel_authentication_endpoint": "",
    ....
}

The backchannel_token_delivery_modes_supported parameter needs some additional commentary. The specification defines three different modes of notifying the client about the completion of authentication.

• Poll: In this mode, the client keeps polling the authorization server until the authentication is complete or the event times out. In case of successful authentication, the final poll returns the tokens to the application. This mode is the simplest and easiest to implement.
• Ping: When the authentication is complete, it will call back to a registered URL of the client, notifying the status. The client makes a request to the authorization server for tokens.
• Push: When the authentication is complete, it will call back to the client’s registered URL with the tokens.

Ping and Push modes are more complex to implement and need additional metadata and implementation steps on the client side. However, it saves network trips caused by the polling cycle.

Since the CIBA request uses a back-channel, it must contain a parameter that the authorization server can use to identify the user. Typically, the parameter is supplied using the login_hint or id_token_hint parameter of the request.

The authentication device performs out-of-band authentication instead of the traditional authentication flow, where the client interacts with the authorization server sequentially. In practical implementations, it would be a push notification to a device such as a phone or smartwatch. The device needs to be securely registered to the authorization server for the user so that it knows where to send the authorization request. The push notification can be delivered by embedding the mechanism in the application’s mobile application or using a companion authenticator application.

Security considerations when using CIBA

CIBA is vulnerable to attacks akin to an MFA fatigue attack. Consider the case where an attacker guesses a user ID or infiltrates a user account and repeatedly attempts to carry out a sensitive transaction implemented using CIBA authorization. The real user might get overwhelmed by repeated push notifications and accept one.

A related scenario is when the attacker has a list of user IDs and initiates transactions for each. While most users would ignore the push prompt, a small percentage could approve the request.

In summary, CIBA suffers from a weakness where an attacker can force-initiate an authorization event. In certain scenarios, a more secure alternative is the device code flow, where a user can actively initiate authorization on their device using a QR code or one-time code.

Also, CIBA should not be used in a same-device scenario where the consumption and authentication devices are the same.

CIBA support in Okta

CIBA is not yet widely implemented. Okta has been an early adopter of the CIBA standard.

CIBA is rapidly gaining traction in the banking industry. FAPI specifications, developed based on the OAuth 2.0 token model, include the CIBA profile. CIBA, along with complementary product offerings such as Demonstrating Proof of Possession (DPoP), make up the key components required for highly regulated identity.

In Europe, CIBA can help implement the decoupled authentication flows outlined by PSD2 and UK Open Banking. Consumer Data Right (CDR) in Australia is expected to include the specification soon. Beyond the banking industry, CIBA is promising to provide enhanced security and user experience for the Helpdesk, customer service, retail Point of Sale (POS), Interactive Voice Response (IVR), and shared kiosk-based applications.

Okta supports CIBA in poll mode, a feature called Transactional Verification. The Okta authorization server includes the CIBA grant as part of the support.

The authentication process is supported by allowing the creation of a mobile push authenticator using the Okta device SDK. This SDK can be easily embedded in the organization’s mobile application or as a separate companion application. Check out the iOS and Android guides on how to implement a branded push authenticator using the SDK. The guides include sample applications to get you quickly started building the experience.

Use CIBA for secure identity verification in your apps

Digital applications are crucial for every business, and securing them is paramount. It’s not enough to protect just the front door with authentications. Applications must always be vigilant during their operations and operate on a zero-trust model. CIBA is an important tool to ensure that applications enforce continuous and secure authorization in appropriate contexts without compromising the user experience.

Learn more about CIBA, Okta, and identity verification

If you want to learn more about CIBA, Okta, and identity verification, check out these resources:

• CIBA specification
• Configure CIBA with Okta

Follow us on Twitter and subscribe to our YouTube channel for more identity content. Feel free to leave us a comment below about the identity topics you want to learn more.