> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

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

# Non-Unique Emails

Non-Unique Emails を使用すると、同じデータベース接続を共有する複数のユーザーアカウントで 1 つのメールアドレスを利用しながら、別の属性 (ユーザー名や電話番号など) を主識別子として使用できます。たとえば、1 つのメールアドレスで複数の子ども用アカウントを管理する保護者や、拠点ごとに 1 つのメールアドレスを使う小規模事業者でも、Non-Unique Emails を使えば、アカウントごとに安全な login と Password Reset の運用を維持できます。

<div id="considerations">
  ### 検討事項
</div>

以下を確認し、Non-Unique Emails がご利用のユースケースに適しているかをご確認ください。

<div id="primary-identifier-requirements">
  #### 主識別子の要件
</div>

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

識別子と属性の詳細については、[Flexible Identifiers](/docs/ja-jp/authenticate/database-connections/flexible-identifiers-and-attributes) を参照してください。

<div id="password-resets">
  #### パスワードリセット
</div>

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

<div id="irreversible-settings">
  #### 元に戻せない設定
</div>

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

<div id="flexible-identifiers">
  #### Flexible Identifiers
</div>

Non-Unique Emails を使用するには、データベース接続で Flexible Identifiers を有効にする必要があります。これは接続の作成後に無効化できません。<Tooltip tip="" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Management+API">Management API</Tooltip> で Non-Unique Emails を有効にすると、Flexible Identifiers は自動的に自動設定されます。

<div id="api-behavior-changes">
  ### API の動作変更
</div>

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

`DELETE /api/v2/connections/{id}/users` は、非一意メール接続には対応していません。

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

<div id="enable-non-unique-emails-in-the-auth0-dashboard">
  ### Auth0 Dashboard で非一意のメールアドレスを有効にする
</div>

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

<Frame>
  <img src="https://mintcdn.com/translations/mMSz-RNYLuOm2GmQ/docs/images/cdy7uua7fh8z/f65T5K61TGU92hyxFFOHW/ebe7b880185e192ffa8ce4944224205a/image__6_.png?fit=max&auto=format&n=mMSz-RNYLuOm2GmQ&q=85&s=85f7d3da488ee95ff409fe423819d3a6" alt="" width="2206" height="1434" data-path="docs/images/cdy7uua7fh8z/f65T5K61TGU92hyxFFOHW/ebe7b880185e192ffa8ce4944224205a/image__6_.png" />
</Frame>

<div id="enable-non-unique-emails-via-the-management-api">
  ### Management API で Non-Unique Emails を有効にする
</div>

Management API の `POST /api/v2/connections` エンドポイントを使用して、Non-Unique Emails をサポートするデータベース接続を作成します。

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

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

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

<div id="example-request">
  #### リクエストの例
</div>

以下は、ユーザー名を主識別子として使用し、同じメールアドレスを複数のアカウントで利用できるデータベース接続を作成するためのリクエスト本文の例です。

```json lines expandable theme={null}
{
 "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
   }
  }
 }
}
```

<div id="shared-email-risk-disclaimer">
  ### 共有メールに関するリスク免責事項
</div>

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

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

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

* 共有メールの利用が、あなたのユースケースに適していること。
* エンドユーザーに対して適切な案内とトレーニングが行われること。
* メールベースのワークフローで起こり得る重複を考慮したアプリケーション設計になっていること。

このトレードオフにより柔軟性は高まりますが、慎重な実装とユーザーへの明確なコミュニケーションが求められます。