> ## 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="パスワードレス: 第1要素としてパスワードに依存しない認証形式。" cta="用語集を表示" href="/ja/docs/glossary?term=passwordless">パスワードレス</Tooltip> のマジックリンクの送信など、一部の処理では有効なメールアドレスが必要です。

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

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

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

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

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

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

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

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

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

**ユーザーのメールアドレスに基づいてアカウントを自動的にリンクするべきではありません**。その前に、必ずユーザーに再認証を求めてください。これにより、次のような事態を防ぐことができます。

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

一方で、次のような事態を軽減するため、アカウントリンクを行う前に `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 テナントでは任意のドメインのユーザーがログインできます。ゲストユーザーに、そのテナントで認証する他のユーザーと同じアクセスレベルを与えるべきではありません。

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

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

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