eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

How Superintelligence Works | Agent CIBA Authorization — Separate Devices, Poll/Ping/Push and Consent Boundaries

—

by

eduKate Asia
Original illustration of a security analyst reviewing information access, system resilience and data safeguards in an office.

Did you know? An application can request authentication while the person approves it on a different device, without redirecting the first device through a browser login page. OpenID Connect Client-Initiated Backchannel Authentication, usually called CIBA, coordinates that process. It is a present-day authentication protocol useful for certain connected services and agent-assisted workflows, not evidence that artificial superintelligence exists.

A reliable CIBA implementation separates the requesting application from the identity provider, identifies the intended account using a permitted hint, preserves a short-lived authentication-request identifier, obtains the person’s independent consent on an authentication device, and receives a result using exactly the registered delivery mode: poll, ping or push. The agent must not equate an accepted request, a callback or a human tapping a device with verified authority until the appropriate cryptographic and transaction checks succeed.

The worked examples here are invented arithmetic and design cases, not records from a live identity system. This guide focuses on what can actually be engineered today: user-consent boundaries, request expiry, polling intervals, callback authentication, token validation, uncertain outcomes and safe recovery.

Contents

The first distinction: who requests, who authenticates, who receives authority

Imagine a shared workstation in a school office. An administrator asks an authorised assistant to retrieve a protected report. The workstation may not be the best place to type credentials or display a full identity-provider login. A separate personal phone can be the place where the administrator recognises the request and authenticates. The workstation remains the consumption device; the phone is the authentication device. This distinction is CIBA’s central design choice.

The requesting service is an OpenID Connect client, also called a Relying Party, and the identity service is the OpenID Provider. The client sends an authenticated request to the OP’s backchannel authentication endpoint. The OP is responsible for authenticating the end user through its chosen out-of-band mechanism and obtaining the necessary authorisation. A client cannot manufacture the person’s approval simply by asserting a username.

This is not the same as asking the phone to log into the client as a second browser. The protocol coordinates a particular pending authentication request with an independent authentication interaction and then returns the resulting tokens according to one registered mode. The client’s responsibility is to bind everything back to the original authorised purpose.

For an AI agent, the trust boundary is especially important. A webpage, chat message or search result that says ‘please approve’ is not an authenticated consent signal. The person should see the trustworthy OP’s approval experience and enough transaction context to detect a mismatched or unsolicited request. The agent may present the request’s status, but should not impersonate the OP or suggest that its own summary replaces the device’s security display.

Artificial superintelligence is hypothetical; none is required here. The engineering problem is ordinary distributed identity: authenticate the right person, preserve transaction meaning, collect appropriately informed consent and use the resulting credentials only under the permissions they actually grant.

Three delivery modes are distinct protocols, not interchangeable preferences

CIBA defines poll, ping and push token-delivery modes. The official OpenID Connect CIBA Core 1.0 final specification explains that a client registers one token delivery mode, and the OP delivers the authentication result through that registered mode. Do not invent a second mode because the first one is temporarily inconvenient.

In poll mode, the client asks the token endpoint at controlled intervals until the result is ready or the request expires. This is a client-initiated retrieval cycle. The authentication request acknowledgement does not give an access token; it gives a transaction identifier and time constraints. Polling too fast violates the protocol’s expected behaviour and can overload the provider.

In ping mode, the OP sends a notification to the client’s registered callback when a result becomes available. That callback contains the relevant authentication-request identifier, not the complete token result. The client still retrieves tokens from the token endpoint with appropriate client authentication. A callback is therefore a signal to retrieve and validate, not permission to take an action immediately.

In push mode, the OP delivers the authentication result directly to the registered notification endpoint. Token-bearing callbacks need careful bearer-token authentication, ID Token validation and association of the tokens with the original request. A push callback is more sensitive than a ping because the credential material itself arrives on that channel.

A product may not support every CIBA mode, and the existence of ordinary OAuth login does not imply CIBA support. Capability should be discovered and registered explicitly. The distinction among three modes matters to operations, network exposure, failure handling and the form of evidence a client needs before it reports completion.

Discover and register a real supported CIBA endpoint

