Structure des données utilisateur

Les utilisateurs sont les entités principales du service d'identité. Dans Logto, ils incluent les données d'authentification de base basées sur le protocole OpenID Connect, ainsi que des données personnalisées.

Profil utilisateur

Chaque utilisateur possède un profil contenant toutes les informations utilisateur.

Il se compose des types de données suivants :

Données de base : il s'agit des informations de base du profil utilisateur. Elles stockent toutes les autres propriétés de l’utilisateur à l’exception des identities sociales et des custom_data, telles que l’identifiant utilisateur, le nom d’utilisateur, l’e-mail, le numéro de téléphone et la date de dernière connexion de l’utilisateur.
Identités sociales : stocke les informations utilisateur récupérées lors de la connexion sociale (c’est-à-dire la connexion avec un connecteur social), telles que Facebook, GitHub et WeChat.
Données personnalisées : stocke des informations utilisateur supplémentaires non listées dans les propriétés prédéfinies de l’utilisateur, telles que la couleur et la langue préférées de l’utilisateur.

Voici un exemple de données utilisateur récupérées lors d’une connexion à Facebook :

{
  "id": "iHXPuSb9eMzt",
  "username": null,
  "primaryEmail": null,
  "primaryPhone": null,
  "name": "John Doe",
  "avatar": "https://example.com/avatar.png",
  "customData": {
    "preferences": {
      "language": "en",
      "color": "#f236c9"
    }
  },
  "identities": {
    "facebook": {
      "userId": "106077000000000",
      "details": {
        "id": "106077000000000",
        "name": "John Doe",
        "email": "[email protected]",
        "avatar": "https://example.com/avatar.png"
      }
    }
  },
  "lastSignInAt": 1655799453171,
  "applicationId": "admin_console"
}

Vous pouvez interroger le profil utilisateur via Logto Console ou Logto Management API, comme GET /api/users/:userId.

Données de base

Passons en revue toutes les propriétés des données de base de l’utilisateur.

id

id est une clé unique générée automatiquement pour identifier l’utilisateur dans Logto.

username

username est utilisé pour la connexion avec username et mot de passe.

Sa valeur provient du nom d’utilisateur avec lequel l’utilisateur s’est inscrit pour la première fois. Elle peut être null. Sa valeur non nulle ne doit pas dépasser 128 caractères, ne contenir que des lettres, des chiffres et des underscores (_), et NE PAS commencer par un chiffre. Elle est sensible à la casse.

primary_email

primary_email est l’adresse e-mail de l’utilisateur, utilisée pour la connexion avec l’e-mail et le mot de passe / code de vérification.

Sa valeur provient généralement de l’adresse e-mail avec laquelle l’utilisateur s’est inscrit pour la première fois. Elle peut être null. Sa longueur maximale est de 128.

primary_phone

primary_phone est le numéro de téléphone de l’utilisateur, utilisé pour la connexion avec le numéro de téléphone et le mot de passe / code de vérification reçu par SMS.

Sa valeur provient généralement du numéro de téléphone avec lequel l’utilisateur s’est inscrit pour la première fois. Elle peut être null. Sa valeur non nulle doit contenir des chiffres précédés de l’indicatif téléphonique du pays (sans le signe plus +).

name

name est le nom complet de l’utilisateur. Sa longueur maximale est de 128.

avatar

avatar est l’URL pointant vers l’image de l’avatar de l’utilisateur. Sa longueur maximale est de 2048.

Si l’utilisateur s’inscrit avec un connecteur social comme Google ou Facebook, sa valeur peut être récupérée à partir des informations sociales de l’utilisateur.

remarque:

Cette propriété est mappée à la revendication picture dans la norme OpenID Connect.

profile

profile stocke les revendications standard OpenID Connect supplémentaires qui ne sont pas incluses dans les propriétés de l’utilisateur.

Sa définition de type peut être trouvée dans ce fichier. Voici une copie de la définition de type :

type UserProfile = Partial<{
  familyName: string;
  givenName: string;
  middleName: string;
  nickname: string;
  preferredUsername: string;
  profile: string;
  website: string;
  gender: string;
  birthdate: string;
  zoneinfo: string;
  locale: string;
  address: Partial<{
    formatted: string;
    streetAddress: string;
    locality: string;
    region: string;
    postalCode: string;
    country: string;
  }>;
}>;

remarque:

Partial signifie que toutes les propriétés sont optionnelles.

Une différence par rapport aux autres revendications standard est que les propriétés dans profile ne seront incluses dans le jeton d’identifiant (ID token) ou la réponse de l’endpoint userinfo que si leurs valeurs ne sont pas vides, tandis que les autres revendications standard retourneront null si les valeurs sont vides.

application_id

La valeur de application_id provient de l’application à laquelle l’utilisateur s’est connecté pour la première fois. Elle peut être null.

last_sign_in_at

last_sign_in_at est l’horodatage avec le fuseau horaire de la dernière connexion de l’utilisateur.

created_at

created_at est l’horodatage avec le fuseau horaire lors de l’inscription de l’utilisateur.

