メインコンテンツへスキップ
プライバシー上の理由から Auth0 データベースに保存すべきでないユーザーフィールドがある場合は、それらを Deny List に追加できます。Deny List に属性を追加するには、 の Update Connection エンドポイントに PATCH リクエストを送信します。
  1. /patch_connections_by_id エンドポイント にアクセスするための有効なアクセストークンを取得します。トークンには update:connections スコープが含まれている必要があります。詳しくは Management API アクセストークン を参照してください。
  2. アクセストークンと拒否する属性のリストを使用して API を呼び出します。以下は、ethnicity と gender の 2 つの属性を拒否する HTTP リクエストの例です。1 つまたは 2 つの値だけを更新する場合でも “merge” は行われないため、options オブジェクトを取得し、PATCH リクエストではそのオブジェクト全体を送信する必要がある点に注意してください。
ここで:
  1. {yourConnectionId} は、これらの属性が拒否される対象の接続 IDです。 2. {yourToken} は、前の手順で受け取ったアクセストークンです。 3. options.non_persistent_attrs オブジェクトには、拒否する属性の配列が格納されます。拒否したい claim が upstream IDプロバイダー (IdP) から送信される場合は、その claim を upstream IdP から送信されたものと完全に同じ値で設定する必要があります。たとえば、https://acme.com/temporary_idtoken という claim を受け取った場合、上記の non_persistent_attrs オブジェクトの例は次のようになります。 
    {"non_persistent_attrs": ["ethnicity", "gender", "https://acme.com/temporary_idtoken"]}

​
制限事項

  • deny の対象にできるのは、ルートフィールド (user.name や user.phone_number など) のみです。
    • user.name または user.nickname を deny すると、それらはトークンに含まれません。
    • user.email を deny すると、その値をカスタムクレームにマッピングできません。たとえば、Rule で context.idToken[namespace + 'work_email'] = user.email は機能しません。
  • 属性を deny しても、それらは引き続き Rules や送信されるトークンから利用できます。ただし、以下のいずれかに該当する場合、Deny List の属性はトークンに含まれません。
    • 多要素認証 (MFA) を有効にしている
    • Rules によるリダイレクトを実行している
    • アプリでデリゲーションを使用している (scope = passthrough を設定していない)
    • アプリで impersonation を使用している
    • Use Auth0 instead of the IdP to do Single Sign-On 設定を有効にしている (レガシーテナントのみ)
  • SAMLP 接続では、Debug mode を有効にすると、logs に Deny List の属性に関する情報が含まれます
これらの制限を許容できない場合は、データを暗号化し、そのデータを user.app_metadata オブジェクトに保持する Rule を作成できます。

​
詳細情報