確認済みのメールをユーザープロファイルで使用する
ユーザープロファイルのemail_verifiedフィールドは、ユーザーがメールアドレスを確認したかどうかを示します。メール確認は任意ですが、メールの送信、パスワードのリセット/復元リンク、ユーザーへのパスワードレスメールマジックリンクといった、特定のアクションには有効なメールアドレスが必要です。
メールは通常、ユーザーアカウントが作成された直後か、ユーザーがアプリケーションに初めてログインしたときに確認されます。サインアップを行う当人がその時点でメールアドレスの実際の所有者であると判定するのに有効な方法です。
メール確認はその特定の時点で一度だけ行われるため、後でそのユーザーアカウントにログインした人が確認済みのメールアドレスをまだ所有しているかどうか確かめることはできません。
フェデレーションIDプロバイダーの場合、ユーザーが確認済みのメールを持っているかどうか報告する場合があり、それに基づいて、Auth0はユーザープロファイルのemail_verifiedフィールドを設定します。しかし、この場合、正しく処理を行う責任はIDプロバイダーに移ることになり、当方より確認を取ることはできません。そのプロバイダーから確認されたメールが対象ユーザーによってまだ所有されているかどうか判断することもできません。
こうした理由から、確認済みのメールから何が想定できるか、慎重に考える必要があります。
Auth0はいつメールを確認済みに設定するのか?
ユーザーがメールとパスワードでサインアップを行うと、リンクが入った確認メールが送られてきます。このリンクをクリックすると、Auth0がメールを確認します。詳細については、「メールテンプレートをカスタマイズする」をお読みください。
ユーザーがフェデレーションIDプロバイダー（ソーシャルやエンタープライズ接続など）で認証を行うと、email_verifiedフィールドの値はIDプロバイダーがユーザープロファイルで返す値に一致します。IDプロバイダーが何も値を返さない場合は、falseに設定されます。
確認済みのメールとアカウントのリンク
2つのユーザーアカウントをリンクしたい場合は、ユーザーが両方のアカウントにまだアクセスできることを確認する必要があります。そのための唯一の方法が、両方のアカウントをリンクさせる前ににユーザーに両方のアカウントで認証してもらうことです。
ユーザーのメールに基づいて、アカウントを自動的にリンクさせてはなりません。ユーザーにもう一度必ず認証するよう促してからリンクさせてください。こうすることで、以下のようなシナリオを防ぐことができます。
Travel0の社員であるJohn Doeが、自分の会社メール（
john.doe@travel0.com）とパスワードを使ってサイトにサインアップします。数か月後に会社を辞めた後、同姓同名の別のJohn Doeが新たに採用されます。メールアカウントは同じです。この人物が同じWebサイトにアクセスし、会社のIDプロバイダー（Google Workspaceなど）で認証を行うと、アカウントは別のユーザーに自動的にリンクされてしまいます。フェデレーションIDプロバイダーは、メール確認の処理方法を間違えて、ユーザーが所有していないメールを所有していると報告する場合があります。
その一方で、以下のようなシナリオを軽減するために、アカウントをリンクさせる前に、email_verifiedフィールドを確認することを推奨します。
攻撃者がGoogleアカウント（
attacker@gmail.com）を作成する攻撃者が被害者のメール（
victim@hotmail.comなど）で新しいデータベースユーザーを作成する攻撃者が両方のアカウントをリンクする
攻撃者がフィッシング攻撃を被害者に仕掛ける
被害者がサインアップしようとすると、ユーザーはすでに存在すると言われ、パスワードをリセットするよう求められる
ユーザーがパスワードを入力し攻撃者のアカウントにログインしたため、被害者がアプリケーションで入力するあらゆるデータに不正アクセスされてしまう
確認済みのメールと認可の決定
メールを完全に信用できないのと同じで、メールのドメインも完全に信用してはなりません。
アプリケーションがユーザーの雇用主に基づいてアクセスを制限する必要がある場合、ユーザーが特定の企業ドメインからのメールでログインしているからといって、アクセスが付与されるべきものとして保証するものではありません。
例：
アプリケーションで顧客が新しいアカウントにサインアップし、別の会社の社員が会社の資格情報を使用して認証を行うとします。この場合、
user@acme.comアカウントでサインアップしたユーザーに、acme.comの企業ディレクトリで認証を行うユーザーと同じ機能セットへのアクセスを付与してはなりません。アプリケーションがEntra IDでの認証に対応し、ディレクトリがゲストユーザーに対応している場合、そのEntra IDテナントからログインするどんなドメインのユーザーでもアクセスできてしまいます。そのテナントで認証を行う残りのユーザーと同じアクセスレベルをゲストユーザーに付与してはなりません。
一般には、メールのドメインを使用して認可の決定を行わないよう推奨します。ユーザーが特定のOrganizationに属するかどうか確認する必要がある場合は、認証に使用した接続またはEntra IDのテナントIDなど接続固有の属性を使用するとよいでしょう。