Outils pour utilisateurs

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 :

Scopes et claims

This website uses cookies. By using the website, you agree with storing cookies on your computer. Also, you acknowledge that you have read and understand our Privacy Policy. If you do not agree, please leave the website.

Plus d’informations