検討事項
以下を確認し、Non-Unique Emails がご利用のユースケースに適しているかをご確認ください。主識別子の要件
Non-Unique Emails を使用している場合、メールアドレスを主識別子として使用することはできません。主識別子には別の属性を設定する必要があり、その属性が認証、パスワードリセット、アカウント管理に使用されます。 識別子と属性の詳細については、Flexible Identifiers を参照してください。パスワードリセット
エンドユーザーがパスワードをリセットする際は、ユーザー名、電話番号、または管理者が主識別子として設定した属性のいずれかを入力する必要があります。Auth0 はその主識別子を使用して、共有メールアドレスに関連付けられたアカウントを特定し、そのアカウントのパスワードをリセットします。元に戻せない設定
一度、接続でメール属性を非一意に設定すると、再び一意に戻すことはできません。さらに、非一意のメールアドレスをサポートするデータベース接続は新規作成時にのみ設定できます。既存の接続を変更することはできないため、選択した主識別子を使用するようにアプリを更新する必要があります。Flexible Identifiers
Non-Unique Emails を使用するには、データベース接続で Flexible Identifiers を有効にする必要があります。これは接続の作成後に無効化できません。 で Non-Unique Emails を有効にすると、Flexible Identifiers は自動的に自動設定されます。API の動作変更
GET /api/v2/users-by-email は、同じメールアドレスを共有しているすべてのユーザーを返します。
DELETE /api/v2/connections/{id}/users は、非一意メール接続には対応していません。
POST /dbconnections/change_password は、ユーザーアカウントを特定するために一意のメールアドレスを必要とするため、非一意メール接続では使用できません。ユーザーは、主識別子を利用するフローを使ってパスワードをリセットする必要があります。
Auth0 Dashboard で非一意のメールアドレスを有効にする
- Authentication > Database に移動し、新しい接続を作成します。
- Choose one or more attributes as user identifiers セクションで、Email Address を On に切り替え、表示される Allow non-unique email addresses トグルを有効にします。
- ログインとパスワードリセットのフローで主識別子として使用するため、ユーザー名 または電話番号のいずれかも On に切り替えます。
- メールアドレスが識別子として使用されないことを確認したら、Create を選択して接続を保存します。

Management API で Non-Unique Emails を有効にする
Management API のPOST /api/v2/connections エンドポイントを使用して、Non-Unique Emails をサポートするデータベース接続を作成します。
接続を作成する際は、次のように設定します。
- 同じメールアドレスを持つ複数のアカウントを許可するには、
options.attributes.emailオブジェクトで unique: false を設定します。メールアドレスが一意でない場合に主識別子として使われないよう、identifier.active: false を設定します。 - 別の属性を主識別子として選択し、選択した属性に identifier.active: true を設定します。
リクエストの例
以下は、ユーザー名を主識別子として使用し、同じメールアドレスを複数のアカウントで利用できるデータベース接続を作成するためのリクエスト本文の例です。共有メールに関するリスク免責事項
Non-Unique Emails 機能には、メールを主識別子として使用できないようにしたり、パスワードリセットをユーザー名または電話番号で行うよう必須にしたりといった保護策が含まれていますが、それでも複数のユーザーアカウントで同じメールアドレスを共有することには、本質的なリスクが伴います。たとえば、次のようなものです。- すべてのメール連絡 (例: パスワードリセットリンク、通知) は、どのユーザーが操作を開始したかにかかわらず、同じ受信トレイに配信されます。
- その結果、ユーザーが混乱したり、受信トレイが共有されている場合にはメールベースのリンクに意図せずアクセスされる可能性があります。
- 共有メールの利用が、あなたのユースケースに適していること。
- エンドユーザーに対して適切な案内とトレーニングが行われること。
- メールベースのワークフローで起こり得る重複を考慮したアプリケーション設計になっていること。