====== OpenID Connect ======

===== Objectif =====

L’Identité Numérique La Poste repose sur le protocole **OpenID Connect (OIDC)**.

Ce standard permet à un service partenaire de :
  * déléguer l’authentification utilisateur
  * récupérer des informations d’identité sécurisées
  * s’appuyer sur un mécanisme standard du marché

-----

===== Principe général =====

Le partenaire ne gère pas l’authentification directement.

👉 Il redirige l’utilisateur vers LINLP, qui :
  * authentifie l’utilisateur (2FA)
  * collecte son consentement
  * renvoie les informations demandées

-----

===== Vue d’ensemble du flow =====

Le flow standard est le suivant :

  - Appel du endpoint `/authorize`
  - Authentification utilisateur (mobile)
  - Redirection avec un **code d’autorisation**
  - Appel du endpoint `/token`
  - Récupération des tokens
  - Appel du endpoint `/userinfo`
  - Récupération des données utilisateur

-----

===== Endpoints principaux =====

^ Endpoint ^ Description ^
| /authorize | Authentification utilisateur |
| /token | Récupération des tokens |
| /userinfo | Récupération des données utilisateur |

-----

===== Étape 1 : /authorize =====

Le partenaire redirige l’utilisateur vers LINLP.

Paramètres principaux :
  * client_id
  * redirect_uri
  * response_type=code
  * scope

Exemple :

<code>
GET /authorize?response_type=code
&client_id=XXX
&redirect_uri=https://monservice.fr/callback
&scope=openid+profile+email
</code>

👉 L’utilisateur est alors authentifié via son application mobile.

-----

===== Étape 2 : récupération du code =====

Après authentification :

  * LINLP redirige vers `redirect_uri`
  * un paramètre `code` est ajouté

Exemple :

<code>
https://monservice.fr/callback?code=ABC123
</code>

⚠️ Ce code est temporaire et à usage unique.

-----

===== Étape 3 : /token =====

Le backend du partenaire échange le code contre des tokens.

<code>
POST /token
</code>

Paramètres :
  * grant_type=authorization_code
  * code
  * redirect_uri

👉 Cette étape doit être faite côté backend.

-----

===== Étape 4 : tokens retournés =====

LINLP retourne :

  * access_token → accès aux APIs
  * id_token → données utilisateur (JWT signé)

-----

===== Étape 5 : /userinfo =====

Le partenaire récupère les données utilisateur :

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

👉 Les données retournées dépendent des scopes demandés.

-----

===== Tokens =====

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

Le **id_token** contient :

  * les données d’identité
  * des informations de session
  * une signature garantissant l’intégrité

👉 Il doit être vérifié avec la clé publique LINLP.

-----

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

Le **access_token** permet :

  * d’appeler l’API `/userinfo`
  * d’accéder aux données utilisateur

-----

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

⚠️ Backend obligatoire  
Ne jamais exposer `client_secret` côté frontend.

⚠️ Pas d’iframe  
La page `/authorize` doit être appelée via redirection.

⚠️ Vérification des tokens  
Toujours vérifier la signature du JWT.

⚠️ Stockage sécurisé  
Les tokens doivent être stockés de manière sécurisée.

-----

===== Environnements =====

^ Environnement ^ URL ^
| Sandbox | https://authent.pprod.lidentitenumerique.laposte.fr |
| Production | https://authent.lidentitenumerique.laposte.fr |

-----

===== À retenir =====

  * LINLP utilise OpenID Connect
  * Le flow principal est **authorization_code**
  * Toute l’authentification est externalisée
  * Les données sont récupérées via tokens sécurisés

-----

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

👉 Implémenter le flow complet :

[[integration:flow_authorization_code|Flow Authorization Code]]