認証
ユーザー管理
カスタマイズ
Auth0 AI
プラットフォームemail_verified フィールドは、ユーザーがメールアドレスを確認済みかどうかを示します。メールアドレスの確認は任意ですが、メール送信、パスワードのリセットや回復用リンクの送信、ユーザーへの のマジックリンクの送信など、一部の処理では有効なメールアドレスが必要です。
通常、メールアドレスはユーザーアカウントの作成直後、またはユーザーが初めてアプリケーションにログインした際に確認されます。これにより、その時点では、サインアップした本人が実際にそのメールアドレスを所有していることを確認できます。
ただし、メールアドレスの確認はその時点で一度だけ行われるため、後になってそのユーザーアカウントでログインした人物が、確認済みのメールアドレスを引き続き所有していることまでは保証できません。
フェデレーションされた の場合、ユーザーのメールアドレスが確認済みであるかどうかを通知することがあり、Auth0 はそれに基づいてユーザープロファイルの email_verified フィールドを設定します。ただし、この場合はその確認を適切に行う責任が IDプロバイダー に委ねられるため、Auth0 ではそれを保証できません。また、そのプロバイダーで確認済みとされたメールアドレスを、現在もそのユーザーが所有しているかどうかも分かりません。
これらの理由から、確認済みメールアドレスに基づいて何を前提にできるかについては、慎重に判断する必要があります。
Auth0 はどのような場合にメールアドレスを確認済みに設定しますか？
email_verified フィールドの値は、IDプロバイダーがユーザープロファイルで返す値と一致します。IDプロバイダーが値を返さない場合は、false に設定されます。
確認済みメールアドレスとアカウントリンク
- 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) を使って新しいデータベースユーザーを作成します。 - 攻撃者が両方のアカウントをリンクします。
- 攻撃者が被害者にフィッシング攻撃を仕掛けます。
- 被害者がサインアップしようとすると、すでにユーザーが存在すると表示され、パスワードのリセットを案内されます。
- ユーザーがパスワードを入力して攻撃者のアカウントにログインしてしまい、その結果、そのアカウントから被害者がアプリケーションに入力したあらゆるデータにアクセスできるようになります。
- アプリケーションで顧客が新しいアカウントにサインアップでき、異なる企業の従業員がそれぞれ自社の認証情報を使って認証する場合、
user@acme.comアカウントでサインアップしたユーザーには、acme.com の企業ディレクトリで認証したユーザーと同じ機能へのアクセスを許可すべきではありません。 - アプリケーションが Azure AD による認証をサポートしていて、そのディレクトリがゲストユーザーをサポートしている場合、その Azure AD テナントでは任意のドメインのユーザーがログインできます。ゲストユーザーに、そのテナントで認証する他のユーザーと同じアクセスレベルを与えるべきではありません。