ログインを実装する
認証は、Auth0 の にリダイレクトする方法、アプリケーションにログインを組み込む方法、または同じアプリ内で両方を組み合わせる方法で実装できます。 Auth0 にログイン画面をホストさせ、更新をシームレスに提供したい場合、Universal Login は適切なデフォルトです。UI/UX を完全に制御したい場合や、Passkey APIs または Native Social Login を使用したネイティブエクスペリエンスを構築する場合は、組み込みログインが適しています。多くのアプリケーションでは、主要なサインインには Universal Login を使用し、アプリ内でのパスキーの登録、認証要素の管理、またはステップアップ認証には組み込みフローを使用します。トレードオフを比較するには、Hosted Login vs. 埋め込みログイン を参照してください。 パスワードレス 認証の実装方法については、以下の記事を参照してください。認証要素として SMS とメールを使用する
Auth0 のパスワードレス実装では、単一の要素でユーザーを認証できます。その単一の要素として使用できるのは、メールまたは SMS で送信される使い捨てコード、あるいはメールで送信されるマジックリンクです。 メールや SMS は、脆弱なパスワードより安全な場合もありますが、どちらにも既知の問題があります。- 電話番号だけでは、ユーザー認証の要素として十分ではありません。携帯電話ネットワークで使用されている SS7 電話ルーティングシステムには、確認済みの脆弱性があります。そのため、認証要素としては推奨されていません。攻撃経路は数多くあり、ソーシャルエンジニアリングの悪用から、SIM カードの差し替え、SS7 ネットワークへのアクセス権の購入まで、さまざまなものがあります。
- メールアドレスを所有しているだけでは、ユーザー認証の要素として十分ではありません (エイリアス、転送、1 つのアカウントを複数ユーザーで共有しているケースなどがその例です) 。メールプロバイダーごとにセキュリティ対策は異なり、中にはユーザーの本人確認をまったく求めないものもあります。SMTP は非常に古いプロトコルであり、現在でも多くのプロバイダーが SMTP トラフィックを暗号化せずに中継しているため、盗聴攻撃を受ける可能性が高まります。
フィッシング攻撃を防ぐ
フィッシング攻撃の一例として、次のような流れが考えられます。- ユーザーが悪意のあるメールやWebサイト内のリンクをクリックします。
- ユーザーは攻撃者の偽サイトに誘導され、そこで認証のために電話番号の入力を求められます。
- ユーザーが電話番号を入力すると、攻撃者は正規のアプリケーションにも同じ電話番号を入力します。
- 正規のアプリケーションからユーザーにSMSが送信されます。
- ユーザーがその使い捨てコードを攻撃者のWebサイトに入力します。
- その結果、攻撃者は正規のWebサイトにログインできてしまいます。
ブルートフォース攻撃を防ぐ
Auth0 では、ブルートフォース攻撃に対して次のような保護機能を提供しています。- 発行された使い捨てコード (またはリンク) のうち、受け付けられるのは最新の 1 件のみです。新しいものが発行されると、それ以前のものはすべて無効になります。また、最新のものも一度使用すると無効になります。
- 1 つの使い捨てコードに対する入力失敗は 3 回までです。3 回失敗すると、新しいコードをリクエストする必要があります。
- 発行された使い捨てコードは、失効するまで 3 分間 (デフォルト) 有効です。
- パスワードレスユーザーが管理上ブロックされている場合、ユーザーのブロックが解除されるまで、Auth0 は SMS やメールで OTP コードを送信しません。この動作により、SMS プロバイダーやメールプロバイダーへの不要なリクエストを防ぐことができます。
ユーザー列挙攻撃を防ぐ
ユーザー列挙とは、悪意のある第三者が総当たり攻撃の手法を用いて、システム内の有効なユーザーを推測または特定することです。 Disable Sign Ups を有効にすると、アプリケーションがユーザー列挙攻撃を受けやすくなる可能性があります。アプリケーションとユーザーの安全性を最大限に確保するため、Auth0 はこの設定を有効にしないことを推奨しています。 それでも Disable Signs Ups を有効にする場合は、Brute-force Protection によってこうした攻撃の一部は緩和できる可能性がありますが、アプリケーションを完全に保護できるわけではありません。アカウントをリンクする
ユーザーは、利用する中で異なるパスワードレス認証手段を使いたい場合があります。たとえば、最初は SMS で登録し、その後はメールで認証するようになることがあります。これは、アカウントのリンクを使って異なるプロフィール同士をリンクできるようにすることで実現できます。レート制限対策として auth0-forwarded-for ヘッダーを設定する
/passwordless/start エンドポイントには、IP アドレスごとに 1 時間あたり 50 リクエストのレート制限があります。サーバーサイドから API を呼び出す場合、バックエンドの IP アドレスがこのレート制限に達してしまうことがあります。この問題への対処方法については、Using Passwordless APIs の「Passwordless Endpoints のレート制限」セクションを参照してください。