ACP Client-initiated Backchannel Authentication modes
Get familiar with the Client-initiated Backchannel Authentication (CIBA) modes: Poll and Ping. Learn the differences between modes and get information on how each mode works.
CIBA modes in a nutshell
The OpenID Connect Client-Initiated Backchannel Authentication Flow specification allows client applications to get results of its authentication using two ways:
-
POLL mode - where a client application sends continuous polling requests to ACP up to the point it receives a response with a success
-
PING mode - where ACP posts a notification (after the process on the authentication device is finished) to a client notification endpoint configured for this client application.
POLL mode
In the POLL mode, after a client application receives a response from the ACP’s backchannel authentication endpoint, the client repeats multiple token requests (hence the name, polling) to the ACP’s token endpoint.
When a clients waits for the result of the authentication, it repeats token requests. Until the
authentication process is not finished, ACP responds with the
authorization_pending
response or with the slow_down
response if there are too many requests
coming.
Continuous requests are sent until the client receives a token in the response or the
response contains an error different from authorization_pending
or slow_down
.
PING mode
The PING mode differs from the POLL mode, as there are no repeated requests to the token endpoint. Instead, once ACP receives an authentication result from the authentication device, it notifies the client application using the client notification endpoint configured for this application. After the client receives such a notification with a successful authentication result, it may request a token.
The client notification endpoint must be set for a client application during its registration. It must be a HTTPs URL and it must utlize the Transport Layer Security (TLS).
Token requests
Both in the POLL and in the PING mode a client application receives an access token as a result of a request to the token endpoint. Such a request must contain the following CIBA-specific parameters:
Parameter | Description |
---|---|
grant_type | This parameter provides information to ACP which grant type is used. Both for the PING and the POLL modes, the value must be set to urn:openid:params:grant-type:ciba . |
auth_req_id | Authentication request ID that is issued from the backchannel authentication endpoint. |
Client authentication
In all CIBA modes, the following client authentication methods are allowed:
none
client authentication cannot be used in the CIBA grant flow
as only confidential clients are able to use CIBA securely.