ユーザープロファイルのDocumentation Index
Fetch the complete documentation index at: https://auth0.generaltranslation.app/llms.txt
Use this file to discover all available pages before exploring further.
email_verifiedフィールドは、ユーザーがメールアドレスを確認したかどうかを示します。メール確認は任意ですが、メールの送信、パスワードのリセット/復元リンク、ユーザーへのパスワードレスメールマジックリンクといった、特定のアクションには有効なメールアドレスが必要です。
メールは通常、ユーザーアカウントが作成された直後か、ユーザーがアプリケーションに初めてログインしたときに確認されます。サインアップを行う当人がその時点でメールアドレスの実際の所有者であると判定するのに有効な方法です。
メール確認はその特定の時点で一度だけ行われるため、後でそのユーザーアカウントにログインした人が確認済みのメールアドレスをまだ所有しているかどうか確かめることはできません。
フェデレーションIDプロバイダーの場合、ユーザーが確認済みのメールを持っているかどうか報告する場合があり、それに基づいて、Auth0はユーザープロファイルのemail_verifiedフィールドを設定します。しかし、この場合、正しく処理を行う責任はIDプロバイダーに移ることになり、当方より確認を取ることはできません。そのプロバイダーから確認されたメールが対象ユーザーによってまだ所有されているかどうか判断することもできません。
こうした理由から、確認済みのメールから何が想定できるか、慎重に考える必要があります。
Auth0はいつメールを確認済みに設定するのか?
email_verifiedフィールドの値はIDプロバイダーがユーザープロファイルで返す値に一致します。IDプロバイダーが何も値を返さない場合は、falseに設定されます。
確認済みのメールとアカウントのリンク
- 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テナントからログインするどんなドメインのユーザーでもアクセスできてしまいます。そのテナントで認証を行う残りのユーザーと同じアクセスレベルをゲストユーザーに付与してはなりません。