Authenticate
Manage Users
Customize
Platformemail_verified フィールドは、そのユーザーがメールアドレスを確認済みかどうかを示します。メールアドレスの確認は必須ではありませんが、メールでの連絡の送信、パスワードリセット/復旧リンクの送信、ユーザーへののマジックリンクの送信など、一部の操作では有効なメールアドレスが必要です。
通常、メールアドレスはユーザーアカウントの作成直後、またはユーザーが初めてアプリケーションにログインしたときに確認されます。これは、その時点でサインアップしている人が実際にそのメールアドレスの所有者であることを確認する有効な方法です。
メールアドレスの確認はその時点で一度だけ行われるため、後でそのユーザーアカウントにログインした人が、確認済みのメールアドレスを引き続き所有していることまでは保証できません。
フェデレーションのの場合、ユーザーのメールアドレスが確認済みかどうかを通知してくることがあり、それに基づいて Auth0 はユーザープロファイルの email_verified フィールドを設定します。ただし、これは適切に実施する責任をアイデンティティプロバイダーに委ねることになり、私たちにはそれを保証できません。また、そのプロバイダーで確認済みとされたメールアドレスを、現在もそのユーザーが所有しているかどうかもわかりません。
こうした理由から、確認済みのメールアドレスに基づいて何を前提にできるかについては、慎重に判断する必要があります。
Auth0 はどのような場合にメールを確認済みとして設定しますか？
ユーザーがメールアドレスとパスワードで新規登録すると、リンク付きの確認メールが送信されます。そのリンクをクリックすると、Auth0 がメールアドレスを確認します。詳しくは、メールテンプレートをカスタマイズする を参照してください。 ユーザーがフェデレーションされたアイデンティティプロバイダー (例: ソーシャル接続またはエンタープライズ接続) で認証する場合、email_verified フィールドの値は、アイデンティティプロバイダーがユーザープロファイルで返す値と一致します。アイデンティティプロバイダーが値を返さない場合は、false に設定されます。
確認済みメールアドレスとアカウントのリンク
2 つのユーザーアカウントをリンクする場合は、ユーザーが現在も両方のアカウントにアクセスできることを確認する必要があります。そのための唯一の方法は、リンクする前にユーザーに両方のアカウントで認証してもらうことです。 ユーザーのメールアドレスに基づいてアカウントを自動的にリンクしてはいけません。そのような処理を行う前に、必ずユーザーに再度認証を求めてください。これにより、次のような事態を防げます。- 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 で認証するほかのユーザーと同じアクセスレベルを与えるべきではありません。