CIBA

Enterprise

Client-Initiated Backchannel Authentication · Decoupled approval via a real Auth0 Guardian push notification · No redirect, no browser round-trip on the approver's device at all

Architecture & Token Flow

CIBA backchannel authentication flow diagram

CIBA approves an action for whichever user is currently signed in — it targets the same identity as your active session on Traditional, BFF, High Trust, or any other pattern in this demo, framing it as step-up approval for a sensitive action mid-session. Sign in via the Traditional demo then come back here.

What this pattern demonstrates

Decoupled auth— the requesting device (this browser) never redirects anywhere. Approval happens entirely out-of-band, on a separate device the requester doesn't control.

No persisted consent— every CIBA call is a standalone authorization event. Auth0 does not check or cache prior grants, even for a repeat request seconds later — the approver is prompted fresh every time.

Real push notifications— this requires an Enterprise plan and a genuinely enrolled Guardian device, not a simulated approval inbox. async_approval_notification_channels: ['guardian-push'] on the Auth0 application is what makes this reachable at all.

Standard vs HRI— toggle above between a plain binding_messagestring and a Rich Authorization Requests payload, one pillar of Auth0's Highly Regulated Identity (FAPI-aligned) feature set. Same transaction, same approver — only the shape of what Guardian renders changes: one opaque sentence versus itemized, structured fields.

Security Implications

Strengths

Out-of-band approval on a device the requester never touches is far harder to phish than a redirect-based prompt — there's no URL bar for an attacker to spoof.
No persisted consent: Auth0 does not check or cache prior grants, so a compromised requesting device can't silently reuse an old approval — every request needs a fresh approval from the actual approver.
Rich Authorization Requests (the HRI toggle in this demo) directly closes the binding_message risk below: instead of one opaque string, Guardian renders structured, itemized transaction fields — the approver can actually verify amount/order/action rather than trusting free text. This is one pillar of Auth0's Highly Regulated Identity (FAPI-aligned) feature set; the others — PAR, JAR, mTLS, JWE, sender-constraining — harden the request/token in transit and aren't visually demoed here since they don't change what's displayed.

Risks & Considerations

binding_message is rendered verbatim on the approver's push notification but is not cryptographically bound to the actual transaction — if the requesting app lets a user (or an attacker who's compromised it) set arbitrary text, the approver could be tricked into approving something other than what the message describes. Standard CIBA has no built-in defence against this; it requires the requesting app to be trustworthy.
authorization_details fixes the display problem, not the trust problem — Guardian faithfully renders whatever fields the requesting app sends, so exactly the same rule applies: those fields must be generated server-side from a verified transaction, never taken from client input.
The 5-minute default window for push delivery is short enough to be a real UX/security tension in production: too long invites approval fatigue and stale-context approvals, too short causes legitimate requests to expire before the approver even sees the notification.
This demo channel (Guardian push) requires an Enterprise plan — teams without one may be tempted to fall back to email notifications or a simulated approval flow without carrying over the same anti-phishing properties.

Hardening Checklist

Always generate binding_message (and authorization_details, if using RAR) server-side from the actual transaction being approved — never forward client-supplied free text or fields into either.
For regulated/high-value transactions, prefer Rich Authorization Requests over binding_message alone — itemized fields give the approver something concrete to verify, not just a sentence to trust.
Treat the auth_req_id's short expiry as a feature, not friction — pair short-lived CIBA windows with a separate, longer-lived business-level approval-request record if the real-world action needs more time than 5 minutes to be actioned.
Monitor access_denied and expired_token responses — a pattern of repeated denials or expirations against the same user is a signal of either approval fatigue or an attacker probing for a moment of inattention.