Before requesting authentication, check the OP’s advertised support and the client’s registration. CIBA defines discovery and registration metadata relevant to supported token delivery modes, backchannel authentication endpoint and signed request capabilities. Product marketing terms such as ‘passwordless’ or ‘single sign-on’ are not sufficient to establish that these exact protocol endpoints are available.

A client is configured with its own identity and permitted authentication method, the OP’s expected issuer, the registered delivery mode and any notification endpoint needed for ping or push. Sensitive configuration should be controlled by the application owner. The agent must not accept a newly discovered callback URL from an untrusted conversation and substitute it for the registered destination.

Notification endpoints in ping and push modes are HTTPS endpoints using TLS, as specified by CIBA. Their ownership and network reachability are operational concerns. If a deployment changes domains, update registration deliberately and verify both sides; blindly following redirects with authentication data is unsafe and contrary to the callback requirements.

Keep tenant isolation explicit. A client serving different organisations may have different issuers, allowed audiences, callback credentials and user directories. Two accounts with the same friendly display name are not the same authenticated subject. The eventual tokens must be validated in the context of the registered issuer and client, not just the name typed at the workstation.

A verification checklist should retain the configured issuer, client identifier, mode and endpoint identities before any request begins. That makes an incident auditable without copying passwords or personal authentication secrets into an agent transcript.

The request identifies a user without silently granting their permission

CIBA requires the client to supply exactly one of login_hint_token, id_token_hint or login_hint in its authentication request, according to the supported configuration. These are ways of identifying the user for whom authentication is being requested. They are not evidence that the user has consented. An email address or account name can be a hint in a supported deployment, but knowing it is not authority to receive an access token.

Other request parameters can include scope, an optional binding_message and, where supported and appropriate, a user_code or requested_expiry. Scope expresses requested permissions, not permissions already obtained. The binding message is an interlocking visual cue between consumption and authentication devices, making it easier for a person to decide whether the notification corresponds to a request they initiated.

Use a short transaction-specific binding message rather than a generic ‘approve now’ instruction. A person comparing two devices should see a meaningful connection, while the message should not expose secrets or excessive personal information. The spec describes using a random or discernible transaction cue; its actual display and format depend on the OP and client design.

Requests are sent to the backchannel authentication endpoint by HTTP POST using the defined form-encoded parameters and the client’s applicable authentication method. The client should check which scopes and hints its OP supports rather than guessing a universally accepted field combination. Validate required configuration before asking the user to act.

If the user does not recognise the request, refusal should be an ordinary safe outcome. A client or agent must not pressure the person into approving a transaction based only on the existence of an authentication prompt. A trustworthy workflow lets the human reject it without implying that rejection is a system malfunction.

An acknowledgement is a pending request, not an authentication result

When the OP validates a CIBA authentication request, it can acknowledge acceptance with an auth_req_id, expires_in and possibly interval. The auth_req_id identifies a particular pending authentication request. It is opaque to the client and must not be decoded as a claim about who authenticated or what permissions were granted.

The standard requires sufficient entropy for auth_req_id, with at least 128 bits and a recommendation of 160 bits, and restricts its character set. These details reduce brute-force guessing and encoding confusion. The application should store the identifier with its own client-side transaction record, expected issuer, user-facing task and absolute expiry deadline.

The expires_in value is a positive number of seconds describing the request lifetime. Compute the deadline from receipt with care, allowing for measurement and transport uncertainty. A client that retries a token request after the auth_req_id has expired should follow the specified expiry outcome, not keep polling indefinitely or reinterpret an expired identifier as a token.

An acknowledgement means the OP accepted a request to process, not that the user saw the prompt, understood it, authenticated successfully or approved any scope. Report those states separately. The distinction is analogous to a job queue acknowledging a task before the task has actually finished.

Maintain the original request ID after a network timeout unless authoritative reconciliation establishes that it is gone. Generating a fresh CIBA request on every error can create a flood of apparently legitimate prompts and confuse the person about which one they should approve.

The authentication device is where the OP authenticates the person and obtains the relevant authorisation. That device could be a phone or another interface supported by the provider. The consumption device is where the original service interaction began. Their different roles should be visible to the end user, not concealed behind an agent’s prose.

