Flow CIBA (Client Initiated Backchannel Authentication)

Le flow CIBA permet de déclencher une authentification utilisateur sans redirection vers la mire d'authentification 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)

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.

⚠️ 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.

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
}

L’utilisateur reçoit une notification sur son smartphone :

• demande d’authentification
• validation via son code secret

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.

Une fois validé :

• récupération des tokens
• appel à `/userinfo`

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

⚠️ 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.

⚠️ Flow nécessitant de connaitre l'utilisateur À utiliser uniquement si l'id utilisateur est connu par le service.

⚠️ Gestion du temps réel Prévoir timeout et retry côté backend.

• Flow sans redirection
• Piloté côté backend
• Idéal pour validation forte
• Complémentaire au flow standard

👉 Comprendre les données retournées :

Scopes et claims