Noms de champ des métadonnées et types de données

Décrit les noms de champ, les types de données, ainsi que les limitations et restrictions des métadonnées utilisateur, des métadonnées d’application et des métadonnées d’application (client).

Auth0 distingue trois types de métadonnées utilisés pour stocker certains types d’information.

Les métadonnées Auth0 ne constituent pas un espace de stockage sécurisé et ne doivent pas être utilisées pour stocker des renseignements sensibles, comme des secrets très sensibles et des renseignements personnels identifiables (PII), par exemple des numéros d’assurance sociale ou de carte de crédit. Auth0 recommande fortement à ses clients d’évaluer les données stockées dans les métadonnées et d’y conserver uniquement celles qui sont nécessaires à la gestion des identités et des accès.

Type de métadonnées	Nom du champ	Description
Informations sur l’utilisateur	user_metadata	Stocke des attributs utilisateur, comme des préférences, qui n’ont pas d’incidence sur les fonctionnalités de base. Ces données peuvent être modifiées par les utilisateurs connectés si vous créez un formulaire à l’aide de la Management API et ne doivent pas être utilisées comme espace de stockage sécurisé.
Informations d’accès	app_metadata	Stocke des renseignements comme les autorisations, le forfait Auth0 et des identifiants externes qui peuvent avoir une incidence sur l’accès de l’utilisateur aux fonctionnalités. Ces données ne peuvent pas être modifiées par les utilisateurs et des restrictions s’appliquent à ce qui peut être stocké dans ce champ.
Informations sur l’application	client_metadata dans l’objet Client, context.clientMetadata dans Rules, et event.client.metadata dans les Actions post-login.	Stocke des renseignements sur une application (ou client dans la terminologie OIDC OAuth2). Par exemple, l’URL de la page d’accueil de l’application (toute valeur qu’Auth0 ne définit pas dans les paramètres de l’application).

​

Noms de champ de métadonnées

​

Caractères acceptés

Les noms de champ ne doivent pas contenir les caractères . (point) ni $ (signe de dollar).

Par exemple, ceci n’est pas permis :

{
  "preference.color": "pink"
}

Mais vous pouvez l’étendre comme ceci :

{
    "preference": { 
        "color": "pink" 
    }
}

​

Noms de champ dynamiques

Les noms de champ doivent être statiques. Des noms de champ dynamiques réduisent l’efficacité de l’indexation et dégradent les performances des requêtes de recherche. Un schéma statique est plus facile à rechercher, à manipuler et à utiliser.

Au lieu de faire ceci :

{
    "participants": [
        "Alice": {
            "role": "sender"
         },
        "Bob": {
            "role": "receiver"
        }
    ]
}

Procédez comme suit :

{
    "participants": [
        {
            "name": "Alice",
            "role": "sender"
        },
        {
            "name" : "Bob",
            "role": "receiver"
        }
    ]
}

​

Conflit de noms

Évitez d’utiliser le même nom pour les champs app_metadata et les champs du profil racine. Le champ app_metadata est fusionné avec le profil racine dans Rules comme dans Actions, ce qui peut écraser les champs du profil racine.

Par exemple, si un utilisateur a un champ groups dans son profil racine (renvoyé par un SAML fournisseur d’identité) et un champ groups dans app_metadata, son profil pourrait ressembler à ceci :

{
    "user_id": "samlp|example-samlp-connection|[e-mail]",
    "groups": [
        "external-group-1",
        "external-group-2"
    ],
    "app_metadata": {
        "groups": [
            "internal-group-1",
            "internal-group-2"
        ]
    }
}

Lorsque vous lisez le champ groups de l’objet utilisateur dans une Rule, il renvoie : ["internal-group-1", "internal-group-2"].

​

Types de données pour les métadonnées

Les champs de métadonnées prennent en charge tous les types de données compatibles avec JSON :

• String
• Nombre
• Tableau
• Objet

Veillez à utiliser des types de données cohérents d’un utilisateur à l’autre. Par exemple, si vous stockez une valeur sous forme de chaîne pour un utilisateur (user.user_metadata.age = "23") et sous forme de nombre pour un autre utilisateur (user.user_metadata.age = 23), vous pourriez rencontrer des problèmes lors de la récupération des données.

​

Limitations et restrictions

​

Limites de débit

Lorsque vous mettez à jour des métadonnées lors de la connexion avec Rules ou Actions, vous êtes soumis aux limites de débit de votre locataire. Pour en savoir plus, consultez Limites de débit des points de terminaison de la Management API.

Vous ne devriez stocker dans les métadonnées que des données liées à l’authentification de l’utilisateur. Les capacités de stockage et de recherche d’Auth0 sont conçues pour des cas d’utilisation qui ne nécessitent pas de recherches intensives ou de mises à jour fréquentes.

Si vous devez conserver des données de profil détaillées sur les utilisateurs, vous devriez le faire dans un système externe. Vous pouvez stocker dans Auth0, comme champ de métadonnées, l’identifiant de l’utilisateur provenant de ce système.

​

Limites de taille et de stockage

• Les données utilisateur pouvant être indexées, interrogées et retournées par le endpoint de recherche d’utilisateurs sont limitées à 1 Mo par utilisateur. Si un profil utilisateur dépasse 1 Mo, les valeurs d’attribut de plus de 256 caractères dans app_metadata et user_metadata ne pourront pas être recherchées ni retournées dans les résultats de recherche. Si le profil utilisateur dépasse toujours 1 Mo après l’exclusion de ces valeurs volumineuses, aucun attribut de app_metadata et de user_metadata ne pourra être recherché ni retourné pour cet utilisateur. Auth0 consigne les cas où un profil utilisateur dépasse toujours 1 Mo après ces exclusions sous le code d’événement wum. Vous devez utiliser le endpoint de récupération d’un utilisateur pour récupérer tous les attributs de métadonnées des profils utilisateur trop volumineux.
• Lorsque vous définissez le champ user_metadata à l’aide du endpoint Signup de l’Authentication API d’Auth0, vous pouvez inclure un maximum de 10 champs de type chaîne dont les valeurs ne dépassent pas 500 caractères chacune. Pour voir un exemple d’utilisation des métadonnées dans un processus d’inscription personnalisé, consultez Custom Signup.
• Le champ client_metadata peut contenir un maximum de 10 clés. Chacune de ses clés et de ses valeurs peut compter au plus 255 caractères et ne peut pas contenir de caractères spéciaux UTF-8.

​

Restrictions

Le champ app_metadata ne doit contenir aucune des propriétés suivantes :

• __tenant
• _id
• blocked
• clientID
• created_at
• email_verified
• email
• globalClientID
• global_client_id
• identities
• lastIP
• lastLogin
• loginsCount
• metadata
• multifactor_last_modified
• multifactor
• updated_at
• user_id

​

En savoir plus

• Gérer les métadonnées avec Rules
• Gérer les métadonnées avec la Management API
• Configurer les métadonnées de l’application
• Stockage des données utilisateur