====== JWT et userinfo ======

===== Objectif =====

Lors d’une authentification via LINLP, plusieurs éléments sont retournés :

  * un **id_token** (JWT)
  * un **access_token**
  * un endpoint **/userinfo**

👉 Cette page explique leur rôle et leur utilisation.

-----

===== Vue d’ensemble =====

^ É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 |

-----

===== ⚠️ Recommandation clé : conservation du id_token =====

⚠️ **Le id_token doit être conservé par le partenaire.**

👉 Il constitue :
  * la **preuve d’authentification** de l’utilisateur
  * une preuve **horodatée et signée**
  * un élément **vérifiable a posteriori**

👉 En effet :
  * le id_token est **signé par LINLP**
  * il peut être **vérifié à tout moment**
  * il ne dépend pas d’un appel API

💡 Cela permet :
  * audit de sécurité
  * traçabilité des connexions
  * preuve en cas de litige

-----

===== ID Token (JWT) =====

Le **id_token** est un JSON Web Token signé contenant :

  * les données utilisateur (claims)
  * des informations de session
  * une signature garantissant l’intégrité

-----

===== Structure d’un JWT =====

Un JWT est composé de 3 parties :

<code>
HEADER.PAYLOAD.SIGNATURE
</code>

-----

===== Exemple de JWT (décodé) =====

===== Header =====

<code>
{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "abc123"
}
</code>

-----

===== Payload =====

<code>
{
  "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"
}
</code>

-----

===== Points importants =====

⚠️ Le payload est lisible  
Un JWT n’est **pas chiffré**, seulement signé.

⚠️ Ne jamais faire confiance sans vérification  
Toujours vérifier la signature.

-----

===== Vérification du JWT =====

Le partenaire doit :

  * récupérer la clé publique LINLP (JWKS)
  * vérifier la signature
  * vérifier les champs :
    * `exp` (expiration)
    * `iss` (issuer)
    * `aud` (client_id)

-----

===== Access Token =====

Le **access_token** :

  * permet d’appeler `/userinfo`
  * représente l’autorisation d’accès

👉 Il ne doit pas être utilisé directement pour lire les données.

-----

===== Endpoint /userinfo =====

Permet de récupérer les données utilisateur via API :

<code>
GET /userinfo
Authorization: Bearer access_token
</code>

-----

===== Exemple de réponse =====

<code>
{
  "sub": "075ccece-6699-4c08-80ca-27a6af136b68",
  "given_name": "Jean Pierre",
  "family_name": "Dupont",
  "email": "jean.dupont@mail.com"
}
</code>

-----

===== id_token vs userinfo =====

^ Critère ^ id_token ^ /userinfo ^
| Format | JWT | JSON |
| Signature | Oui | Non |
| Utilisation | Authentification | Données utilisateur |

-----

===== Bonnes pratiques =====

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

-----

===== Points d’attention =====

⚠️ Le access_token est sensible  
À protéger comme un mot de passe.

-----

===== Résumé =====

  * id_token = identité + preuve d’authentification
  * access_token = accès aux APIs
  * /userinfo = récupération des données
  * Le id_token doit être conservé pour audit et preuve

-----

===== Étape suivante =====

👉 Tester l’intégration :

[[tests:creer_une_identite_de_test|Créer une identité de test]]