CIBA Flow (Client Initiated Backchannel Authentication)

The CIBA flow allows user authentication to be triggered without redirecting the user to the LINLP authentication screen.

👉 It is used to:

• trigger a validation request on the mobile device
• authenticate an already known user
• perform strong validation (e.g. payment, sensitive action)

Unlike the standard flow:

• no browser redirection
• the request is initiated server-side
• validation happens directly on the smartphone

👉 The server triggers a request → the user validates on their phone.

⚠️ This flow requires the user to be known:

• LINLP technical identifier (`sub`)
• or QR code generated from the LINLP application

👉 This identifier is generally obtained during a first login through the Authorization Code flow.

Backend call:

POST /ext/ciba/auth

Parameters:

• client_id
• client_secret
• scope
• login_hint

Example:

grant_type=client_credentials
client_id=XXX
client_secret=XXX
scope=openid
login_hint=LIN|user_id

Response:

{
  "auth_req_id": "ABC123",
  "expires_in": 900,
  "interval": 5
}

The user receives a notification on their smartphone:

• authentication request
• validation through secret PIN code

The backend polls LINLP:

POST /token

Parameters:

• grant_type=urn:openid:params:grant-type:ciba
• auth_req_id
• client_id
• client_secret

👉 This request is repeated until validation is completed.

Once validated:

• tokens are returned
• `/userinfo` can be called

The CIBA flow is suitable for:

• validation of a sensitive transaction (payment, signature)
• authentication without a web journey
• background identity confirmation

Examples:

• bank transfer approval
• confirmation of a critical action
• mobile-first journeys

⚠️ Always handle polling Respect the `interval` field to avoid overload.

⚠️ Handle expirations `auth_req_id` expires quickly.

⚠️ User experience Inform the user that a mobile validation is expected.

⚠️ Security Never expose `client_secret`.

⚠️ Flow requiring a known user Use only when the user identifier is already known by the service.

⚠️ Real-time handling Implement timeout and retry logic on the backend.

• Flow without redirection
• Backend-driven
• Ideal for strong validation
• Complementary to the standard flow

👉 Understand returned data:

Scopes and Claims