The file size limit for a bulk import is 500KB. You will need to start multiple imports if your data exceeds this size.
User JSON schema
The following JSON schema describes valid users:Properties
You can import users with the following properties:| Property | Type | Description | Upsert During Import? |
|---|---|---|---|
app_metadata | object | Data that can affect the application’s core functionality or what the user can access. Data stored in app_metadata cannot be edited by users. This may include things such as support plans, roles or access groups. | Yes |
blocked | boolean | Indicates whether the user has been blocked. | No |
email | string | The user’s email address. | No |
email_verified | boolean | Indicates whether the user has verified their email address. Set to false by default if email is updated by upsert but not email_verified. | Yes |
family_name | string | The user’s family name. | Yes |
given_name | string | The user’s given name. | Yes |
name | string | The user’s full name. | Yes |
nickname | string | The user’s nickname. | Yes |
picture | string | URL pointing to the user’s profile picture. | Yes |
user_id | string | The user’s unique identifier. This will be prepended by the connection strategy. | No |
user_metadata | object | Data that does not impact what users can or cannot access, such as work address, home address, or user preferences. | Yes |
username | string | The user’s username. | No |
password_hash | string | Hashed password for the user’s connection. When users are created, Auth0 uses bcrypt to secure the password. Importing hashed passwords lets users keep their passwords for a smoother experience. Compatible passwords should be hashed using bcrypt or and have 10 saltRounds. This property can only be provided when the user is first imported and cannot be updated later. | No |
custom_password_hash | object | A more generic way to provide the user’s password hash. This can be used instead of the password_hash field when the user’s password hash was created with an alternate algorithm. 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. | Yes |
mfa_factors | array | The MFA factors that can be used to authenticate this user | No |
app_metadata and user_metadata, read Understand How Metadata Works in User Profiles.
App metadata
Theuser.app_metadata object must not contain any of these properties:
__tenant_idblockedclientIDcreated_atemail_verifiedemailglobalClientIDglobal_client_ididentitieslastIPlastLoginloginsCountmetadatamultifactor_last_modifiedmultifactorupdated_atuser_id
Custom password hash
Theuser.custom_password_hash object can be used instead of the user.password_hash property when the user’s password hash was created with an alternate algorithm. Note this field and password_hash are mutually exclusive.
The user.custom_password_hash object has the following properties:
| Property | Type | Description |
|---|---|---|
algorithm | string | The algorithm used to hash the password. Must be one of:
|
hash | object | |
hash.value | string | The password hash. |
hash.encoding | string | The encoding of the provided hash. Must be one of:
|
hash.digest | string | The algorithm used to generate the HMAC hash. Must be one of:
|
hash.key | object | The key used to generate the HMAC hash. |
hash.key.value | string | The key value. |
hash.key.encoding | string | The key encoding. Must be one of:
hash.key.encoding is utf8. |
salt | object | |
salt.value | string | The salt value used to generate the hash. |
salt.encoding | string | The encoding of the provided salt. Must be one of:
salt.encoding is utf8. |
salt.position | string | The position of the salt when the hash was calculated. By default, salt.position is prefix. |
password.encoding | string | The encoding of the password used to generate the hash. Must be one of:
password.encoding before being checked against the provided hash. For example, if your hash was generated from a ucs2 encoded string, then you would set: “encoding”: “ucs2” |
keylen | integer | Desired key length in bytes for the scrypt hash. Must be an integer greater than zero. This parameter is required when algorithm is set to scrypt. |
cost | integer | CPU/memory cost parameter used for the scrypt hash. Must be a power of two greater than one. By default, cost is 16384.This parameter is only used when algorithm is set to scrypt. |
blockSize | integer | Block size parameter used for the scrypt hash. Must be a positive integer. By default, blockSize is 8.This parameter is only used when algorithm is set to scrypt. |
parallelization | integer | Parallelization parameter used for the scrypt hash. Must be a positive integer. By default, parallelization is 1.This parameter is only used when algorithm is set to scrypt. |
Update custom password hash
During the bulk import process, you can update thecustom_password_hash if the user did not login using the initially imported custom_password_hash. For example, you can submit the below JSON twice to the/api/v2/jobs/users-imports endpoint with different values for custom_password_hash. On the second submit, send the upsert flag to true.
Supported hash algorithms
Auth0 currently supports imports of user passwords hashed by: Please consider the following sections when providing acustom_password_hash.
Argon2
When thealgorithm is set to argon2:
hash.encodingmust beutf8.hash.saltis not allowed.hash.valuemust be in PHC string format, specified in P-H-C / phc-string-format on GitHub. It also must conform to the requirements specified in Auth0 / magic on GitHub.hash.valuemust include the base64 encoded salt (as specified in thePHCdocumentation).
bcrypt
When thealgorithm is set to bcrypt:
-
hash.encodingmust beutf8. -
hash.saltis allowed in conjunction with with salt encoding and position. -
hash.valuemust include one of these prefixes:$2a$$2b$$2y$
$2$,$sha1$, and$2x$, are not supported at this time.
hello using a cost parameter of 10:
$2b$10$nFguVi9LsCAcvTZFKQlRKeLVydo8ETv483lkNsSFI/Wl1Rz1Ypo1K
The bcrypt algorithm processes a maximum of 72 bytes of input when computing password hashes or performing comparisons and the length of salt.value counts towards the 72-byte input limit. Any input beyond the 72 byte limit is truncated; for example, if the salt consumes 10 bytes, the maximum password length for hashing or comparison is 62 bytes.
Passwords longer than the reduced limit are truncated, potentially weakening password strength or introducing hash collisions. Always validate password lengths before hashing.
HMAC
When thealgorithm is set to hmac:
-
hash.encodingmust be eitherhexorbase64. -
hash.digestis required and must be one of these:md4md5ripemd160sha1sha224sha256sha384sha512whirlpool
-
hash.key.valueis required. -
hash.key.encodingmust be eitherbase64orhexorutf8.
LDAP
When thealgorithm is set to ldap:
hash.encodingmust beutf8.saltis not allowed.hash.valuemust adhere to the format outlined in RFC-2307 section-5.3 on IETF Datatracker.- The scheme should be one of
md5|smd5|sha*|ssha*see here for more info. - Note that the crypt scheme is not supported due to system/implementation dependent behavior. To learn more, read Open LDAP Admin Guide - 14.4.2. CRYPT password storage scheme.
MD or SHA
When thealgorithm is set to md4, md5, sha1, sha256, or sha512:
hash.encodingmust be eitherhexorbase64.
PBKDF2
When thealgorithm is set to pbkdf2:
-
hash.encodingmust beutf8. -
hash.saltis not allowed. -
hash.valueshould be in PHC string format, specified in P-H-C / phc-string-format on GitHub. -
hash.valuemust include the B64 encoded salt (base64 omitting padding characters=, as specified in thePHCdocumentation). -
hash.valueshould includei(iterations) andl(keylen) parameters. If these parameters are omitted, they will default toi=100000andl=64. -
The
idshould be in apbkdf2-<digest>format (pbkdf2-sha512,pbkdf2-md5, etc). The supported digests are:RSA-MD4RSA-MD5RSA-MDC2RSA-RIPEMD160RSA-SHA1RSA-SHA1-2RSA-SHA224RSA-SHA256RSA-SHA384RSA-SHA512md4md4WithRSAEncryptionmd5md5WithRSAEncryptionmdc2mdc2WithRSAripemdripemd160ripemd160WithRSArmd160sha1sha1WithRSAEncryptionsha224sha224WithRSAEncryptionsha256sha256WithRSAEncryptionsha384sha384WithRSAEncryptionsha512sha512WithRSAEncryptionssl3-md5ssl3-sha1whirlpool
scrypt
When thealgorithm is set to scrypt:
hash.encodingmust be eitherhexorbase64.keylenparameter is required.costparameter can be specified; if not, it will default to 16384.blockSizeparameter can be specified; if not, it will default to 8.parallelizationparameter can be specified; if not, it will default to 1.
MFA factors
Theuser.mfa_factors array contains enrollments for the user. To learn more, read Multi-Factor Authentication in Auth0. Importing enrollments prevents the need for users to re-enroll in MFA after they’re imported. The supported enrollment types are:
| Property | Type | Description |
|---|---|---|
email | object | |
email.value | string | The email address for MFA. |
phone | object | |
phone.value | string | The phone number for SMS MFA. Must have a country code and begin with +, such as: “+12125550001” |
totp | object | |
totp.secret | string | The OTP secret for MFA authentication with authenticator apps (Google Authenticator, Microsoft Authenticator, Authy, 1Password, LastPass). Must be in un-padded Base32 encoding, for example: “JBTWY3DPEHPK3PNP” |
Examples
Basic example
A file with the following contents is valid:Custom password hash examples
Some example users with hashes provided:MFA factors examples
As you might expect, theuser.mfa_factors array allows you to provide the user’s MFA enrollments. The supported enrollment types are:
- Phone: Used for sms-based verification.
- TOTP: OTP secret for use with MFA type apps (Google Authenticator, Microsoft Authenticator, Authy, 1Password, LastPass).
- Email: Used for email-based verification.