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

​
制限事項

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

​
詳しくはこちら