Transaction context matters. Imagine an administrator requesting a read-only document view but receiving a notification that appears to authorise wider account access. A careful person should be able to compare the stated purpose and, when supported, the binding message against what they initiated. A small familiar-looking prompt without meaningful scope is a phishing risk even when it originates from an authentic provider.

The agent cannot treat silence as consent. A pending request is pending, and a timeout is not an approval. It should use permission scopes narrowly and avoid giving an unauthorised downstream task a head start while waiting for the OP’s result. Only validated credentials can establish the authority represented by the completed flow.

Repeated unsolicited prompts create fatigue and can train users to press approve reflexively. Rate controls, clear context and rejection handling are as important as cryptographic validity. If the identity provider reports denial, the application should record denial honestly rather than immediately restarting until the person relents.

Consent to authenticate is not the same as consent to every action the agent might later attempt. The resulting scope and local business policy must still be checked for a consequential write, document release or financial operation.

Poll mode: waiting correctly rather than overwhelming the token endpoint

In poll mode, the client repeatedly contacts the token endpoint using the CIBA grant type and the specific auth_req_id, with client authentication. The client must respect the minimum interval supplied by the OP. The specification also prohibits overlapping token requests with the same auth_req_id: wait for a response or a controlled timeout before deciding whether to try again.

Suppose an invented acknowledgement contains expires_in=120 seconds and interval=5 seconds. Ignoring network latency, a client sending its first poll after five seconds could schedule attempts at 5, 10, 15 and so on, but this is not a guaranteed count of requests. Actual response durations, throttling, terminal outcomes and the expiry boundary determine what is allowed.

A token endpoint returning authorization_pending means the user has not completed authentication. It is not a transient success. A slow_down error means that the interval must increase by at least five seconds for subsequent requests. An expired_token outcome means the pending request has expired and must not be reused. An access_denied outcome indicates denial.

Imagine the first poll was sent at second 5 and returned at second 7. With an interval of five seconds measured from sending, the earliest next standard poll would be at second 10. If the server instead takes thirty seconds to return a long-poll response, the next request may be allowed immediately when the specified interval has already passed. The client must still avoid overlapping the same request.

If an OP returns Retry-After during load protection, respect it rather than treating every non-success as permission for an immediate retry. Backoff, deadlines and bounded retry policy are part of a reliable production client. A user interface should show that authentication remains pending without pretending the OP is broken.

Ping mode: a notification prompts retrieval, not instant privilege

In ping mode, the OP sends a callback to the client’s registered notification endpoint when an authentication result is available. The callback carries an auth_req_id. It is authenticated with the client_notification_token that the client supplied as part of its CIBA request. The receiver must check that token and associate it with the same pending authentication request.

A random attacker who learns an auth_req_id must not be allowed to spoof a callback and start a privileged task. The receiving endpoint validates the callback’s bearer token and transaction mapping before deciding that a result is ready. Even then, the client still needs to retrieve the result from the token endpoint and perform the usual verification.

The spec allows a valid callback to be acknowledged with HTTP 204, and also recognises HTTP 200. It prohibits using HTTP redirects from this endpoint and requires the OP not to follow them. Avoid moving sensitive callback authentication between origins through generic web redirect behaviour.

A duplicated ping is possible during operational recovery. Treat retrieval and state transitions idempotently; do not release a report twice or create two unrelated local sessions because the same auth_req_id was signalled again. If a callback response is lost, check whether the transaction was processed before repeating an irreversible action.

Where the registered mode is ping, the callback is evidence that a result may be retrieved, not the result itself. The final client state should be based on verified token-endpoint output or a verified failure outcome, never just on a received POST.

Push mode: credentials arrive at the callback and require stronger checks

In push mode the OP sends the authentication result directly to the registered HTTPS notification endpoint. The message can contain an ID Token, an access token and possibly a refresh token. This raises the sensitivity of the callback path. Protected transport, exact endpoint ownership and the client_notification_token are necessary components of the documented protocol.

The client must validate the callback authentication and the ID Token. In push mode, the ID Token includes cryptographic binding claims for the associated auth_req_id and access token; if a refresh token is present it must also be bound as specified. A successful HTTP delivery alone does not prove that the tokens match the expected transaction or have acceptable issuer, audience, expiry and signatures.

