====== 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]]