メインコンテンツへスキップ

ログインの実装

認証は、Auth0 の にリダイレクトするか、アプリケーションにログイン機能を埋め込むことで実装できます。Auth0 では、Universal Login の実装を常に推奨しています。その理由については、集中管理型 Universal Login と埋め込みログインを参照してください。 パスワードレス認証の実装方法については、以下の記事を参照してください。

SMS とメールアドレスを認証要素として使用する

Auth0 のパスワードレス実装では、単一の要素でユーザーを認証できます。その単一要素として使用できるのは、メールアドレスまたは SMS で送信される使い捨てのワンタイムコード、あるいはメールアドレスで送信されるマジックリンクです。 メールアドレスや SMS は、脆弱なパスワードより安全な場合もありますが、どちらにも既知の問題があります。
  • 電話番号だけでは、ユーザー認証には十分ではありません。携帯電話ネットワークで使用される SS7 電話ルーティングシステムには、確認済みの脆弱性があります。そのため、認証要素としては推奨されていません。攻撃経路は数多く存在し、ソーシャルエンジニアリングの悪用から、SIM カードの差し替え、SS7 ネットワークへのアクセス権の購入まで多岐にわたります。
  • メールアドレスを保有しているだけでは、ユーザー認証には十分ではありません (エイリアス、転送、1 つのアカウントを複数のユーザーで共有しているケースなどがその例です) 。メールプロバイダーによってセキュリティ対策は異なり、ユーザーの本人確認をまったく要求しないものもあります。SMTP は非常に古いプロトコルであり、多くのプロバイダーでは現在でも SMTP トラフィックが暗号化されずにルーティングされているため、傍受攻撃を受ける可能性が高まります。
これらの理由から、パスワードレス認証を使用する場合は、ユーザーがセキュリティ上重要な操作を実行するときに、別の要素を使用した 多要素認証 (MFA) も実装することを推奨します。

フィッシング攻撃を防ぐ

フィッシング攻撃の例として、次のようなものが考えられます。
  1. ユーザーが、悪意のあるメールや Web サイト内のリンクをクリックします。
  2. ユーザーは攻撃者が用意した偽サイトに誘導され、そこで認証のために電話番号の入力を求められます。
  3. ユーザーが電話番号を入力すると、攻撃者は同じ電話番号を正規のアプリケーションに入力します。
  4. 正規のアプリケーションがユーザーに SMS を送信します。
  5. ユーザーがワンタイムコードを攻撃者の Web サイトに入力します。
  6. すると、攻撃者は正規の Web サイトにログインできるようになります。
この攻撃が成功する可能性を下げるには、SMS にアプリケーションを明確に識別できる情報が含まれていることを、ユーザーが確認できるようにする必要があります。SMS テンプレートには、テナント名やアプリケーション名、またはその両方が記載されるように設定してください。
Your verification code for accessing's Acme @@application.name@@ is @@code@@

ブルートフォース攻撃を防ぐ

Auth0 には、ブルートフォース攻撃に対する次の保護機能があります。
  • 発行されたワンタイムコード (またはリンク) のうち、受け付けられるのは最新のものだけです。新しいコードが発行されると、それ以前のものはすべて無効になります。最新のコードも、一度使用されると無効になります。
  • 1 つのワンタイムコードに対して許可される入力失敗は 3 回までです。これを超えた場合は、新しいコードをリクエストする必要があります。
  • 発行されたワンタイムコードは、期限切れになるまで 3 分間 (デフォルト) 有効です。
  • パスワードレスのユーザーが管理者によってブロックされている場合、ユーザーのブロックが解除されるまで、Auth0 は SMS またはメールで OTP コードを送信しません。この動作により、SMS プロバイダーやメールプロバイダーに不要なリクエストが送られるのを防ぎます。
ワンタイムコードの有効期限は、Auth0 Dashboard > Authentication > Passwordless で変更できます。

ユーザー列挙攻撃を防ぐ

ユーザー列挙とは、悪意のある攻撃者が総当たりの手法を使って、システム内の有効なユーザーを推測または確認することです。 Disable Sign Ups を有効にすると、アプリケーションがユーザー列挙攻撃に対して脆弱になる可能性があります。アプリケーションとそのユーザーのセキュリティを最大限に確保するため、Auth0 ではこの設定を有効にしないことを推奨しています。 Disable Signs Ups を有効にする場合でも、Brute-force Protection によってこれらの攻撃の一部は軽減できる可能性がありますが、アプリケーションを完全に保護できるわけではありません。 ユーザーは、利用していく中で別のパスワードレス認証要素を使って認証したくなることがあります。たとえば、最初は SMS でサインアップし、その後はメールアドレスで認証するようになる場合があります。これを実現するには、アカウントリンクを有効にして、異なるプロフィールをリンクできるようにします。

レート制限対応のために auth0-forwarded-for ヘッダーを設定する

/passwordless/start エンドポイントには、IP アドレスごとに 1 時間あたり 50 リクエストのレート制限があります。サーバーサイドから API を呼び出す場合、バックエンドの IP アドレスがこのレート制限に達しやすくなります。この問題への対処方法については、Using Passwordless APIs の「Rate Limiting in Passwordless Endpoints」セクションを参照してください。