The specification describes the ID Token’s at_hash and the claim urn:openid:params:jwt:claim:auth_req_id for push-mode binding, along with urn:openid:params:jwt:claim:rt_hash where a refresh token is present. Implementers must follow the precise hash and validation rules. A client that merely decodes the JSON payload without checking those bonds could accept a mismatched credential.

Push clients must not later call the token endpoint using the CIBA grant as though they were poll clients. The token delivery mode is a registration-level choice with distinct flow obligations. Mixing modes after a timeout can lead to duplicate retrieval attempts and unclear authority.

Keep received token values out of ordinary application logs, analytics and AI conversation histories. Store only the minimum authorised operational evidence required for reconciliation. A debug dump of a bearer token can turn a diagnostic action into credential exposure.

Worked case: three requests and a 120-second lifetime

Consider three explicitly fictional CIBA requests from a school’s approved system, each with a separate auth_req_id and expires_in=120 seconds. Request A uses poll mode with a five-second interval; request B is associated with a separate ping-enabled client; request C uses a third registered push client. These are three different client configurations, not three interchangeable methods inside one client’s registration.

For A, suppose the authentication request is acknowledged at second 0, polls at 5 and 10 receive authorization_pending, a poll at 15 receives slow_down, and a later permissible poll is sent at second 25 after increasing the interval to at least ten seconds. A successful result at that time counts as one verified completed transaction only after the returned tokens are validated. Two pending responses and one slow_down do not count as three successful authentications.

For B, the OP sends one authenticated ping, the client verifies the bearer token tied to its auth_req_id and retrieves valid tokens from the token endpoint. Count B as successful after both steps, not after the ping alone. If retrieval fails, B remains incomplete despite an HTTP success response from the callback.

For C, the OP delivers a push result, but the client’s validation finds that the auth_req_id binding claim does not match the pending request. The correct outcome is rejection. If a dashboard counts deliveries, it might report three successful transmissions. A verified authorisation ledger would instead show two of three completed requests, or 2/3≈66.67%, and one of three rejected, or 1/3≈33.33%.

This denominator is three independently requested transactions, not the number of HTTP calls. The example is arithmetic, not a real incident. It shows why the status of a delivery mechanism and the status of the user’s authenticated authority must be reported separately.

Expiry, slow_down and the cost of guessing after a timeout

An auth_req_id has a stated finite lifetime. A client must respect the expiration and terminal errors rather than turning a pending transaction into an infinite background loop. If the OP reports expired_token, a new user-initiated authentication request may be necessary. Creating a new request without user context can trigger unexpected prompts and erode trust.

A lost network response creates uncertainty. The OP may have accepted an authentication request while the client never received the acknowledgement. Repeatedly submitting fresh requests could produce multiple notifications on the person’s phone. Reconcile any available original transaction record and use bounded error handling instead of assuming no server-side action occurred.

Slow polling also has resource implications. If 100 requests each poll once every five seconds while pending, the rough load is 100/5=20 polls per second under ideal steady conditions, before latency and different expiry times. A three-second interval would increase the theoretical rate to about 33.33 polls per second. The client must still obey the OP’s minimum interval, so these calculations are capacity illustrations, not suggestions to poll faster.

Unnecessary overlapping calls waste resources and violate CIBA’s no-overlapping-polls requirement for the same auth_req_id. Track an in-flight request per transaction. Respect a response that extends or restricts the wait, and never treat a timeout as an implicit approval.

An agent’s status should be explicit: accepted, pending consent, awaiting callback, token result received but not validated, verified or failed. This makes uncertainty visible and keeps the user’s next step clear.

Account hints and notifications are privacy boundaries

Authentication requests often involve account hints such as email addresses, phone numbers or subject identifiers. They are sensitive even when not passwords. The system should collect only what the OP and user journey require, transmit it to the intended provider and avoid scattering it into analytics and third-party logs.

A malicious party who can initiate CIBA requests for arbitrary known accounts may generate repeated authentication prompts, creating harassment, confusion or approval fatigue. Rate controls, appropriate account confirmation and a provider-side consent interface help reduce that risk. The original specification includes security and privacy considerations; implementers should read them rather than focusing only on successful token flows.

