Différences

Ci-dessous, les différences entre deux révisions de la page.

--- integration:flow_ciba [2026/04/06 23:15] – créée mkessabi
+++ integration:flow_ciba [2026/04/06 23:46] (Version actuelle) – [Points d’attention] mkessabi
@@ Ligne 1: / Ligne 1: @@
-sc
+====== Flow CIBA (Client Initiated Backchannel Authentication) ======
+===== Objectif =====
+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)
+-----
+===== 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 :
+<code>
+POST /ext/ciba/auth
+</code>
+Paramètres :
+  * client_id
+  * client_secret
+  * scope
+  * login_hint
+Exemple :
+<code>
+grant_type=client_credentials
+client_id=XXX
+client_secret=XXX
+scope=openid
+login_hint=LIN|user_id
+</code>
+Réponse :
+<code>
+{
+  "auth_req_id": "ABC123",
+  "expires_in": 900,
+  "interval": 5
+}
+</code>
+-----
+===== Étape 2 : validation utilisateur =====
+L’utilisateur reçoit une notification sur son smartphone :
+  * demande d’authentification
+  * validation via son code secret
+-----
+===== Étape 3 : récupération des tokens =====
+Le backend interroge LINLP :
+<code>
+POST /token
+</code>
+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 | Validation forte | Validation forte |
+-----
+===== Points d’attention =====
+⚠️ 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.
+-----
+===== 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 :
+[[donnees:scopes_et_claims|Scopes et claims]]