The most comprehensive online tool to test Client Initiated Backchannel Authentication (CIBA). Send authentication requests, poll for tokens, inspect responses, and validate your CIBA implementation in seconds.
CIBA (Client Initiated Backchannel Authentication) is an OpenID Connect extension defined by the Financial-Grade API (FAPI) working group that decouples the authentication device from the consumption device. Unlike traditional redirect-based OAuth flows where the user authenticates on the same browser session, CIBA enables a client application — such as a call center agent, smart TV, IoT kiosk, or digital wallet — to trigger authentication on a completely separate channel, typically the user's registered mobile device.
In a standard CIBA authentication request, the client submits a backchannel authentication request
to the server's /bc-authorize endpoint, including a user hint (login_hint,
login_hint_token, or id_token_hint), client credentials, and optional parameters like
scope, binding_message, and user_code.
The server responds with an auth_req_id — a unique request identifier with an expiry —
that the client uses to obtain tokens.
The CIBA delivery mode determines how tokens reach the client. In Poll mode, the client repeatedly queries the token endpoint using grant_type=urn:openid:params:grant-type:ciba until the user approves or the request expires. Ping mode reduces polling overhead by having the server send a lightweight notification to the client's registered client_notification_endpoint, after which the client fetches tokens once. Push mode delivers tokens directly to the notification endpoint — ideal for highly responsive applications.
Our CIBA Flow Tester supports all three delivery modes, allows real-time metadata inspection of authentication requests and responses, provides sample demo configurations for popular identity providers, validates input parameters against the CIBA specification, and generates downloadable test reports. Whether you are integrating CIBA for open banking, healthcare, or enterprise SSO scenarios, this tool accelerates your implementation and debugging workflow dramatically.
Fill in the form above and click Refresh to preview the request body.
Fetch and inspect the OpenID Connect discovery document to identify CIBA-specific endpoints and capabilities.
No history yet. Successful requests will appear here for easy replay.
⚠ Disclaimer: This tool is provided for testing and development purposes only. "CIBA", "OpenID Connect", "OAuth 2.0", and related terms are trademarks or registered trademarks of their respective owners including the OpenID Foundation. "Keycloak" is a trademark of Red Hat, "Okta" and "Auth0" are trademarks of Okta Inc., "Azure Active Directory" is a trademark of Microsoft Corporation, "PingFederate" is a trademark of Ping Identity Corporation. Use of these names is for identification purposes only and does not imply endorsement. Do not transmit production credentials or sensitive user data through this tool. All requests are proxied server-side via a secure PHP backend for CORS compatibility.
A comprehensive toolkit for developers implementing Client Initiated Backchannel Authentication
Test Poll, Ping, and Push delivery modes. Configure notification endpoints and auto-fill token requests from auth responses.
Automated polling with configurable interval and attempt limits. Real-time progress bar and polling log with status updates.
Instantly decode and inspect ID tokens, access tokens, and login_hint_tokens. View header, payload, claims, and expiry.
Pre-loaded sample configurations for Keycloak, Okta, Auth0, PingFederate, Azure AD, and ForgeRock to get started instantly.
Fetch and parse OpenID Connect discovery documents to identify bc-authorize endpoints, supported modes, and CIBA capabilities.
Instant field-level validation against the CIBA specification. Required fields, URL formats, JWT structure, and more.
Include Rich Authorization Requests (RFC 9396) authorization_details for fine-grained authorization scenarios.
Session-based request history for easy replay and comparison of different CIBA configurations and provider responses.
Copy responses to clipboard or download complete test reports as formatted TXT files for documentation and debugging.
Understand each stage of the Client Initiated Backchannel Authentication protocol
The consuming device (client) sends a POST to the /bc-authorize endpoint with user hint, client credentials, scope, and optional binding_message.
The authorization server validates the request and returns an auth_req_id, expires_in, and the recommended interval for polling.
The server sends a push notification to the user's registered authentication device (mobile app). The user reviews the binding_message and approves or denies.
In poll mode, the client repeatedly sends grant_type=urn:openid:params:grant-type:ciba with the auth_req_id. Responses include authorization_pending or slow_down until approval.
Upon user approval, the token endpoint returns access_token, id_token, and optionally refresh_token. The CIBA flow is complete.
auth_req_id is a unique, opaque identifier returned by the authorization server after a successful backchannel authentication request. It acts as a handle for the pending authentication. Its lifetime is specified in the expires_in field of the response (typically 120–300 seconds, but configurable per provider). The client must complete token acquisition before this expires.
auth_req_id at the recommended interval until tokens are available or the request expires. Ping mode: The authorization server sends a notification to the client's pre-registered client_notification_endpoint using the client_notification_token, after which the client fetches tokens once. Push mode: The authorization server pushes tokens directly to the client_notification_endpoint — the most efficient mode for responsive applications.
authorization_pending is the expected error response when polling the token endpoint before the user has approved the authentication request. The client should continue polling at the recommended interval. If the server returns slow_down, the client must increase the polling interval by 5 seconds. expired_token means the auth_req_id has expired; access_denied means the user rejected the request.
binding_message to prevent phishing attacks (the message links the consuming device to the authentication action); requiring HTTPS everywhere; implementing client authentication (never use public clients without careful consideration); setting appropriate requested_expiry values; and validating the id_token signature and claims after token acquisition.
From API testing to SSL inspection, web performance, and 100+ AI-powered utilities — all free, no account needed.