Lors d’une authentification via LINLP, plusieurs éléments sont retournés :
👉 Cette page explique leur rôle et leur utilisation.
| Élément | Rôle |
|---|---|
| id_token | Contient les données d’identité (JWT signé) |
| access_token | Permet d’appeler les APIs |
| /userinfo | Permet de récupérer les données utilisateur |
⚠️ Le id_token doit être conservé par le partenaire.
👉 Il constitue :
👉 En effet :
💡 Cela permet :
Le id_token est un JSON Web Token signé contenant :
Un JWT est composé de 3 parties :
HEADER.PAYLOAD.SIGNATURE
{
"alg": "RS256",
"typ": "JWT",
"kid": "abc123"
}
{
"sub": "075ccece-6699-4c08-80ca-27a6af136b68",
"given_name": "Jean Pierre",
"family_name": "Dupont",
"preferred_username": "Martin",
"birthdate": "1990-05-10",
"email": "jean.dupont@mail.com",
"iat": 1710000000,
"exp": 1710003600,
"iss": "https://authent.lidentitenumerique.laposte.fr",
"aud": "client_id"
}
⚠️ Le payload est lisible Un JWT n’est pas chiffré, seulement signé.
⚠️ Ne jamais faire confiance sans vérification Toujours vérifier la signature.
Le partenaire doit :
Le access_token :
👉 Il ne doit pas être utilisé directement pour lire les données.
Permet de récupérer les données utilisateur via API :
GET /userinfo Authorization: Bearer access_token
{
"sub": "075ccece-6699-4c08-80ca-27a6af136b68",
"given_name": "Jean Pierre",
"family_name": "Dupont",
"email": "jean.dupont@mail.com"
}
| Critère | id_token | /userinfo |
|---|---|---|
| Format | JWT | JSON |
| Signature | Oui | Non |
| Utilisation | Authentification | Données utilisateur |
⚠️ Conserver le id_token Il constitue une preuve d’authentification vérifiable.
⚠️ Toujours vérifier le JWT Signature + expiration obligatoires.
⚠️ Ne pas exposer les tokens Jamais côté frontend non sécurisé.
⚠️ Utiliser HTTPS uniquement Transport sécurisé obligatoire.
⚠️ Le access_token est sensible À protéger comme un mot de passe.
👉 Tester l’intégration :