Client Initiated Backchannel Authentication (CIBA)

Overview of CIBA

Typical OpenID Connect flows rely on browser redirects or require user interaction with the client. However, the Client Initiated Backchannel Authentication (CIBA) specification extends OpenID Connect to define a decoupled flow where authentication can be initiated on one device and carried out at another. With CIBA, there is no requirement for user interaction on the client initiating the flow, and there are no HTTP redirects through the user's browser. Instead, CIBA enables direct communication between the Relying Party (client) and the OpenID provider (Authorization Server). In this way, the client can obtain tokens from the Authorization Server for a given user at one device after the same user authenticated and granted consent through another device.

CIBA opens new possibilities. For example, a call center agent may ask a caller to authenticate via a decoupled login. Using OpenID Connect in the background, the agent could access claims such as address or email after successful authentication. CIBA also proves helpful in financial services. For example, it could assist a user who wants to authorize a contactless transaction at a point of sale terminal with a smartphone.

Although such use cases may already be implemented somehow, with CIBA, they follow a standardized flow and use widely adopted standards such as OpenID Connect. In particular, CIBA helps to comply with legal frameworks by defining a protocol that can be used to implement a decoupled approach for Strong Customer Authentication as described in PSD2.

Decoupled Flow

The CIBA specification defines two devices:

• Consumption Device: The device that helps the user consume a service.
• Authentication Device: The device on which the user will authenticate and grant consent.

In addition, there are two new endpoints, one at the Authorization Server and, optionally, one at the client:

• Backchannel Authentication Endpoint
• Backchannel Client Notification Endpoint

The client calls the Backchannel Authentication Endpoint when initiating the decoupled authentication. The client may publish a Backchannel Client Notification Endpoint to which the Authorization Server will post a callback if the token delivery mode requires it. Both endpoints must support TLS.

1. The flow starts with an authentication request. The client posts an authentication request directly to the Backchannel Authentication Endpoint at the Authorization Server. The request includes a hint for the Authorization Server to identify the user that is requested to authenticate. The Authorization Server returns immediately with an Authentication Request Acknowledgment, including a unique identifier auth_req_id for the initiated authentication transaction. This identifier is critical for request-response validation in further communications during the flow.

2. The Authorization Server initiates the user authentication with the authentication device. It is up to the Authorization Server to select an appropriate channel for the decoupled authentication.

3. The user enters the credentials and approves the request on the authentication device.

4. When the user is finished, it is time to notify the client of the result and deliver the tokens. The client can use three modes to retrieve tokens from the Authorization Server token endpoint:

   • Poll: The client regularly checks for tokens.
   • Ping: The client fetches the tokens from the token endpoint upon receiving a notification from the Authorization Server.
   • Push: The Authorization Server will deliver the tokens to the Client Notification Endpoint.

Token Delivery

As part of the registration, the client specifies a token delivery mode. A client must only specify one delivery mode, and the Authorization Server must obey this setting. However, clients that register to use the Ping mode may poll for tokens as well.

CIBA specifies a new decoupled grant type. Clients running a CIBA flow use urn:openid:params:grant-type:ciba as a grant type in the token request to specify that the request is part of a CIBA flow. Clients must authenticate during the token request using any of the client authentication methods defined in OpenID Connect or extensions to it (see also Authentication Request). Defining the authentication method is part of the client registration.

Poll Mode

In Poll mode, the client polls the Authorization Server's token endpoint regularly to check for tokens for a given transaction id (3a). It must respect the minimum wait time provided by the Authorization Server as part of the Authentication Request Acknowledgement (1b). Clients should be prepared to wait at least 30 seconds for a response. This is the timeout recommended by RFC 6202 - Best Practices for Long Polling. That is to say, the Authorization Server may implement long polling. When using long polling, the Authorization Server only responds to the token request when the authentication result has become available or a timeout has occurred.

