If there are user fields that should not be stored in Auth0 databases due to privacy reasons, you can add them to the Deny List. To add attributes to the Deny List, make a PATCH call to the Update Connection endpoint of the .
  1. Get a valid access token to access the /patch_connections_by_id endpoint. The token must include the update:connections scope. See Management API Access Tokens for details.
  2. With the access token and the list of attributes to be denied, call the API. Here is an example HTTP request that denies two attributes: ethnicity and gender. Keep in mind you need to retrieve the options object and send the whole object in your PATCH request as there is no “merge” when you only update one or two values. 
     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"]}}'
    Where:
    1. {yourConnectionId} is the connection ID for which these attributes will be denied.
    2. {yourToken} is the access token you received in the previous step.
    3. options.non_persistent_attrs object holds an array of the attributes that will be denied. If the claim that you want to deny is being sent by an upstream Identity Provider (IdP), you should set the claim exactly as sent by the upstream IdP. For example, for a claim received as https://acme.com/temporary_idtoken, the above sample non_persistent_attrs object would read: 
      {"non_persistent_attrs": ["ethnicity", "gender", "https://acme.com/temporary_idtoken"]}

​
Limitations

  • Only root fields (such as user.name or user.phone_number) can be denied.
    • If user.name or user.nickname are denied, they will not be included in tokens.
    • If user.email is denied, the value cannot be mapped to a custom claim. For example, in a rule, context.idToken[namespace + 'work_email'] = user.email would not work.
  • When you deny attributes, they will still be available via rules and outgoing tokens. However, if any of the following apply, the Deny List attributes will not be included in tokens:
    • You have enabled multi-factor authentication (MFA)
    • You have performed a redirect via rules
    • Your app is using delegation (and you haven’t set scope = passthrough)
    • Your app is using impersonation
    • You have enabled the Use Auth0 instead of the IdP to do Single Sign-On setting (legacy tenants only)
  • For SAMLP connections, if you enable Debug mode, your logs will contain information on the Deny List attributes
If any of these limitations are unacceptable, you can write a rule to encrypt the data and have the data persist to the user.app_metadata object.

​
Learn more