Flow Authorization Code

Le flow Authorization Code est le mode d’intégration principal de L’Identité Numérique La Poste.

Il permet :

• d’authentifier un utilisateur
• de récupérer ses données d’identité
• de garantir un haut niveau de sécurité

Le flow repose sur un échange en plusieurs étapes :

1. Redirection utilisateur vers LINLP
2. Authentification (mobile)
3. Retour avec un code temporaire
4. Échange du code contre des tokens
5. Récupération des données utilisateur

👉 Ce flow est conforme au standard OpenID Connect.

Le partenaire redirige l’utilisateur vers LINLP.

GET /authorize

Paramètres principaux :

• client_id
• redirect_uri
• response_type=code
• scope
• state (recommandé)
• nonce (recommandé)
• login_hint (optionnel)

Exemple :

https://authent.pprod.lidentitenumerique.laposte.fr/auth/realms/partenaire/protocol/openid-connect/auth
?client_id=XXX
&response_type=code
&redirect_uri=https://monservice.fr/callback
&scope=openid+profile+email
&state=abc123
&nonce=xyz456

💡 `login_hint` permet de pré-remplir le téléphone utilisateur.

L’utilisateur :

• est redirigé vers LINLP
• reçoit une notification sur son mobile
• valide via son code secret

👉 Le consentement des données est demandé si nécessaire.

Après succès :

https://monservice.fr/callback?code=ABC123&state=abc123

⚠️ Le code :

• est temporaire (durée courte)
• est à usage unique

Le backend appelle :

POST /token

Exemple :

grant_type=authorization_code
code=ABC123
redirect_uri=https://monservice.fr/callback

👉 Authentification requise via :

• client_id
• client_secret

Réponse :

• access_token
• id_token (JWT signé)
• expires_in

GET /userinfo
Authorization: Bearer access_token

👉 Retour :

• données utilisateur (claims)
• informations de contexte

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

⚠️ Toujours utiliser un backend

• Ne jamais appeler `/token` depuis le frontend.

⚠️ Vérifier le paramètre state

• Permet d’éviter les attaques CSRF.

⚠️ Vérifier le nonce

• Permet d’éviter les attaques de rejeu.

⚠️ Vérifier la signature du id_token

• 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.

⚠️ redirect_uri doit être strictement identique

• Sinon rejet automatique.

⚠️ Les scopes doivent être déclarés en amont

• Impossible d’en ajouter dynamiquement.

⚠️ Le flow est synchrone côté utilisateur

• Prévoir une UX adaptée (chargement, attente).

⚠️ Les données retournées dépendent :

• des scopes demandés
• du paramétrage LINLP
• du consentement utilisateur

• 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

👉 Pour des cas avancés :

Flow CIBA