User Profile Structure

Auth0's normalized user profile consists of a few different components:

  • Details: Core User Profile object, which contains basic info, such as name, email, and timestamp of the user's latest login, in pre-defined attributes. This object may also contain info from a user's source connection. Most of the user attributes are root attributes (attributes stored at the first, or root, level of the user object), and some of these are editable.

  • Metadata: Two sub-objects that operate as secondary storage to store additional user info in customizable attributes: user_metadata and app_metadata. To learn more, including when to use app_metadata and user_metadata, read Understand How Metadata Works in User Profiles.

User profile attributes

The following attributes are available on the user profile. Many are root attributes (attributes stored at the first, or root, level of the user object), and some may be updated, imported, and exported, as noted below.

If there are user fields that should not be stored by Auth0 due to privacy reasons, you can add the attributes you do not want persisting in Auth0 databases to the DenyList. To learn more, read Add User Attributes to the DenyList.

By default, user profile attributes provided by identity providers other than Auth0 (such as Google, Facebook, or X) are not directly editable because they are updated from the identity provider each time the user logs in.

To be able to edit the name, nickname, given_name, family_name, or picture root attributes on the normalized user profile, you must configure your connection sync with Auth0 so that user attributes will be updated from the identity provider only on user profile creation. These root attributes will then be available to be edited individually or by bulk imports

Name Type Description Search? Update? Import? Upsert during import? Export?
app_metadata object Custom fields that store info about a user that influences the user's access, such as support plan, security roles (if not using the Authorization Core feature set), or access control groups. To learn more, read Metadata Overview. Y Y Y Y Y
blocked boolean Indicates whether the user has been blocked. Importing enables subscribers to ensure that users remain blocked when migrating to Auth0. Y Y Y N Y
blocked_for array (object) IP addresses that have been blocked under suspicion of a bruteforce attack. N N N N N
created_at date time Timestamp indicating when the user profile was first created. Y N N N Y
email text (unique) The user's email address. Y Y Y N Y
email_verified boolean Indicates whether the user has verified their email address. Y Y Y Y Y
family_name text The user's family name. Y Y Y Y Y
given_name text The user's given name. Y Y Y Y Y
guardian_authenticators array (object) Detailed information about the guardian backup authorization methods the user has set up, including SMS and Recovery Codes. N N N N N
identities array (object)

Contains info retrieved from the identity provider with which the user originally authenticates. Users may also link their profile to multiple identity providers; those identities will then also appear in this array. The contents of an individual identity provider object varies by provider, but it will typically include the following:

  • connection (text): Name of the Auth0 connection used to authenticate the user.
  • isSocial (boolean): Indicates whether the connection is a social one.
  • provider (text): Name of the entity that is authenticating the user, such as Facebook, Google, SAML, or your own provider.
  • user_id (text): User's unique identifier for this connection/provider.
  • profileData (object): User info associated with the connection. When profiles are linked, it is populated with the associated user info for secondary accounts.
In some cases, it will also include an API Access Token to be used with the provider.		 Y N N N Y
last_ip text IP address associated with the user's last login. Y N N N Y
last_login date time Timestamp indicating when the user last logged in. If a user is blocked and logs in, the blocked session updates last_login. If you are using this property from inside a Rule using the user< object, its value will be associated with the login that triggered the rule; this is because rules execute after login. Y N N N Y
last_password_reset date time Timestamp indicating the last time the user's password was reset/changed. At user creation, this field does not exist. This property is only available for Database connections. N N N N Y
logins_count integer Number of times the user has logged in. If a user is blocked and logs in, the blocked session is counted in logins_count. Y N N N Y
multifactor array (string) List of multi-factor providers with which the user is enrolled. N N N N Y
multifactor_last_modified date time Date and time of the last update to a user's multifactor authentication. N N N N Y
name text The user's full name. Y Y Y Y Y
nickname text The user's nickname. Y Y Y Y Y
phone_number text The user's phone number. Only valid for users with SMS connections. Y Y N N Y
phone_verified boolean Indicates whether the user has been verified their phone number. Only valid for users with SMS connections. Y Y N N Y
picture text URL pointing to the user's profile picture. N Y Y Y Y
tenant text Name of the tenant being used. N N N N N
updated_at date time Timestamp indicating when the user's profile was last updated/modified. Changes to last_login are considered updates, so most of the time, updated_at will match last_login. Y N N N Y
user_id text (unique) The user's identifier. Importing allows user records to be synchronized across multiple systems without using mapping tables. Y N Y N Y
user_metadata object Custom fields that store info about a user that does not impact what they can or cannot access, such as work address, home address, or user preferences. To learn more, read Metadata Overview. Y Y Y Y Y
username text (unique) The user's username. Y Y Y N Y

User profile validation

Auth0 accepts a specific validation schema for certain fields in the user profile. See the table below for a list of requirements when setting profile attribute values.

Field Type Character Limit Validation
email email The maximum length is 64 characters for the user/local part and 256 characters for the domain part. JSON validation schema.
username string The default allowed length for usernames is between 1 and 15 characters. Up to a maximum length of 128 characters. The username field accepts the following characters:
Alphanumeric characters (without accent marks, automatically converted to lowercase);
The at sign (@) character (but email addresses are not allowed);
The caret (^) character;
The dollar sign ($) character;
The dot (.) character;
The exclamation (!) character;
The grave accent (`) character;
The minus (-) character;
The number sign (#) character;
The plus (+) character;
The single quote (') character;
The tilde (~) character;
The underscore (_) character;
No other characters/symbols are allowed, and Auth0 does not validate or sanitize custom database inputs.
phone_number phone Standardized Format
Phone numbers need to be in E.164 format		 Regex: ^\+[0-9]{1,15}$
password string The minimum password length you can set is 1 byte, while the maximum is 72 bytes. Standard Characters: ASCII characters in the range of 33-126 are valid, including:
A through Z uppercase characters,
a through z lower case characters,
0 through 9 numeric characters,
special characters allowed.
name string 1-150 characters All UTF-8 characters are supported
nickname string 1-350 characters All UTF-8 characters are supported
family_name string 1-150 characters All UTF-8 characters are supported
given_name string 1-150 characters All UTF-8 characters are supported

Three other fields are not technically part of the user profile, but may be of interest when importing users:

  • password_hash (text): Hashed password for the user's connection. When users are created, Auth0 uses bcrypt to secure the password. Importing compatible hashed passwords allows users to retain their passwords, thereby providing a smoother experience. Compatible passwords should be hashed using bcrypt $2a$ or $2b$ and have 10 saltRounds. Note that you can provide this field only when the user is first imported; you cannot update it later.

  • custom_password_hash (object): Hashed password for the user's connection when created using an alternate algorithm. Used in place of the password_hash field. During the bulk import process, you can update the custom_password_hash if the user did not login using the initially imported custom_password_hash.

Learn more