Ceci est une ancienne révision du document !
Flow CIBA (Client Initiated Backchannel Authentication)
Objectif
Le flow CIBA permet de déclencher une authentification utilisateur sans redirection vers LINLP.
👉 Il est utilisé pour :
- déclencher une validation côté mobile
- authentifier un utilisateur déjà connu
- réaliser une validation forte (ex : paiement, action sensible)
Principe
Contrairement au flow classique :
- aucune redirection navigateur
- l’appel est initié côté backend
- la validation se fait directement sur le smartphone
👉 Le serveur déclenche une demande → l’utilisateur valide sur son téléphone.
Prérequis
⚠️ Ce flow nécessite de connaître l’utilisateur :
- identifiant technique LINLP (sub)
- ou QR code issu de l’application LINLP
👉 Cet identifiant est généralement obtenu lors d’un premier login via Authorization Code.
Étape 1 : déclenchement de la demande
Appel backend :
POST /ext/ciba/auth
Paramètres :
- client_id
- client_secret
- scope
- login_hint
Exemple :
grant_type=client_credentials client_id=XXX client_secret=XXX scope=openid login_hint=LIN|user_id
Réponse :
{
"auth_req_id": "ABC123",
"expires_in": 900,
"interval": 5
}
Étape 2 : validation utilisateur
L’utilisateur reçoit une notification sur son smartphone :
- demande d’authentification
- validation via PIN ou biométrie
Étape 3 : récupération des tokens
Le backend interroge LINLP :
POST /token
Paramètres :
- grant_type=urn:openid:params:grant-type:ciba
- auth_req_id
- client_id
- client_secret
👉 Cette requête est répétée jusqu’à validation.
Étape 4 : récupération des données
Une fois validé :
- récupération des tokens
- appel à `/userinfo`
Cas d’usage
Le flow CIBA est adapté pour :
- validation d’une opération sensible (paiement, signature)
- authentification sans parcours web
- confirmation d’identité en arrière-plan
Exemples :
- validation d’un virement bancaire
- confirmation d’une action critique
- parcours mobile-first
Cas d’erreur
| Cas | Description |
|---|---|
| Utilisateur non reconnu | erreur login_hint |
| Demande expirée | auth_req_id invalide |
| Refus utilisateur | pas de token retourné |
| Mauvais client_secret | erreur authentication |
Bonnes pratiques
⚠️ Toujours gérer le polling Respecter le champ `interval` pour éviter la surcharge.
⚠️ Gérer les expirations `auth_req_id` expire rapidement.
⚠️ UX utilisateur Informer l’utilisateur qu’une validation est attendue sur mobile.
⚠️ Sécurité Ne jamais exposer client_secret.
Différences avec Authorization Code
| Critère | Authorization Code | CIBA |
|---|---|---|
| Redirection utilisateur | Oui | Non |
| Initié par | Frontend | Backend |
| Connaissance utilisateur | Non obligatoire | Obligatoire |
| Cas d’usage | Login classique | Validation forte |
Points d’attention
⚠️ Flow plus complexe À utiliser uniquement si nécessaire.
⚠️ Dépendance mobile L’utilisateur doit avoir son téléphone disponible.
⚠️ Gestion du temps réel Prévoir timeout et retry côté backend.
Résumé
- Flow sans redirection
- Piloté côté backend
- Idéal pour validation forte
- Complémentaire au flow standard
Étape suivante
👉 Comprendre les données retournées :