重複可能なメールアドレス

重複可能なメールアドレスと関連する識別子の設定方法

重複可能なメールアドレスを使用すると、同じデータベース接続を共有する複数のユーザーアカウントで、1 つのメールアドレスを使用しつつ、別の属性 (username や電話番号など) を主要な識別子として利用できます。たとえば、1 つのメールアドレスで複数の子ども用アカウントを管理する保護者や、拠点ごとに 1 つのメールアドレスを使う小規模事業者のようなケースでも、重複可能なメールアドレスを使えば、アカウントごとに安全なログインおよびパスワードリセットの運用を維持できます。

​

考慮事項

Non-Unique Emails がユースケースに適しているかどうかを判断するため、以下を確認してください。

​

主識別子の要件

Non-Unique Emails を使用する場合、メールアドレスは主識別子として使用できません。主識別子として別の属性を設定する必要があります。この主識別子は、認証、パスワードのリセット、アカウント管理に使用されます。

識別子と属性の詳細については、Flexible Identifiers を参照してください。

​

パスワードのリセット

エンドユーザーがパスワードをリセットする際は、ユーザー名、電話番号、または管理者がプライマリ属性として設定した属性のいずれかを指定する必要があります。Auth0 はそのプライマリ識別子を使用して、共有メールアドレスに関連付けられたアカウントを特定し、そのパスワードをリセットします。

​

元に戻せない設定

接続でメールアドレス属性を一意でない設定にすると、後から一意に戻すことはできません。さらに、一意でないメールアドレスをサポートするデータベース接続として作成できるのは、新しい接続のみです。既存の接続を変更することはできないため、選択した主要識別子を使用するようにアプリを更新する必要があります。

​

柔軟な識別子

非一意のメールアドレスを使用するには、データベース接続で柔軟な識別子を有効にしておく必要があります。また、接続の作成後に無効化することはできません。Management APIで非一意のメールアドレスを有効にすると、柔軟な識別子は自動的に設定されます。

​

API の動作変更

GET /api/v2/users-by-email は、同じメールアドレスを持つすべてのユーザーを返します。

DELETE /api/v2/connections/{id}/users は、一意でないメールアドレスの接続には対応していません。

POST /dbconnections/change_password は、ユーザーアカウントを特定するために一意のメールアドレスを必要とするため、一意でないメールアドレスの接続では使用できません。ユーザーは、プライマリ識別子を使用するフローでパスワードをリセットする必要があります。

​

Auth0 Dashboard で一意でないメールアドレスを有効にする

1. Authentication > Database に移動し、新しい接続を作成します。
2. Choose one or more attributes as user identifiers セクションで、メールアドレスを On に切り替え、表示される Allow non-unique email addresses トグルを有効にします。
3. username または電話番号のいずれかも On に切り替え、ログインおよびパスワードリセットフローの主識別子として使用します。
4. メールアドレスが識別子として使用されないことを確認したら、Create を選択して接続を保存します。

​

Management API で重複するメールアドレスを有効にする

Management API の POST /api/v2/connections エンドポイントを使用して、重複するメールアドレスをサポートするデータベース接続を作成します。

接続を作成する際は、次のように設定します。

• 同じメールアドレスを持つ複数のアカウントを許可するには、options.attributes.email オブジェクトで unique: false を設定します。また、メールアドレスが一意でない場合に主識別子として使用されないよう、identifier.active: false を設定します。
• 別の属性を主識別子として選択し、選択した属性に identifier.active: true を設定します。

メールアドレス以外に主識別子がない場合、認証フローおよびパスワードリセットフローは正しく動作しません。少なくとも 1 つの属性が有効な識別子として設定されていることを確認してください。

​

リクエストの例

以下は、username を主要な識別子として使用し、重複するメールアドレスを許可するデータベース接続を作成するためのリクエストボディの例です。

{
 "name": "new-non-unique",
 "strategy": "authO",
 "options": {
  "attributes": {
   "email": {
     "unique": false,
     "signup" : {
       "status": "required"
     },
     "identifier": {
      "active": false
     },
     "profile_required": true
   ｝，
   "username": {
    "signup": {
     "status": "required"
   },
   "identifier": {
    "active": true
   ｝，
   "profile_required": true
   }
  }
 }
}

​

共有メールアドレスに関するリスク免責事項

Non-Unique Emails 機能には、メールアドレスを主識別子として使用できないようにすることや、パスワードのリセットをユーザー名または電話番号で行うことを必須にすることなどの保護措置が含まれています**。**それでも、複数のユーザーアカウントで同じメールアドレスを共有する場合には、本質的なリスクが伴います。たとえば、次のようなものです。

• すべてのメールによる連絡 (例: パスワードリセットリンク、通知) は、どのユーザーが操作を開始したかにかかわらず、同じ受信トレイに配信されます。
• その結果、ユーザーの混乱を招いたり、受信トレイが共有されている場合にはメールベースのリンクに意図せずアクセスされる可能性があります。

この機能を有効にすると、以下を確実にする責任を認識し、これを受け入れるものとします。

• 共有メールアドレスの運用が、あなたのユースケースに適していること。
• エンドユーザーに対して適切に周知し、必要な教育を行うこと。
• アプリケーション設計において、メールベースのワークフローで発生しうる重複を考慮していること。

このトレードオフにより柔軟性は高まりますが、慎重な実装とユーザーへの明確な周知が必要です。