Informations de profil standard et scopes standards
La spécification de UserInfo dans le standard OpenID Connect figure ici : UserInfo Response
Dans l’état actuel du développement, OAuth Server by DnC fournit les déclarations (claims), autrement dit informations de profil, suivantes en fonction du scope (ou des scopes) :
| Scope | Informations de profil (claims) |
|---|---|
| profile | name, family_name, given_name, middle_name, nickname, profile, picture, website, gender, birthday, zoneinfo, locale, updated_at |
| email, verified | |
| address | address, street_address, locality, region, postal_code, country |
| phone | phone_number |
[dnc2]
Notes :
La spécification indique qu’il n’est pas garanti que la réponse UserInfo Endpoint corresponde à l’utilisateur identifié par l’élément sub du jeton d’identité (Token ID) [1]. Avant de considérer la réponse UserInfo comme valide, il convient de vérifier que la déclaration sub dans la réponse UserInfo correspond exactement à la déclaration sub du jeton d’identité (Token ID).
La déclaration sub est toujours incluse dans la réponse, par défaut, c’est à dire y compris en l’absence de Scope.
Lors de la certification OpenID Connect, nous avons constaté que la déclaration name est également exigée par défaut [2].
La déclaration name est une valeur composée avec les valeurs d’autres champs en fonction de règles locales [3]. De ce fait (mais aussi en application des règles de normalisation des bases de données relationnelles), ce champ n’est pas présent dans la table users, mais il est calculé par le contrôleur UserInfo. Dans l’état actuel du développement, la valeur de name est déterminée comme suit :
Informations de profil étendu
La définition standard des couples scope-claims n’est pas satisfaisante pour deux raisons principales :
le scope profile appelle trop d’informations, mélangeant des information essentielles et légitimement acceptables par l’utilisateur final avec des informations secondaires et plus intimes, telles que gender et birthdate.
à l’inverse, plus d’informations sur l’utilisateur devraient être disponibles.
La norme permettant de définir des scope et des claims additionnels, une implémentation spécifique d’OAuth Server by DnC pourrait exposer de nouveaux couples scope-claims mieux appropriés.
Voici par exemple des scopes permettant de définir des employés d’une entreprise :
| Scope | Informations de profil (claims) |
|---|---|
| job | job_title, job_street_address, job_locality, job_region, job_postal_code, job_country, job_phone, job_phone2, job_mobile, job_fax, job_email, job_website |
| firm | firm_name, firm_street_address, firm_locality, firm_region, firm_postal_code, firm_country, firm_phone, firm_phone2, firm_mobile, firm_fax, firm_email, firm_website |
| trading | legalidentity, siret, rcs, vat_id, terms, rights |
Voici un autre exemple permettant à une application eCommerce d’authentifier ses clients :
| Scope | Informations de profil (claims) |
|---|---|
| delivery | delivery_fullname, delivery_street_address, delivery_locality, delivery_region, delivery_postal_code, delivery_country, delivery_phone, delivery_infos |
| billing | billing_fullname, billing_street_address, billing_locality, billing_region, billing_postal_code, billing_country, billing_phone, billing_vat_id |
| bank | bank_name, bank_full_address, bank_bic, bank_iban |
Comment étendre les informations de profil ?
Il faut distinguer deux configurations du serveur d’authentification :
le serveur est conçu pour des applications variées et non connues à l’avance (ce peut être un SaaS ouvert à la configuration d’applications par des administrateurs publics), et dans ce cas il parait souhaitable de le conserver conforme au standard OIDC. L’extension des informations de profil devrait alors se faire à l’aide de Web services distincts, propres aux applications.
le serveur est un serveur privé mis en œuvre dans le cadre d’un domaine d’entreprise pour des applications connues (c’est le cas des serveurs d’authentification de G..., F..., Wordpress avec le jeton blog etc.). Dans ce cas, la meilleure solution pour la sécurité (et notamment pour appliquer le RGPD) consiste à compléter la table users de la base de données et à définir des scopes particuliers avec la liste d’informations qui leur est rattachée.
Dans le deuxième cas, une bonne pratique serait de conserver la réponse UserInfo conforme au standard lorsque l’on interroge le point d’extrémité UserInfo, et de créer un point d’extrémité spécifique, par exemple UserInfoExt pour les informations de profil étendues, ainsi qu’une table particulière dans la base de données. Cette pratique permettra de conserver le serveur conforme au standard et de mieux gérer le code ainsi que les données.
RSS 2.0