> ## 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.

> ユーザープロファイルにおける email_verified フィールドの適切な使用方法を説明します。

# ユーザープロファイルで確認済みメールアドレスを使用する

ユーザープロファイルの `email_verified` フィールドは、そのユーザーがメールアドレスを確認済みかどうかを示します。メールアドレスの確認は必須ではありませんが、メールでの連絡の送信、パスワードリセット/復旧リンクの送信、ユーザーへの<Tooltip tip="Passwordless: パスワードを第一の認証要素として使わない認証方式。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=passwordless">パスワードレス</Tooltip>のマジックリンクの送信など、一部の操作では有効なメールアドレスが必要です。

通常、メールアドレスはユーザーアカウントの作成直後、またはユーザーが初めてアプリケーションにログインしたときに確認されます。これは、その時点でサインアップしている人が実際にそのメールアドレスの所有者であることを確認する有効な方法です。

メールアドレスの確認はその時点で一度だけ行われるため、後でそのユーザーアカウントにログインした人が、確認済みのメールアドレスを引き続き所有していることまでは保証できません。

フェデレーションの<Tooltip tip="Identity Provider (IdP): デジタルアイデンティティを保存および管理するサービス。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=identity+providers">アイデンティティプロバイダー</Tooltip>の場合、ユーザーのメールアドレスが確認済みかどうかを通知してくることがあり、それに基づいて Auth0 はユーザープロファイルの `email_verified` フィールドを設定します。ただし、これは適切に実施する責任をアイデンティティプロバイダーに委ねることになり、私たちにはそれを保証できません。また、そのプロバイダーで確認済みとされたメールアドレスを、現在もそのユーザーが所有しているかどうかもわかりません。

こうした理由から、確認済みのメールアドレスに基づいて何を前提にできるかについては、慎重に判断する必要があります。

<div id="when-does-auth0-set-emails-as-verified">
  ## Auth0 はどのような場合にメールを確認済みとして設定しますか？
</div>

ユーザーがメールアドレスとパスワードで新規登録すると、リンク付きの確認メールが送信されます。そのリンクをクリックすると、Auth0 がメールアドレスを確認します。詳しくは、[メールテンプレートをカスタマイズする](/docs/ja-jp/customize/email/email-templates) を参照してください。

ユーザーがフェデレーションされたアイデンティティプロバイダー (例: ソーシャル接続またはエンタープライズ接続) で認証する場合、`email_verified` フィールドの値は、アイデンティティプロバイダーがユーザープロファイルで返す値と一致します。アイデンティティプロバイダーが値を返さない場合は、`false` に設定されます。

<div id="verified-emails-and-account-linking">
  ## 確認済みメールアドレスとアカウントのリンク
</div>

[2 つのユーザーアカウントをリンクする](/docs/ja-jp/manage-users/user-accounts/user-account-linking)場合は、ユーザーが現在も両方のアカウントにアクセスできることを確認する必要があります。そのための唯一の方法は、リンクする前にユーザーに両方のアカウントで認証してもらうことです。

**ユーザーのメールアドレスに基づいてアカウントを自動的にリンクしてはいけません**。そのような処理を行う前に、必ずユーザーに再度認証を求めてください。これにより、次のような事態を防げます。

* Travel0 の従業員である John Doe が、会社のメールアドレス `john.doe@travel0.com` とパスワードを使ってサイトにサインアップします。数か月後、John Doe は Travel0 を退職し、同じメールアカウントを持つ新しい John Doe が採用されます。その人が同じ Web サイトにアクセスし、会社のアイデンティティプロバイダー (Google Workspace など) で認証すると、別のユーザーのアカウントに自動的にリンクされてしまいます。
* フェデレーションされたアイデンティティプロバイダーでは、メールアドレスの確認の扱いを誤り、ユーザーが実際には所有していないメールアドレスを所有していると報告してしまうことがあります。

一方で、次のような事態を軽減するために、アカウントをリンクする前に `email_verified` フィールドを確認することは引き続き推奨されます。

* 攻撃者が Google アカウント `attacker@gmail.com` を作成します。
* 攻撃者が被害者のメールアドレス (例: `victim@hotmail.com`) で新しいデータベースユーザーを作成します。
* 攻撃者が両方のアカウントをリンクします。
* 攻撃者が被害者にフィッシング攻撃を仕掛けます。
* 被害者がサインアップしようとすると、ユーザーはすでに存在すると表示され、パスワードのリセットを案内されます。
* ユーザーがパスワードを入力して攻撃者のアカウントにログインすると、そのアカウントは被害者がアプリケーションに入力したあらゆるデータにアクセスできるようになります。

<div id="verified-emails-and-authorization-decisions">
  ## 確認済みメールアドレスと認可の判断
</div>

メールアドレスを完全に信頼できないのと同様に、メールドメインも完全に信頼できるわけではありません。

アプリケーションで、ユーザーの勤務先に基づいてアクセスを制限する必要がある場合でも、特定の企業ドメインのメールアドレスでユーザーがログインしているという事実だけで、そのユーザーにアクセスを許可すべきとは限りません。

例えば、次のようなケースです。

* アプリケーションで顧客が新規アカウントを登録でき、異なる企業の従業員がそれぞれ自社の資格情報を使って認証する場合、`user@acme.com` アカウントで登録したユーザーに、acme.com の企業ディレクトリで認証するユーザーと同じ機能へのアクセスを許可すべきではありません。
* アプリケーションが Azure AD による認証をサポートしており、そのディレクトリがゲストユーザーをサポートしている場合、その Azure AD tenant では、任意のドメインのユーザーがログインできる可能性があります。ゲストユーザーに、その tenant で認証するほかのユーザーと同じアクセスレベルを与えるべきではありません。

一般的な推奨事項として、**認可の判断にメールアドレスのドメインを使用するべきではありません**。ユーザーが特定の organization に属しているかどうかを確認する必要がある場合は、認証に使用した接続や、Azure AD の tenant id のような接続固有の属性を利用するほうが適切です。

<div id="learn-more">
  ## 詳しくはこちら
</div>

* [ユーザーアカウントをリンクする](/docs/ja-jp/manage-users/user-accounts/user-account-linking/link-user-accounts)
* [ユーザー主導のアカウントリンク: クライアントサイド実装](/docs/ja-jp/manage-users/user-accounts/user-account-linking/user-initiated-account-linking-client-side-implementation)
* [ユーザーアカウントのリンク: サーバーサイド実装](/docs/ja-jp/manage-users/user-accounts/user-account-linking/suggested-account-linking-server-side-implementation)