🇫🇷 Français | 🇬🇧 English
The CIBA flow allows user authentication to be triggered without redirecting the user to the LINLP authentication screen.
👉 It is used to:
Unlike the standard flow:
👉 The server triggers a request → the user validates on their phone.
⚠️ This flow requires the user to be known:
👉 This identifier is generally obtained during a first login through the Authorization Code flow.
Backend call:
POST /ext/ciba/auth
Parameters:
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:
The backend polls LINLP:
POST /token
Parameters:
👉 This request is repeated until validation is completed.
Once validated:
The CIBA flow is suitable for:
Examples:
| Case | Description |
|---|---|
| Unknown user | login_hint error |
| Expired request | invalid auth_req_id |
| User refusal | no token returned |
| Invalid client_secret | authentication error |
⚠️ 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`.
| Criteria | Authorization Code | CIBA |
|---|---|---|
| User redirection | Yes | No |
| Initiated by | Frontend | Backend |
| User knowledge required | Not mandatory | Mandatory |
| Main use case | Strong authentication | Strong authentication |
⚠️ 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.
👉 Understand returned data: