Skip to main content
S’il y a des champs utilisateur qui ne devraient pas être stockés dans les bases de données Auth0 pour des raisons de confidentialité, vous pouvez les ajouter à la Deny List. Pour ajouter des attributs à la Deny List, effectuez une requête PATCH vers le point de terminaison Update Connection de la .
  1. Obtenez un jeton d’accès valide pour accéder au point de terminaison /patch_connections_by_id. Le jeton doit inclure la portée update:connections. Consultez Management API Access Tokens pour en savoir plus.
  2. Avec le jeton d’accès et la liste des attributs à rejeter, appelez l’API. Voici un exemple de requête HTTP qui rejette deux attributs : l’origine ethnique et le genre. Gardez à l’esprit que vous devez récupérer l’objet options et envoyer l’objet complet dans votre requête PATCH, car il n’y a pas de “fusion” lorsque vous ne mettez à jour qu’une ou deux valeurs.
Où :
  1. {yourConnectionId} est l’ID de connexion pour laquelle ces attributs seront rejetés. 2. {yourToken} est le jeton d’accès que vous avez reçu à l’étape précédente. 3. L’objet options.non_persistent_attrs contient un tableau des attributs qui seront rejetés. Si la claim que vous voulez rejeter est envoyée par un fournisseur d’identité en amont (IdP), vous devez définir la claim exactement telle qu’elle est envoyée par l’IdP en amont. Par exemple, pour une claim reçue sous la forme https://acme.com/temporary_idtoken, l’exemple d’objet non_persistent_attrs ci-dessus serait :

​
Limites

  • Seuls les champs racine (comme user.name ou user.phone_number) peuvent être rejetés.
    • Si user.name ou user.nickname sont rejetés, ils ne seront pas inclus dans les jetons.
    • Si user.email est rejeté, la valeur ne peut pas être mappée à un claim personnalisé. Par exemple, dans une règle, context.idToken[namespace + 'work_email'] = user.email ne fonctionnerait pas.
  • Lorsque vous rejetez des attributs, ils demeurent accessibles via les règles et les jetons sortants. Toutefois, si l’une des situations suivantes s’applique, les attributs de la Deny List ne seront pas inclus dans les jetons :
    • Vous avez activé l’authentification multifacteur (MFA)
    • Vous avez effectué une redirection via les règles
    • Votre application utilise Delegation (et vous n’avez pas défini scope = passthrough)
    • Votre application utilise l’impersonation
    • Vous avez activé le paramètre Use Auth0 instead of the IdP to do Single Sign-On (tenants Legacy uniquement)
  • Pour les connexions SAMLP, si vous activez le mode débogage, vos logs contiendront de l’information sur les attributs de la Deny List
Si l’une de ces limites est inacceptable, vous pouvez écrire une règle pour chiffrer les données et faire en sorte qu’elles soient enregistrées dans l’objet user.app_metadata.

​
En savoir plus