Passer au contenu principal
S’il existe 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 liste de refus. Pour ajouter des attributs à la liste de refus, envoyez une requête PATCH au point de terminaison Update Connection de l’.
  1. Obtenez un jeton d’accès valide pour accéder au point de terminaison /patch_connections_by_id. Le jeton doit inclure le scope update:connections. Consultez Management API Access Tokens pour en savoir plus.
  2. À l’aide du jeton d’accès et de la liste des attributs à exclure, appelez l’API. Voici un exemple de requête HTTP qui exclut 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 mettez à jour seulement une ou deux valeurs.
Où :
  1. {yourConnectionId} est l’ID de la connexion pour laquelle ces attributs seront refusé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 refusés. Si la revendication que vous souhaitez refuser est envoyée par un fournisseur d’identité (IdP) en amont, vous devez la définir exactement telle qu’elle est envoyée par cet IdP. Par exemple, pour une revendication reçue sous la forme https://acme.com/temporary_idtoken, l’objet non_persistent_attrs de l’exemple ci-dessus serait : 
    {"non_persistent_attrs": ["ethnicity", "gender", "https://acme.com/temporary_idtoken"]}

​
Limites

  • Seuls les champs de premier niveau (comme user.name ou user.phone_number) peuvent être ajoutés à la liste de refus.
    • Si user.name ou user.nickname sont refusés, ils ne seront pas inclus dans les jetons.
    • Si user.email est refusé, la valeur ne peut pas être associée à une revendication personnalisée. Par exemple, dans une Rule, context.idToken[namespace + 'work_email'] = user.email ne fonctionnerait pas.
  • Lorsque vous refusez des attributs, ils restent accessibles par les Rules et dans les jetons sortants. Toutefois, si l’un des cas suivants s’applique, les attributs de la liste de refus ne seront pas inclus dans les jetons :
    • Vous avez activé l’authentification multifacteur (MFA)
    • Vous avez effectué une redirection au moyen de Rules
    • Votre application utilise la délégation (et vous n’avez pas défini scope = passthrough)
    • Votre application utilise l’usurpation d’identité
    • Vous avez activé le paramètre Use Auth0 instead of the IdP to do Single Sign-On (locataires hérités seulement)
  • Pour les connexions SAMLP, si vous activez le mode Debug, vos journaux contiendront des renseignements sur les attributs de la liste de refus
Si l’une de ces limites est inacceptable, vous pouvez écrire une Rule pour chiffrer les données et les conserver dans l’objet user.app_metadata.

​
En savoir plus