認証
ユーザー管理
カスタマイズ
プラットフォームemail_verified フィールドは、そのユーザーがメールアドレスを確認済みかどうかを示します。メールアドレスの確認は必須ではありませんが、メールでの連絡の送信、パスワードリセット/復旧リンクの送信、ユーザーへののマジックリンクの送信など、一部の操作では有効なメールアドレスが必要です。
通常、メールアドレスはユーザーアカウントの作成直後、またはユーザーが初めてアプリケーションにログインしたときに確認されます。これは、その時点でサインアップしている人が実際にそのメールアドレスの所有者であることを確認する有効な方法です。
メールアドレスの確認はその時点で一度だけ行われるため、後でそのユーザーアカウントにログインした人が、確認済みのメールアドレスを引き続き所有していることまでは保証できません。
フェデレーションのの場合、ユーザーのメールアドレスが確認済みかどうかを通知してくることがあり、それに基づいて Auth0 はユーザープロファイルの email_verified フィールドを設定します。ただし、これは適切に実施する責任をアイデンティティプロバイダーに委ねることになり、私たちにはそれを保証できません。また、そのプロバイダーで確認済みとされたメールアドレスを、現在もそのユーザーが所有しているかどうかもわかりません。
こうした理由から、確認済みのメールアドレスに基づいて何を前提にできるかについては、慎重に判断する必要があります。
Auth0 はどのような場合にメールを確認済みとして設定しますか？
email_verified フィールドの値は、アイデンティティプロバイダーがユーザープロファイルで返す値と一致します。アイデンティティプロバイダーが値を返さない場合は、false に設定されます。
確認済みメールアドレスとアカウントのリンク
- Travel0 の従業員である John Doe が、会社のメールアドレス
john.doe@travel0.comとパスワードを使ってサイトにサインアップします。数か月後、John Doe は Travel0 を退職し、同じメールアカウントを持つ新しい John Doe が採用されます。その人が同じ Web サイトにアクセスし、会社のアイデンティティプロバイダー (Google Workspace など) で認証すると、別のユーザーのアカウントに自動的にリンクされてしまいます。 - フェデレーションされたアイデンティティプロバイダーでは、メールアドレスの確認の扱いを誤り、ユーザーが実際には所有していないメールアドレスを所有していると報告してしまうことがあります。
email_verified フィールドを確認することは引き続き推奨されます。
- 攻撃者が Google アカウント
attacker@gmail.comを作成します。 - 攻撃者が被害者のメールアドレス (例:
victim@hotmail.com) で新しいデータベースユーザーを作成します。 - 攻撃者が両方のアカウントをリンクします。
- 攻撃者が被害者にフィッシング攻撃を仕掛けます。
- 被害者がサインアップしようとすると、ユーザーはすでに存在すると表示され、パスワードのリセットを案内されます。
- ユーザーがパスワードを入力して攻撃者のアカウントにログインすると、そのアカウントは被害者がアプリケーションに入力したあらゆるデータにアクセスできるようになります。
- アプリケーションで顧客が新規アカウントを登録でき、異なる企業の従業員がそれぞれ自社の資格情報を使って認証する場合、
user@acme.comアカウントで登録したユーザーに、acme.com の企業ディレクトリで認証するユーザーと同じ機能へのアクセスを許可すべきではありません。 - アプリケーションが Azure AD による認証をサポートしており、そのディレクトリがゲストユーザーをサポートしている場合、その Azure AD tenant では、任意のドメインのユーザーがログインできる可能性があります。ゲストユーザーに、その tenant で認証するほかのユーザーと同じアクセスレベルを与えるべきではありません。