Skip to main content
Le fichier d’utilisateurs doit contenir un tableau JSON avec les informations des utilisateurs.
La taille maximale du fichier pour une importation groupée est de 500KB. Vous devrez lancer plusieurs importations si vos données dépassent cette limite.

Schéma JSON d’un utilisateur

Le schéma JSON suivant décrit les objets utilisateur valides :
Pour en savoir plus sur le schéma JSON, consultez jsonschema.org.

Propriétés

Vous pouvez importer des utilisateurs avec les propriétés suivantes : Pour en savoir plus sur app_metadata et user_metadata, consultez Comprendre le fonctionnement des métadonnées dans les profils utilisateur.

Métadonnées de l’application

L’objet user.app_metadata ne doit pas contenir les 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

Hachage personnalisé du mot de passe

L’objet user.custom_password_hash peut être utilisé à la place de la propriété user.password_hash lorsque le hachage du mot de passe de l’utilisateur a été créé avec un autre algorithme. Notez que ce champ et password_hash sont mutuellement exclusifs. L’objet user.custom_password_hash possède les propriétés suivantes :

Mettre à jour le hachage personnalisé du mot de passe

Pendant le processus d’importation groupée, vous pouvez mettre à jour le custom_password_hash si l’utilisateur ne s’est pas connecté à l’aide du custom_password_hash importé initialement. Par exemple, vous pouvez soumettre le JSON ci-dessous deux fois à l’endpoint /api/v2/jobs/users-imports avec des valeurs différentes pour custom_password_hash. Lors du deuxième envoi, définissez l’indicateur upsert sur true.
Vous pouvez utiliser le Bcrypt Password Generator de browserling.com pour générer des hachages bcrypt de mots de passe.

Algorithmes de hachage pris en charge

Auth0 prend actuellement en charge l’importation de mots de passe d’utilisateurs hachés avec : Veuillez consulter les sections suivantes lorsque vous fournissez un custom_password_hash.

Argon2

Lorsque algorithm est défini à argon2 :
  • hash.encoding doit être utf8.
  • hash.salt n’est pas autorisé.
  • hash.value doit être au format de chaîne PHC, comme indiqué dans P-H-C / phc-string-format sur GitHub. Il doit également respecter les exigences précisées dans Auth0 / magic sur GitHub.
  • hash.value doit inclure le sel encodé en base64 (comme indiqué dans la documentation PHC).

bcrypt

Lorsque algorithm est défini sur bcrypt :
  • hash.encoding doit être utf8.
  • hash.salt est autorisé en combinaison avec l’encodage et la position du sel.
  • hash.value doit inclure l’un de ces préfixes :
    • $2a$
    • $2b$
    • $2y$
    Les autres préfixes, comme $2$, $sha1$ et $2x$, ne sont pas pris en charge pour le moment.
Par exemple, la valeur suivante a été générée à partir de la chaîne hello à l’aide d’un paramètre de coût de 10 : $2b$10$nFguVi9LsCAcvTZFKQlRKeLVydo8ETv483lkNsSFI/Wl1Rz1Ypo1K L’algorithme bcrypt traite au maximum 72 octets en entrée lors du calcul des hachages de mot de passe ou des comparaisons, et la longueur de salt.value compte dans cette limite de 72 octets. Toute entrée qui dépasse cette limite est tronquée; par exemple, si le sel consomme 10 octets, la longueur maximale du mot de passe pour le hachage ou la comparaison est de 62 octets. Les mots de passe qui dépassent cette limite réduite sont tronqués, ce qui peut affaiblir la force du mot de passe ou provoquer des collisions de hachage. Validez toujours la longueur des mots de passe avant le hachage.

HMAC

Lorsque algorithm est défini à hmac :
  • hash.encoding doit être hex ou base64.
  • hash.digest est requis et doit correspondre à l’une des valeurs suivantes :
    • md4
    • md5
    • ripemd160
    • sha1
    • sha224
    • sha256
    • sha384
    • sha512
    • whirlpool
  • hash.key.value est requis.
  • hash.key.encoding doit être base64, hex ou utf8.

LDAP

Lorsque algorithm est défini à ldap :

MD ou SHA

Lorsque algorithm est défini à md4, md5, sha1, sha256 ou sha512 :
  • hash.encoding doit être hex ou base64.

PBKDF2

Lorsque algorithm est défini à pbkdf2 :
  • hash.encoding doit être utf8.
  • hash.salt n’est pas permis.
  • hash.value doit être au format de chaîne PHC, comme indiqué dans P-H-C / phc-string-format sur GitHub.
  • hash.value doit inclure le sel encodé en B64 (base64 sans les caractères de remplissage =, comme indiqué dans la documentation PHC).
  • hash.value devrait inclure les paramètres i (itérations) et l (longueur de clé). Si ces paramètres sont omis, les valeurs par défaut seront i=100000 et l=64.
  • L’id doit être au format pbkdf2-<digest> (pbkdf2-sha512, pbkdf2-md5, etc.). Les condensés pris en charge sont :
    • 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

Lorsque algorithm est défini sur scrypt :
  • hash.encoding doit être soit hex, soit base64.
  • Le paramètre keylen est obligatoire.
  • Le paramètre cost peut être spécifié; sinon, la valeur par défaut sera 16384.
  • Le paramètre blockSize peut être spécifié; sinon, la valeur par défaut sera 8.
  • Le paramètre parallelization peut être spécifié; sinon, la valeur par défaut sera 1.

Facteurs MFA

Le tableau user.mfa_factors contient les inscriptions de l’utilisateur. Pour en savoir plus, consultez l’authentification multifacteur dans Auth0. L’importation des inscriptions évite aux utilisateurs d’avoir à se réinscrire à l’authentification multifacteur après l’importation. Les types d’inscription pris en charge sont :

Exemples

Exemple de base

Un fichier dont le contenu est le suivant est valide :

Exemples de hachages de mots de passe personnalisés

Voici quelques exemples d’utilisateurs pour lesquels des hachages sont fournis :

Exemples de facteurs MFA

Comme on peut s’y attendre, le tableau user.mfa_factors vous permet d’indiquer les inscriptions MFA de l’utilisateur. Les types d’inscription pris en charge sont :
  • Téléphone : utilisé pour la vérification par SMS.
  • TOTP : secret OTP à utiliser avec des applications d’authentification MFA (Google Authenticator, Microsoft Authenticator, Authy, 1Password, LastPass).
  • Courriel : utilisé pour la vérification par courriel.
Voici quelques exemples d’utilisateurs avec des facteurs MFA :

En savoir plus