updated_at

updated_at est l’horodatage avec le fuseau horaire lors de la dernière mise à jour des informations du profil utilisateur.

has_password

has_password est une valeur booléenne qui indique si l’utilisateur possède un mot de passe. Vous pouvez consulter et gérer ce statut, y compris définir ou réinitialiser le mot de passe sur la page de détail de Console > Gestion des utilisateurs.

password_encrypted

password_encrypted est utilisé pour stocker le mot de passe chiffré de l’utilisateur.

Sa valeur provient du mot de passe avec lequel l’utilisateur s’est inscrit pour la première fois. Elle peut être null. Si sa valeur est non nulle, son contenu original avant chiffrement doit comporter au moins six caractères.

password_encryption_method

password_encryption_method est utilisé pour chiffrer le mot de passe de l’utilisateur. Sa valeur est initialisée lors de l’inscription de l’utilisateur avec un nom d’utilisateur et un mot de passe. Elle peut être null.

Logto utilise par défaut l’implémentation node-argon2 d’Argon2 comme méthode de chiffrement ; voir la référence pour plus de détails si cela vous intéresse.

Exemple de password_encrypted et password_encryption_method pour un utilisateur dont le mot de passe est 123456 :

{
  "password_encryption_method": "Argon2i",
  "password_encrypted": "$argon2i$v=19$m=4096,t=10,p=1$aZzrqpSX45DOo+9uEW6XVw$O4MdirF0mtuWWWz68eyNAt2u1FzzV3m3g00oIxmEr0U"
}

is_suspended

is_suspended est une valeur booléenne qui indique si un utilisateur est suspendu ou non. La valeur peut être gérée en appelant la Logto Management API ou en utilisant Logto Console.

Une fois qu’un utilisateur est suspendu, les jetons de rafraîchissement préalablement accordés seront immédiatement révoqués et l’utilisateur ne pourra plus être authentifié par Logto.

mfa_verification_factors

mfa_verification_factors est un tableau qui liste les méthodes d’authentification multi-facteurs (MFA) associées au compte de l’utilisateur. Les valeurs possibles incluent : Totp (OTP via application d’authentification), WebAuthn (Passkey), et BackupCode.

mfaVerificationFactors: ("Totp" | "WebAuthn" | "BackupCode")[];

identities contient les informations utilisateur récupérées lors de la connexion sociale (c’est-à-dire la connexion avec un connecteur social). Les identities de chaque utilisateur sont stockées dans un objet JSON individuel.

Les informations utilisateur varient selon le fournisseur d’identité sociale (c’est-à-dire la plateforme de réseau social), et incluent généralement les éléments suivants :

target du fournisseur d’identité, tel que "facebook" ou "google"
Identifiant unique de l’utilisateur pour ce fournisseur
Nom de l’utilisateur
E-mail vérifié de l’utilisateur
Avatar de l’utilisateur

Le compte de l’utilisateur peut être lié à plusieurs fournisseurs d’identité sociale via la connexion sociale ; les informations utilisateur correspondantes récupérées auprès de ces fournisseurs seront stockées dans l’objet identities.

Exemple d’identities pour un utilisateur connecté à la fois avec Google et Facebook :

{
  "facebook": {
    "userId": "5110888888888888",
    "details": {
      "id": "5110888888888888",
      "name": "John Doe",
      "email": "[email protected]",
      "avatar": "https://example.com/avatar.png"
    }
  },
  "google": {
    "userId": "111000000000000000000",
    "details": {
      "id": "111000000000000000000",
      "name": "John Doe",
      "email": "[email protected]",
      "avatar": "https://example.com/avatar.png"
    }
  }
}

Identités SSO

sso_identities contient les informations utilisateur récupérées lors du SSO d’entreprise (c’est-à-dire connexion Single Sign-On avec un connecteur d’entreprise). Les ssoIdentities de chaque utilisateur sont stockées dans un objet JSON individuel.

Les données synchronisées depuis le fournisseur d’identité SSO dépendent des portées configurées dans le connecteur d’entreprise à demander. Voici une copie de la définition de type TypeScript :

type SSOIdentity = {
  issuer: string;
  identityId: string;
  detail: JsonObject; // Voir https://github.com/withtyped/withtyped/blob/master/packages/server/src/types.ts#L12
};

Données personnalisées

custom_data stocke des informations utilisateur supplémentaires non listées dans les propriétés prédéfinies de l’utilisateur.

Vous pouvez utiliser custom_data pour faire les choses suivantes :

Enregistrer si des actions spécifiques ont été effectuées par l’utilisateur, comme avoir vu la page d’accueil.
Stocker des données spécifiques à l’application dans le profil utilisateur, telles que la langue et l’apparence préférées de l’utilisateur par application.
Maintenir d’autres données arbitraires liées à l’utilisateur.

Exemple de custom_data pour un utilisateur administrateur dans Logto :

