Skip to main content

​
ログインを実装する

認証は、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 トラフィックを暗号化せずに中継しているため、盗聴攻撃を受ける可能性が高まります。
こうした理由から、パスワードレス認証を使用する場合は、ユーザーがセキュリティ上重要な操作を行う際に、異なる要素を用いた 多要素認証 (MFA) も実装することを推奨します。

​
フィッシング攻撃を防ぐ

フィッシング攻撃の一例として、次のような流れが考えられます。
  1. ユーザーが悪意のあるメールやWebサイト内のリンクをクリックします。
  2. ユーザーは攻撃者の偽サイトに誘導され、そこで認証のために電話番号の入力を求められます。
  3. ユーザーが電話番号を入力すると、攻撃者は正規のアプリケーションにも同じ電話番号を入力します。
  4. 正規のアプリケーションからユーザーにSMSが送信されます。
  5. ユーザーがその使い捨てコードを攻撃者のWebサイトに入力します。
  6. その結果、攻撃者は正規のWebサイトにログインできてしまいます。
この攻撃が成功する可能性を低くするには、SMS内でどのアプリケーションから送信されたものかが明確にわかるようにしておく必要があります。SMSテンプレートは、テナント名やアプリケーション名が記載されるように設定してください。

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

Auth0 では、ブルートフォース攻撃に対して次のような保護機能を提供しています。
  • 発行された使い捨てコード (またはリンク) のうち、受け付けられるのは最新の 1 件のみです。新しいものが発行されると、それ以前のものはすべて無効になります。また、最新のものも一度使用すると無効になります。
  • 1 つの使い捨てコードに対する入力失敗は 3 回までです。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 の「Passwordless Endpoints のレート制限」セクションを参照してください。