Ceci est une ancienne révision du document !

Scopes et claims

Objectif

Les données retournées par L’Identité Numérique La Poste sont définies via les scopes OpenID Connect.

👉 Un scope correspond à un ensemble de données (claims) que le partenaire demande lors de l’authentification.

Principe

Lors de l’appel `/authorize`, le partenaire précise les données souhaitées :

scope=openid+profile+email+phone

👉 LINLP retourne la donnée uniquement si les 3 conditions sont respectées :

la donnée est demandée ou préconfigurée par défaut
la donnée est autorisée dans le paramétrage LINLP
la donnée est consentie par l’utilisateur

Notions clés

Terme	Description
Scope	Groupe de données
Claim	Donnée individuelle
id_token	Contient des claims
/userinfo	Retourne des claims

Scopes disponibles

Scope openid

Claim	Description	Format
sub	Identifiant unique utilisateur	UUID

Scope profile

Claim	Description	Format
given_name	Prénoms	String
family_name	Nom de naissance	String
preferred_username	Nom d’usage	String
gender	Sexe (Male / Female)	String

Scope birth

Claim	Description	Format
birthdate	Date de naissance	YYYY-MM-DD
birthplace	Code INSEE commune	String (5)
birthdepartment	Département	String
birthcountry	Pays de naissance	String (5)
birthplacelabel	Libellé de la commune	String
birthcountrylabel	Libellé du pays	String
birthcountry_iso	Pays (format ISO)	JSON

Scope email

Claim	Description	Format
email	Adresse email	email
email_verified	Email vérifié	boolean

Scope phone

Claim	Description	Format
phone_number	Numéro de téléphone	+33XXXXXXXXX
phone_number_verified	Téléphone vérifié	boolean

Scope nationality

Claim	Description	Format
nationality	Nationalité	JSON {code, label}

Données complémentaires

Certaines données peuvent être retournées en complément des scopes :

Claim	Description	Format
ccu_id	Identifiant interne La Poste	String (13)
splitted_given_name	Prénoms séparés	JSON
majority	Statut majeur	boolean
digital_identity_creation_date	Date de création identité	datetime
digital_identity_expiration_date	Date d’expiration	datetime

Données structurées

Certaines données sont retournées sous forme d’objets JSON :

Nationalité

"nationality": {
  "code": "FRA",
  "label": "Française"
}

Téléphone structuré

"phone": {
  "country_prefix": "+33",
  "phone_number": "601020304"
}

Prénoms détaillés

"splitted_given_name": {
  "first_name": "Martin",
  "middle_name": "Didier Marc"
}

Exemple de réponse (/userinfo)

{
  "sub": "5577832670193",
  "given_name": "Claire Marie",
  "family_name": "Dupont",
  "birthdate": "1965-12-06",
  "email": "test@mail.com",
  "phone_number": "+33600000000"
}

Recommandation par cas d’usage

Cas d’usage	Scopes recommandés
Authentification simple	openid email
Création de compte	openid profile email
Vérification d’identité (KYC)	openid profile birth nationality
Sécurité renforcée	openid phone

Bonnes pratiques

⚠️ Demander uniquement les données nécessaires Respect du principe de minimisation.

⚠️ Anticiper les données absentes Certains champs peuvent être vides.

⚠️ Gérer les consentements L’utilisateur peut refuser certaines données.

⚠️ Ne pas dépendre d’un seul claim Toujours prévoir fallback.

Points d’attention

⚠️ Les scopes doivent être validés en amont Impossible de demander un scope non autorisé.

⚠️ Différence id_token vs userinfo Les données peuvent différer selon le endpoint.

⚠️ Les formats sont normalisés Respecter les formats (date, codes INSEE, etc.).

Bon à savoir

💡 Toutes les données :

sont certifiées par LINLP
sont transmises uniquement après consentement utilisateur
peuvent évoluer selon le paramétrage du partenaire

Résumé

Les données sont pilotées par les scopes
Les claims sont les données individuelles
Les données sont retournées via JWT ou API
L’utilisateur garde le contrôle via consentement

Étape suivante

👉 Comprendre les tokens :

JWT et userinfo