Passer au contenu principal
S’il existe des champs utilisateur qui ne doivent pas être stockés dans les bases de données Auth0 pour des raisons de confidentialité, vous pouvez les ajouter à la liste rouge. Pour ajouter des attributs à la liste rouge, effectuez un appel PATCH au point de terminaison de connexion de mise à jour de .
  1. Obtenez un jeton d’accès valide pour accéder au point de terminaison/patch_connections_by_id. Le jeton doit inclure la permission update:connections. Pour plus de détails, veuillez consulter Jetons d’accès à Management API.
  2. Avec le jeton d’accès et la liste des attributs à refuser, appelez l’API. Voici un exemple de requête HTTP qui refuse deux attributs : l’origine ethnique et le genre. Gardez à l’esprit que vous devez récupérer l’objet options et envoyer l’objet entier dans votre requête PATCH, car il n’y a pas de « fusion » si vous ne mettez à jour qu’une ou deux valeurs.
     curl --request PATCH \
       --url 'https://{yourDomain}/api/v2/connections/YOUR_CONNECTION_ID' \
       --header 'authorization: Bearer YOUR_TOKEN' \
       --header 'content-type: application/json' \
       --data '{"options": {"non_persistent_attrs": ["ethnicity", "gender"]}}'
    
    Où :
    1. {yourConnectionId} est l’ID de connexion pour lequel 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 demande que vous souhaitez refuser est envoyée par un fournisseur d’identité (IdP) en amont, vous devez définir la demande exactement comme elle a été envoyée par l’IdP en amont. Par exemple, pour une demande reçue comme https://acme.com/temporary_idtoken, l’objet de l’exemple ci-dessus non_persistent_attrs serait :
      {"non_persistent_attrs": ["ethnicity", "gender", "https://acme.com/temporary_idtoken"]}
      

Limites

  • Seuls les champs racine (comme user.name ou user.phone_number) peuvent être refusés.
    • Si user.name ou user.nickname est refusé, il ne sera pas inclus dans les jetons.
    • Si user.email est refusé, la valeur ne peut pas être mappée à une demande personnalisée. Par exemple, dans une règle, context.idToken[namespace + ’work_email’] = user.email ne fonctionnerait pas.
  • Lorsque vous refusez des attributs, ils seront toujours disponibles via des règles et des jetons sortants. Cependant, si l’une des conditions suivantes s’applique, les attributs de la liste rouge ne seront pas inclus dans les jetons :
    • Vous avez activé l’authentification multifacteur (MFA)
    • Vous avez effectué une redirection à l’aide de règles
    • Votre application utilise la délégation (et vous n’avez pas défini permission = passthrough)
    • Votre application utilise l’usurpation d’identité
    • Vous avez activé le paramètre Utiliser Auth0 au lieu de l’IdP pour effectuer une authentification unique (anciens locataires uniquement)
  • Pour les connexions SAMLP, si vous activez le mode Debug, vos journaux contiendront des informations sur les attributs de la liste rouge
Si l’une de ces limitations est inacceptable, vous pouvez créer une règle pour chiffrer les données et faire en sorte que les données persistent dans l’objet user.app_metadata.

En savoir plus

I