Différences

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

--- integration:flow_authorization_code [2026/04/06 23:37] – mkessabi
+++ integration:flow_authorization_code [2026/04/07 09:27] (Version actuelle) – [Points d’attention] mkessabi
@@ Ligne 41: / Ligne 41: @@
   * scope
   * state (recommandé)
+  * nonce (recommandé)
   * login_hint (optionnel)
@@ Ligne 50: / Ligne 51: @@
 &response_type=code
 &redirect_uri=https://monservice.fr/callback
-&scope=openid profile email
+&scope=openid+profile+email
 &state=abc123
+&nonce=xyz456
 </code>
@@ Ligne 64: / Ligne 66: @@
   * est redirigé vers LINLP
   * reçoit une notification sur son mobile
-  * valide via PIN ou biométrie
+  * valide via son code secret
+👉 Le consentement des données est demandé si nécessaire.
 -----
@@ Ligne 77: / Ligne 81: @@
 ⚠️ Le code :
-  * est temporaire
+  * est temporaire (durée courte)
   * est à usage unique
@@ Ligne 109: / Ligne 113: @@
   * access_token
-  * id_token (JWT)
+  * id_token (JWT signé)
   * expires_in
@@ Ligne 122: / Ligne 126: @@
 👉 Retour :
-  * données utilisateur
+  * données utilisateur (claims)
   * informations de contexte
+-----
+===== 🔐 Recommandation critique =====
+⚠️ Le partenaire doit impérativement **stocker le id_token**
+👉 Pourquoi ?
+  * il constitue la **preuve d’authentification de l’utilisateur**
+  * il est **signé par LINLP**
+  * il peut être **vérifié cryptographiquement à tout moment**
+  * il ne dépend pas de la disponibilité de LINLP
+👉 Cas d’usage :
+  * audit de connexion
+  * preuve légale
+  * contrôle a posteriori
+  * gestion de litiges
+💡 Contrairement à l’access_token, le **id_token doit être conservé côté partenaire**
 -----
@@ Ligne 166: / Ligne 192: @@
 ===== Bonnes pratiques =====
 ⚠️ Toujours utiliser un backend
-Ne jamais appeler `/token` depuis le frontend.
+  * Ne jamais appeler `/token` depuis le frontend.
 ⚠️ Vérifier le paramètre state
-Permet d’éviter les attaques CSRF.
+  * Permet d’éviter les attaques CSRF.
-⚠️ Gérer les expirations
+⚠️ Vérifier le nonce
-Les codes et tokens expirent rapidement.
+  * Permet d’éviter les attaques de rejeu.
-⚠️ Journaliser les erreurs
+⚠️ Vérifier la signature du id_token
-Indispensable pour le support et debug.
+  * Garantit l’intégrité des données.
+⚠️ Gérer les expirations
+  * Les codes et tokens expirent rapidement.
+⚠️ Journaliser les erreurs
+  * Indispensable pour le support et debug.
 -----
@@ Ligne 182: / Ligne 214: @@
 ===== Points d’attention =====
 ⚠️ redirect_uri doit être strictement identique
-Sinon rejet automatique.
+  * Sinon rejet automatique.
+⚠️ Les scopes doivent être déclarés en amont
+  * Impossible d’en ajouter dynamiquement.
-⚠️ Les scopes doivent être déclarés en amont
+⚠️ Le flow est synchrone côté utilisateur
-Impossible d’en ajouter dynamiquement.
+  * Prévoir une UX adaptée (chargement, attente).
-⚠️ Le flow est synchrone côté utilisateur
+⚠️ Les données retournées dépendent :
-Prévoir une UX adaptée (chargement, attente).
+  * des scopes demandés
+  * du paramétrage LINLP
+  * du consentement utilisateur
 -----
@@ Ligne 197: / Ligne 234: @@
   * Flow standard OpenID Connect
   * Basé sur redirection + échange sécurisé
+  * Retour de tokens dont le **id_token clé**
   * Recommandé pour tous les cas d’usage web et mobile