A binding message can help the user compare devices but may create a privacy leak if it includes document titles, private account numbers or other personal details displayed on a locked screen. Prefer a brief transaction-specific cue and a clear description of the requesting application. The most secure design depends on the OP’s presentation and the threat model.

Separate authentication evidence from operational logs. A timestamp and transaction ID may be needed for reconciliation, but raw access tokens and push payloads should not be retained in ordinary support transcripts. Deletion and retention policies must match applicable obligations rather than being chosen only for debugging convenience.

The fact that an AI assistant can format a convincing explanation of a CIBA prompt does not mean it should persuade a user to approve it. A human should be able to decline unfamiliar requests without the system retaliating or quietly rerouting around the denial.

CIBA, OAuth Device Authorization and OIDC logout do different jobs

CIBA is often confused with the OAuth 2.0 Device Authorization Grant, defined in RFC 8628. Device Authorization is designed for input-constrained devices and commonly asks the user to visit an authorisation URL and enter or confirm a user code. CIBA instead begins with an identity hint and a backchannel authentication request, with the OP initiating the out-of-band user interaction on an authentication device.

The site’s verified OAuth Device Authorization guide explores user codes, polling and phishing boundaries for that different flow. Shared concepts do not make the protocols interchangeable. Read the actual grant type, required fields and registered mode rather than reusing an implementation because it uses polling.

OIDC back-channel logout solves an opposite problem: ending existing RP sessions based on a signed Logout Token. The back-channel logout guide covers issuer, audience, sub/sid scope and session invalidation. CIBA seeks new authenticated authority; logout seeks to terminate an existing session. Similar backchannel terminology must not confuse these directions.

CIBA push also differs from an ordinary unsigned webhook. A callback requires a registered HTTPS endpoint, appropriate bearer-token checking and token-to-transaction cryptographic binding. A service that accepts a generic JSON message as proof of a user’s consent is not implementing the safeguards promised by the protocol.

Choose the flow that matches the user journey and the supported provider capabilities. Do not describe CIBA as a universal replacement for browser-based OpenID Connect or claim that every mobile authenticator implements it.

Ten implementation failures and their first repairs

Failure one is treating an auth_req_id acknowledgement as a token result. Repair by maintaining separate accepted, pending and verified states. Failure two is accepting a hint as proof of identity or consent. Repair by relying on the OP’s authenticated user interaction and validated completed token result.

Failure three is polling faster than the OP’s interval or failing to increase the interval after slow_down. Repair with per-request scheduling and explicit error handling. Failure four is making overlapping polls for one auth_req_id. Repair by storing an in-flight flag or otherwise serialising requests for that identifier.

Failure five is accepting a ping without checking the client_notification_token and its association with the request. Failure six is treating a ping as token delivery. Repair by authenticating the callback and separately retrieving and validating the result. Failure seven is accepting push tokens without checking the ID Token’s issuer, audience, signature and required binding hashes.

Failure eight is sending credential-bearing callbacks through redirects or recording raw tokens in debugging logs. Repair with registered HTTPS endpoints and narrow secret handling. Failure nine is switching a push client to polling as an improvised recovery action. Repair by respecting its single registered delivery mode and using a protocol-compliant recovery procedure.

Failure ten is automatically reissuing new requests after denial, expiry or an unknown outcome, causing prompt floods. Repair by keeping original transaction identity, bounded retries and clear user-visible status. These are not interchangeable bugs; diagnose exactly which trust boundary broke before changing code.

Transfer exercise: a shared tablet and a private phone

Change the original office example. A student requests access to a read-only learning document on a school tablet, while a parent is the authorised adult who must approve it on a private phone. The student enters a permitted account hint at the tablet. The OP sends an authentication request to the correct adult’s authentication device, and the adult compares the displayed transaction context with what was expected.

Suppose the tablet displays binding message Q7M2, but the parent’s phone shows Q7N2 for an unrelated request. The difference is a warning, not a minor formatting issue to be waved away. The adult should decline or investigate. The client’s assistant must not say that the two codes are close enough or suggest a shortcut around the provider’s interaction.

