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

Décrit les noms de champs, les types de données, ainsi que les limites et restrictions des métadonnées utilisateur, des métadonnées d’accès et des métadonnées d’application (client).

Auth0 distingue trois types de métadonnées servant à stocker des types précis d’information.

Les métadonnées Auth0 ne constituent pas un stockage de données sécurisé et ne doivent pas être utilisées pour stocker des renseignements sensibles, comme des secrets à haut risque et des renseignements personnels identifiables (PII), tels que 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 de n’y conserver que ce qui est nécessaire à des fins de gestion des identités et des accès.

Type de métadonnées	Nom du champ	Description
Informations utilisateur	user_metadata	Stocke des attributs utilisateur, comme des préférences, qui n’ont pas d’incidence sur les fonctionnalités de base de l’utilisateur. 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 stockage de données sécurisé.
Informations d’accès	app_metadata	Stocke des renseignements comme les permissions, le plan Auth0 et les ID 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 il existe des restrictions quant à 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 des métadonnées

​

Caractères acceptés

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

Par exemple, ceci n’est pas permis :

{
  "preference.color": "pink"
}

Mais vous pouvez l’étendre ainsi :

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

​

Noms de champ dynamiques

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

Au lieu de faire ceci :

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

Faites ceci :

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

​

Collision 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é au profil racine, dans Rules comme dans Actions, ce qui peut remplacer des 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 dans l’objet user depuis une Rule, il renvoie : ["internal-group-1", "internal-group-2"].

​

Types de données des métadonnées

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

• String
• Number
• Array
• Object

Assurez-vous d’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 (user.user_metadata.age = 23), vous pourriez rencontrer des problèmes lors de la récupération des données.

​

Limites et restrictions

​

Limites de débit

Lorsque vous mettez à jour des métadonnées pendant la connexion à l’aide de Rules ou Actions, vous êtes soumis aux limites de débit de votre tenant. Pour en savoir plus, consultez les limites de débit des points de terminaison de la Management API.

Vous ne devriez stocker dans les métadonnées que les 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 des recherches fréquentes ni des mises à jour fréquentes.

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

​

Limites de taille et stockage

• Il existe une limite de 1 Mo par utilisateur pour les données utilisateur pouvant être indexées, interrogées et renvoyées par le point de terminaison de recherche d’utilisateurs. 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 seront pas interrogeables ni renvoyées dans les résultats de recherche. Si le profil utilisateur dépasse encore 1 Mo après l’omission de ces valeurs volumineuses, aucun des attributs app_metadata et user_metadata ne pourra être interrogé ni renvoyé pour cet utilisateur. Auth0 capture et consigne les cas où un profil utilisateur dépasse toujours 1 Mo après ces omissions sous le wum code d’événement. Le point de terminaison Get User doit être utilisé pour récupérer tous les attributs de métadonnées des profils utilisateur de trop grande taille.
• Lorsque vous définissez le champ user_metadata à l’aide du point de terminaison Signup de l’Auth0 Authentication API, vous pouvez inclure un maximum de 10 champs de type chaîne dont les valeurs ne dépassent pas 500 caractères chacune. Pour obtenir 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. Ses clés et ses valeurs ont chacune une longueur maximale de 255 caractères et ne peuvent 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 à l’aide de Rules
• Gérer les métadonnées à l’aide de la Management API
• Configurer les métadonnées de l’application
• Stockage des données utilisateur