Suppose the polling interval passes without receiving a message from the Authorization Server. In that case, the client must not send two overlapping requests for the same transaction ID while waiting for the response as part of the long polling mechanism. Finally, the Authorization Server responds with an ID token and access token (and optionally a refresh token) if available (3b). It will return an error if the authorization request is still pending or if the user authentication failed.

Ping Mode

When using Ping mode, the client registers with a Client Notification Endpoint. This is the endpoint where the Authorization Server will post a notification message containing the transaction ID for which an authentication result is ready (3). The client will then fetch the tokens from the Token Endpoint (4a).

Push Mode

A client registered in Push mode will wait for a Push Callback from the Authorization Server, which is basically a token response (3a). After the user was authenticated using a decoupled login and has authorized the request, the Authorization Server will post an ID Token, an Access Token, and, optionally, a Refresh Token to the Client Notification Endpoint.

Authentication Request

When initiating the authentication with an authentication request, the client must provide a hint for the Authorization Server to identify the user for whom the authentication is requested. This is because the Authorization Server does not interact with the user through the consumption device but in a decoupled authentication flow. Thus, it must be able to "contact the user". The hint may be an ID token that was previously issued to the client by the Authorization Server, another proprietary token, or a simple string.

The client must authenticate to the Authorization Server as part of the authentication request. The authentication method is set during client registration and may be any client authentication method defined by OpenID Connect or extensions. CIBA recommends using client authentication methods based on public-key mechanisms over shared secrets, such as JWT assertions or Mutual TLS.

Authentication Request Acknowledgement

Upon successful authentication of the client and validation of the authentication request, the Authorization Server will respond with a unique identifier auth_req_id and a lifetime expires_in for the transaction. The client stores the identifier for validating callbacks and when making token requests. When a client calls the token endpoint with an expired auth_req_id, the Authorization Server will return an error. Likewise, the client can omit identifiers that have expired, if no token or notification was delivered in time.

If the client is registered to use Poll (or Ping) mode, the Authorization Server may add an interval to its response. This interval specifies the minimum number of seconds a client must wait between two polling requests to the token endpoint. When omitted, the default value is 5 seconds.

User Code

User codes add a mechanism to protect the user from unsolicited authentication requests popping up at the authentication device. The user code is a secret that is only known to the user and that can be verified by the Authorization Server. When supported by the Authorization Server, the client will obtain a secret code from the user before starting a CIBA flow. In this way, malicious clients or malicious end-users who have a login hint cannot start unsolicited CIBA flows.

Do not confuse user codes with the user password entered during authentication. The user code is like a pin code that the user enters at the consumption device to authorize the client to initiate the decoupled authentication flow. The client must not store the user code.

An Authorization Server may or may not support user codes. Even if the mechanism is supported, whether or not the Authorization Server enforces it will depend on the context. In the call center use case mentioned above, the requirement of a user code may prove impractical. There may also be users who have not configured any user code and would be excluded from consuming the service if user codes were enforced. The Authorization Server should offer a method for the user to register and change the user code. A client may not request any user code from the user until it receives an error from the Authorization Server indicating otherwise. The client can then ask the user for input.

Signed Authentication Requests

The CIBA specification supports signed authentication requests. All request parameters are encoded as claims of a signed JWT, with the parameter name as claim name and the values represented as JSON strings. No request parameters must be sent outside the JWT except for parameters needed for client authentication, such as client_id for mutual TLS authentication or client_assertion and client_assertion_type when using JWT assertions for client authentication. The signed JWT and the client authentication parameters are then added to the HTTP post request to the Backchannel Authentication Endpoint.

Summary

The Client Initiated Backchannel Authentication specification defines a decoupled authentication flow where a client can initiate authentication at a consumption device without user interaction. The user authenticates off-the-band on a different device; the authentication device. There are three different modes to deliver tokens to the client after successful authentication: Poll, Ping, and Push. A new grant type for the decoupled grant, urn:openid:params:grant-type:ciba, was introduced for the token request.