拒否リストへのユーザー属性の追加

プライバシー上の理由により Auth0 データベースに保存すべきでないユーザーフィールドがある場合は、それらを拒否リストに追加できます。拒否リストに属性を追加するには、の更新接続エンドポイントに対してPATCH呼び出しを行います。

/patch_connections_by_idエンドポイントにアクセスするための有効なアクセストークンを取得します。トークンには、update:connectionsスコープが含まれている必要があります。詳細については、［Management API Access Tokens（Management APIのアクセストークン）］を参照してください。
アクセストークンと拒否する属性のリストを使用して、API を呼び出します。以下は、ethnicityとgenderの2つの属性を拒否するHTTP要求の例です。1つまたは2つの値のみを更新する場合は「マージ」が行われないため、optionsオブジェクトを取得してPATCH要求でオブジェクト全体を送信する必要があることに注意してください。

ここでは、

{yourConnectionId} は、これらの属性が拒否される接続 IDです。
{yourToken}は、前の手順で受け取ったアクセストークンです。
options.non_persistent_attrsオブジェクトは、拒否される属性の配列を保持します。拒否するクレームがアップストリームのIDプロバイダー（IdP）によって送信されている場合は、アップストリームのIdPによって送信されたとおりにクレームを設定する必要があります。たとえば、https://acme.com/temporary_idtokenとして受信されたクレームの場合、上記のサンプルのnon_persistent_attrsオブジェクトオブジェクトが読み取ります。
```
{"non_persistent_attrs": ["ethnicity", "gender", "https://acme.com/temporary_idtoken"]}
```

制限事項

拒否できるのは、ルートフィールド（user.nameやuser.phone_number など）のみです。
- user.nameまたはuser.nicknameが拒否された場合、それらはトークンに含まれません。
- user.emailが拒否された場合、その値はカスタムクレームにマッピングできません。たとえば、ルールでは、context.idトークン[namespace + 'work_email'] = user.emailは機能しません。
属性を拒否しても、ルールと送信トークンを介して使用できます。ただし、次のいずれかに該当する場合、拒否リスト属性はトークンに含まれません :
- 多要素認証（MFA）を有効にしています
- ルールを介してリダイレクトを実行しています
- アプリで委任を使用しています（かつ、scope = passthrough を設定していない）
- アプリはなりすましを使用しています
- ［Use Auth0 instead of the IdP to do Single Sign-On（IdPの代わりにAuth0を使用してシングルサインオン）］ の設定を有効にしています（レガシーテナントのみ）
SAMLP接続の場合、デバッグモードを有効にすると、ログに拒否リスト属性に関する情報が含まれます

これらの制限のいずれかが受け入れられない場合は、データを暗号化するルールを記述し、データをuser.app_metadataオブジェクトに保持することができます。