🇫🇷 Français | 🇬🇧 English
Validation des tokens
Objectif
Expliquer comment vérifier les tokens retournés par L’Identité Numérique La Poste.
👉 La validation des tokens est obligatoire pour garantir la sécurité de l’authentification.
Tokens concernés
Les principaux tokens retournés sont :
| Token | Usage |
|---|---|
| id_token | Preuve d’authentification |
| access_token | Accès aux APIs |
⚠️ Le `id_token` doit toujours être vérifié.
Vérifications obligatoires du id_token
Le partenaire doit contrôler les éléments suivants :
| Contrôle | Description |
|---|---|
| Signature | Vérifier que le token a bien été signé par LINLP |
| iss | Vérifier l’émetteur attendu |
| aud | Vérifier que le token est destiné à votre client |
| exp | Vérifier que le token n’est pas expiré |
| iat | Vérifier la cohérence temporelle |
| nonce | Vérifier si utilisé lors du flow |
Vérification de signature
LINLP publie ses clés publiques via le endpoint :
/auth/realms/partenaire/protocol/openid-connect/certs
👉 Format standard : JWKS
Le partenaire doit :
- récupérer la clé correspondant au `kid`
- vérifier la signature du JWT
Vérification du issuer
Le champ `iss` doit correspondre à l’environnement utilisé.
Exemple :
| Environnement | Valeur attendue |
|---|---|
| Sandbox | https://authent.pprod.lidentitenumerique.laposte.fr |
| Production | https://authent.lidentitenumerique.laposte.fr |
Vérification de l’audience
Le champ `aud` doit correspondre à votre :
client_id
👉 Si ce n’est pas le cas, le token doit être rejeté.
Vérification d’expiration
Le champ :
exp
représente la date limite de validité du token.
⚠️ Un token expiré ne doit pas être accepté.
Vérification du nonce
Si un `nonce` a été envoyé lors de `/authorize` :
👉 Le même `nonce` doit être présent dans le token.
Cela protège contre certaines attaques de rejeu.
Exemple de payload
{
"iss": "https://authent.lidentitenumerique.laposte.fr",
"aud": "client_abc",
"sub": "5577832670193",
"exp": 1712345678,
"iat": 1712342078
}
Recommandation sur le id_token
⚠️ Le `id_token` peut être conservé comme preuve d’authentification historique.
👉 Son expiration concerne l’usage temps réel, pas sa valeur de preuve.
Validation du access_token
Le `access_token` est utilisé pour appeler :
/userinfo
👉 Le partenaire doit le traiter comme un secret temporaire.
À retenir
- Le `id_token` doit être systématiquement vérifié
- Signature + iss + aud + exp = minimum requis
- Les clés publiques LINLP sont publiées via JWKS
- Le `id_token` doit être conservé comme preuve
Étape suivante
👉 Questions fréquentes :