---
title: "Introducing CIBA for Secure Transaction Verification"
description: "CIBA addresses identity verification when an application cannot use an interactive login on the consumption device, including bank customer-service changes, retail POS payments, browser-constrained devices, and shared kiosks. Client-Initiated Backchannel Authentication decouples authentication from the application: a client sends a back-channel request to an OAuth 2.0 authorization provider, while the user approves it on a separately enrolled phone or smartwatch. CIBA extends OpenID Connect with a grant type, discovery metadata, and poll, ping, and push token-delivery modes; in the described banking flow, the application receives a user-scoped token to update the email address. The approach improves least-privilege access and avoids exposing credentials on shared devices, but can enable MFA-fatigue-style attacks, should not be used same-device, and may warrant device code flow in some cases."
---

# Introducing CIBA for Secure Transaction Verification

[Okta](https://yomu.fyi/company/okta) · Indranil Jha · Jul 31, 2025

**Type:** Explainer

## Summary

CIBA addresses identity verification when an application cannot use an interactive login on the consumption device, including bank customer-service changes, retail POS payments, browser-constrained devices, and shared kiosks. Client-Initiated Backchannel Authentication decouples authentication from the application: a client sends a back-channel request to an OAuth 2.0 authorization provider, while the user approves it on a separately enrolled phone or smartwatch. CIBA extends OpenID Connect with a grant type, discovery metadata, and poll, ping, and push token-delivery modes; in the described banking flow, the application receives a user-scoped token to update the email address. The approach improves least-privilege access and avoids exposing credentials on shared devices, but can enable MFA-fatigue-style attacks, should not be used same-device, and may warrant device code flow in some cases.

## Context

Applications often need to verify identity during sensitive operations such as changing a bank account email address, recovering credentials, making a POS payment, or using a shared or browser-constrained device. Interactive login may be inappropriate in these contexts, while ad hoc verification can create poor user experiences, account-takeover risks, and overly powerful backend credentials.

## Approach / What changed

CIBA separates the consumption device from the authentication device. The client initiates a back-channel request to an OAuth 2.0 authorization provider, which sends an authentication prompt to a securely enrolled phone or smartwatch. After approval, the provider returns a token through a poll, ping, or push delivery mode; the token can be scoped to the user and target operation.

## Takeaways

- CIBA defines three token-delivery modes: poll, where the client repeatedly checks for completion; ping, where the provider notifies a registered client URL; and push, where the provider sends tokens to that URL.
- The banking email-update flow uses a push notification to a separately enrolled phone or smartwatch, followed by a user-scoped token that lets the customer-care application complete the update.
- CIBA can be abused through repeated unsolicited authorization prompts resembling MFA-fatigue attacks; the source recommends considering device code flow in some cases and avoiding same-device use.

**Tags:** [Authentication](https://yomu.fyi/topic/authentication), [CIBA](https://yomu.fyi/topic/ciba), [OAuth 2.0](https://yomu.fyi/topic/oauth-2-0), [Security](https://yomu.fyi/topic/security)

- Source: [Okta](https://developer.okta.com/blog/2025/07/31/ciba-okta)
- Source URL: https://developer.okta.com/blog/2025/07/31/ciba-okta
- Ingested by Yomu: 2026-09-09T08:43:53.456Z

[Read original post](https://developer.okta.com/blog/2025/07/31/ciba-okta)