{
  "adminConsolePreferences": {
    "language": "en",
    "appearanceMode": "system",
    "experienceNoticeConfirmed": true
  },
  "customDataFoo": {
    "foo": "foo"
  },
  "customDataBar": {
    "bar": "bar"
  }
}

Les custom_data de chaque utilisateur sont stockées dans un objet JSON individuel.

remarque:

NE METTEZ PAS de données sensibles dans custom_data.

Les données personnalisées peuvent être accessibles via les revendications personnalisées du jeton JWT après la connexion de l’utilisateur, et les jetons JWT sont encodés en base64 (non chiffrés) et fréquemment transmis sur les réseaux, ce qui rend toute donnée sensible facilement exposée.

Vous pouvez récupérer un profil utilisateur contenant custom_data via la Management API et l’envoyer aux applications frontend ou aux services backend externes. Par conséquent, mettre des informations sensibles dans custom_data peut entraîner des fuites de données.

Si vous souhaitez tout de même placer des informations sensibles dans custom_data, nous recommandons de les chiffrer au préalable. Chiffrez/déchiffrez-les uniquement dans une partie de confiance comme vos services backend, et évitez de le faire dans les applications frontend. Cela minimisera les pertes si les custom_data de vos utilisateurs sont divulguées par erreur.

Comment collecter et mettre à jour les données personnalisées utilisateur

Utilisez la fonctionnalité Collecter le profil utilisateur pour recueillir des données personnalisées lors de l’inscription de l’utilisateur.
Utilisez l’Account API pour implémenter le profil utilisateur ou les paramètres de compte côté utilisateur final.
- Utilisez GET /api/my-account pour récupérer toutes les données utilisateur.
- Utilisez PATCH /api/my-account pour mettre à jour les custom_data d’un utilisateur.
Utilisez la Management API pour la gestion des utilisateurs ou des flux personnalisés avancés :
- Utilisez GET /api/users/{userId} pour récupérer toutes les données utilisateur.
- Utilisez PATCH /api/users/{userId}/custom-data pour mettre à jour les custom_data d’un utilisateur.
Votre équipe support peut directement mettre à jour les custom_data utilisateur dans Console > Gestion des utilisateurs. En savoir plus sur la consultation et la mise à jour des profils utilisateur.

Mettez à jour avec précaution. La mise à jour des custom_data d’un utilisateur écrasera complètement son contenu original dans le stockage.

Par exemple, si votre entrée lors de l’appel de l’API de mise à jour custom_data ressemble à ceci (supposons que le custom_data original soit l’exemple de données précédent) :

{
  "customDataBaz": {
    "baz": "baz"
  }
}

alors la nouvelle valeur de custom_data après la mise à jour sera :

{
  "customDataBaz": {
    "baz": "baz"
  }
}

C’est-à-dire que la valeur du champ mis à jour n’a rien à voir avec la valeur précédente.

Référence des propriétés

Les colonnes suivantes de la table utilisateur en base de données (sauf password_encrypted et password_encryption_method) sont visibles sur le profil utilisateur, ce qui signifie que vous pouvez les interroger via la Management API.

Nom	Type	Description	Unique	Requis
id	string	Identifiant unique	✅	✅
username	string	Nom d’utilisateur pour la connexion	✅	❌
primary_email	string	E-mail principal	✅	❌
primary_phone	string	Numéro de téléphone principal	✅	❌
name	string	Nom complet	❌	❌
avatar	string	URL de l’avatar de l’utilisateur	❌	❌
profile	object	Profil utilisateur	❌	✅
identities	object	Infos utilisateur issues de la connexion sociale	❌	✅
custom_data	object	Infos supplémentaires dans les propriétés personnalisables	❌	✅
application_id	string	ID de l’application à laquelle l’utilisateur s’est inscrit	❌	✅
last_sign_in_at	date time	Horodatage de la dernière connexion	❌	✅
password_encrypted	string	Mot de passe chiffré	❌	❌
password_encryption_method	string	Méthode de chiffrement du mot de passe	❌	❌
is_suspended	bool	Marque de suspension de l’utilisateur	❌	✅
mfa_verifications	object[]	Facteurs de vérification MFA	❌	✅

Unique : Garantit l’unicité des valeurs saisies dans une propriété d’une table de base de données.
Requis : Garantit que les valeurs saisies dans une propriété d’une table de base de données ne peuvent PAS être null.

Hub sécurisé pour les données utilisateur en mouvement

Profil utilisateur​

Données de base​

id​

username​

primary_email​

primary_phone​

name​

avatar​

profile​

application_id​

last_sign_in_at​

created_at​

updated_at​

has_password​

password_encrypted​

password_encryption_method​

is_suspended​

mfa_verification_factors​

Identités sociales​

Identités SSO​

Données personnalisées​

Référence des propriétés​

Ressources associées​

Profil utilisateur

Données de base

id

username

primary_email

primary_phone

name

avatar

profile

application_id

last_sign_in_at

created_at

updated_at

has_password

password_encrypted

password_encryption_method

is_suspended

mfa_verification_factors

Identités sociales

Identités SSO

Données personnalisées

Référence des propriétés

Ressources associées