Skip to main content
The users file must have an array with the users’ information in JSON format.
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:
To learn more about JSON schema, read jsonschema.org.

Properties

You can import users with the following properties: To learn more about app_metadata and user_metadata, read Understand How Metadata Works in User Profiles.

App metadata

The user.app_metadata object must not contain any of these properties:
  • __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

Custom password hash

The user.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:

Update custom password hash

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. 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.
You can use the Bcrypt Password Generator at browserling.com to generate bcrypt password hashes.

Supported hash algorithms

Auth0 currently supports imports of user passwords hashed by: Please consider the following sections when providing a custom_password_hash.

Argon2

When the algorithm is set to argon2:
  • hash.encoding must be utf8.
  • hash.salt is not allowed.
  • hash.value must 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.value must include the base64 encoded salt (as specified in the PHC documentation).

bcrypt

When the algorithm is set to bcrypt:
  • hash.encoding must be utf8.
  • hash.salt is allowed in conjunction with with salt encoding and position.
  • hash.value must include one of these prefixes:
    • $2a$
    • $2b$
    • $2y$
    Other prefixes, such as $2$, $sha1$, and $2x$, are not supported at this time.
For example, this was generated from the string 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 the algorithm is set to hmac:
  • hash.encoding must be either hex or base64.
  • hash.digest is required and must be one of these:
    • md4
    • md5
    • ripemd160
    • sha1
    • sha224
    • sha256
    • sha384
    • sha512
    • whirlpool
  • hash.key.value is required.
  • hash.key.encoding must be either base64 or hex or utf8.

LDAP

When the algorithm is set to ldap:

MD or SHA

When the algorithm is set to md4, md5, sha1, sha256, or sha512:
  • hash.encoding must be either hex or base64.

PBKDF2

When the algorithm is set to pbkdf2:
  • hash.encoding must be utf8.
  • hash.salt is not allowed.
  • hash.value should be in PHC string format, specified in P-H-C / phc-string-format on GitHub.
  • hash.value must include the B64 encoded salt (base64 omitting padding characters =, as specified in the PHC documentation).
  • hash.value should include i (iterations) and l (keylen) parameters. If these parameters are omitted, they will default to i=100000 and l=64.
  • The id should be in a pbkdf2-<digest> format (pbkdf2-sha512, pbkdf2-md5, etc). The supported digests are:
    • RSA-MD4
    • RSA-MD5
    • RSA-MDC2
    • RSA-RIPEMD160
    • RSA-SHA1
    • RSA-SHA1-2
    • RSA-SHA224
    • RSA-SHA256
    • RSA-SHA384
    • RSA-SHA512
    • md4
    • md4WithRSAEncryption
    • md5
    • md5WithRSAEncryption
    • mdc2
    • mdc2WithRSA
    • ripemd
    • ripemd160
    • ripemd160WithRSA
    • rmd160
    • sha1
    • sha1WithRSAEncryption
    • sha224
    • sha224WithRSAEncryption
    • sha256
    • sha256WithRSAEncryption
    • sha384
    • sha384WithRSAEncryption
    • sha512
    • sha512WithRSAEncryption
    • ssl3-md5
    • ssl3-sha1
    • whirlpool

scrypt

When the algorithm is set to scrypt:
  • hash.encoding must be either hex or base64.
  • keylen parameter is required.
  • cost parameter can be specified; if not, it will default to 16384.
  • blockSize parameter can be specified; if not, it will default to 8.
  • parallelization parameter can be specified; if not, it will default to 1.

MFA factors

The user.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:

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, the user.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.
Some examples of users with MFA factors:

Learn more