ACP Client-initiated Backchannel Authentication grant flow overview

Read an overview of the Client-initiated Backchannel Authentication (CIBA) grant flow implementation in Authorization Control Plane (ACP). Learn how it works in general and what its advantages are.

CIBA in a nutshell

Client-initiated Backchannel Authentication is an OpenID Connect decoupled flow. In CIBA, the client application that is responsible for making requests to ACP APIs and resource server APIs is decoupled from the authentication device which the end-user uses to authenticate themselves and to confirm their consent. It means that, with CIBA, a client application can be outside of the end user control. The client and the authentication device can be physically separated.

ACP CIBA simplified

CIBA flow is unlike the other OAuth and OIDC flows categorized as redirect flows. As the flow is decoupled, it gives the client application (a consumption device in CIBA) the possibility to act without the presence of the end-user. The flow may be initiated by a different person, for example, a customer service operator. In CIBA, there is no redirection of the end user, as they authenticate and give their consent through the use of the authentication device, for example, their mobile phone and an application installed on it.

CIBA use case example

John is an online customer service operator for a popular web application and he needs to perform some actions on behalf of the application’s end-user, Mark. The client application is registered within ACP and configured to use the CIBA flow. John uses their internal client application to access Mark’s users data. Such action requires Mark’s consent. ACP receives the request and communicates with the authentication device that Mark uses. Mark opens an external authenticator application installed on his mobile phone to authenticate himself and to give his consent. He agrees that the client application John uses is authorized to access his personal data. Now, the client application is able to receive an access token from ACP (by making a request to the token endpoint). to make requests to APIs stored on the resource server. In other words, with an access token, the client application is able to request Mark’s personal data, and, later on, provide it to John enabling him to solve Mark’s issues.

[mermaid-begin]
sequenceDiagram participant A as John participant B as Client Application participant C as ACP participant D as Authentication device participant E as Mark A->>B: Access B->>C: Request authorization C->>D: Delegate authorization D->>E: Display consent E->>D: Give consent D->>C: Pass result of consent C->>B: Backchannel response B->>C: Request token C->>B: Token