Now suppose the correct request is approved, but the resulting access token grants only document-read scope. The assistant may retrieve the permitted material after complete validation, but it cannot use that token to edit grades or release other students’ records. The scope and business authorisation remain separate checks after CIBA authentication succeeds.

Finally imagine the token request times out after the adult approves. The tablet should report that final verification remains uncertain and reconcile by the correct registered mode; it should not create a new privileged session from the approval tap alone or prompt the adult repeatedly without context.

This changed-context exercise highlights a key invariant: a separate-device approval helps only when request identity, human understanding, final cryptographic token validation and downstream permissions remain bound to one authorised purpose.

CIBA is conditional capability, not automatic universal trust

CIBA requires participating OP and client support, registration and a suitable user journey. A normal OpenID Connect implementation may not offer it. Push and ping require reachable registered notification endpoints, while poll mode requires controlled token requests. Each mode brings different operational costs and failure modes.

A technically valid authentication result does not guarantee the user intended a particular later action. The scope and local authorisation policy still limit what an agent may do. A push message that arrives correctly can be followed by a business-layer rejection when a user lacks permission for the requested document or action.

Security is not achieved solely by checking the cryptographic signature of one token. Issuer, audience, transaction binding, client identity, endpoint control, expiration, replay considerations and token storage all matter. Systems also need attention to unsolicited prompts, human confusion and privacy.

The artificial-superintelligence label in the series describes the engineering trajectory of capable agents; the subject here is ordinary contemporary authentication. No claim of existing ASI or a new autonomous identity authority is made.

Read the latest provider documentation and applicable security profile before implementing. This article’s numerical examples are educational and are not evidence of a tested production deployment.

Frequently asked questions

What is CIBA? It is an OpenID Connect authentication flow that lets a client initiate an authentication request directly with an OP while the user authenticates on a separate device.

Does the first device need to redirect to a browser login? Not for the CIBA exchange as defined, which uses backchannel client-to-provider communication and an authentication-device interaction.

Can an email hint sign a user in by itself? No. A supported hint identifies the target; authentication and consent must still be completed through the OP.

What is auth_req_id? It is an opaque identifier for a pending authentication request, not a bearer access token or evidence of user approval.

What happens in poll mode? The client requests the result from the token endpoint at allowed intervals until a terminal result or expiry.

What happens in ping mode? The OP notifies the registered client endpoint, and the client then retrieves the result from the token endpoint.

What happens in push mode? The OP delivers the tokens directly to the registered notification endpoint with required authentication and token-binding checks.

Can a client switch between modes after a timeout? Not as an improvised fallback: the registered delivery mode governs the interaction.

What is a binding message? It is a human-readable interlocking cue to help a person recognise the same transaction across devices.

What does slow_down mean? In a pending polling flow it requires increasing the polling interval by at least five seconds.

Does a successful callback mean the agent has permission to do anything? No. Token validation, scopes, local access controls and task-specific consent still apply.

Reader pathways and primary technical documents

If you build a CIBA client, begin with the registered issuer and delivery mode, then test each request field and auth_req_id state. Simulate pending, denial, expiry, slow_down, callback spoofing, token-binding mismatches and an uncertain timeout. Keep the user’s transaction purpose visible.

If you operate an identity provider, verify that requests are from authorised clients and that unsolicited prompts are controlled. Provide clear context on the authentication device and send final results using the declared delivery mode. Protect callback data and enforce request lifetime consistently.

If you audit agent-assisted authentication, distinguish what the user intended, what the provider confirmed, what tokens were validated and what operations those tokens authorise. Report each boundary separately, with no invented claim that a prompt or transport receipt proves business completion.

The primary reference is OpenID Connect CIBA Core 1.0 Final, 1 September 2021. For the separate input-constrained device grant, consult IETF RFC 8628. Both URLs are official published specifications.

Related live reading includes Agent OAuth Device Authorization, OIDC Back-Channel Logout and the How Super Intelligence Works overview. These have different reader jobs and are not duplicate owners.

Discover more from eduKate Singapore

Subscribe now to keep reading and get access to the full archive.

Continue reading