Bonnes pratiques

Présenter les principales recommandations de sécurité pour intégrer L’Identité Numérique La Poste.

👉 Cette page complète la documentation technique OpenID Connect.

Le partenaire reste responsable :

• de son application
• de ses comptes utilisateurs
• de ses sessions
• de la protection des données reçues

LINLP sécurise l’authentification, mais l’intégration doit également être sécurisée côté partenaire.

⚠️ Obligatoire

Les appels sensibles doivent être réalisés côté serveur :

• `/token`
• `/userinfo`
• traitements des JWT

👉 Le `client_secret` ne doit jamais être exposé côté frontend.

⚠️ Tous les échanges doivent être protégés via HTTPS :

• redirections utilisateur
• appels API
• callbacks
• pages de connexion partenaire

Le partenaire doit vérifier les `id_token` :

• signature
• issuer (`iss`)
• audience (`aud`)
• expiration (`exp`)
• nonce (si utilisé)

👉 Voir : Validation des tokens

⚠️ Recommandation forte

Le `id_token` constitue :

• la preuve d’authentification utilisateur
• une preuve signée
• un élément vérifiable a posteriori

👉 Il doit être conservé selon les règles internes du partenaire.

Le partenaire doit protéger ses sessions applicatives :

• expiration de session
• cookies sécurisés
• invalidation après logout
• protection contre le vol de session

Limiter l’accès :

• aux credentials LINLP
• aux logs sensibles
• aux données utilisateurs
• aux consoles d’administration

Conserver des traces adaptées :

• date / heure authentification
• identifiant utilisateur (`sub`)
• identifiant de session
• id_token

⚠️ Respecter les règles RGPD et durées de conservation internes.

Appliquer le principe de minimisation :

• demander uniquement les scopes nécessaires
• stocker uniquement les données utiles
• protéger les données sensibles

• Sécuriser LINLP = sécuriser aussi l’intégration partenaire
• Backend + HTTPS indispensables
• Vérification JWT obligatoire
• id_token à conserver comme preuve

👉 Vérifier les JWT :

Validation des tokens