> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> パスワードレス接続を使用する際のベストプラクティスについて説明します。

# パスワードレス接続のベストプラクティス

<div id="implement-login">
  ## ログインの実装
</div>

<Tooltip tip="パスワードレス: 第1要素としてパスワードに依存しない認証形式です。" cta="用語集を表示" href="/ja/docs/glossary?term=Passwordless">パスワードレス</Tooltip>認証は、Auth0 の <Tooltip tip="パスワードレス: 第1要素としてパスワードに依存しない認証形式です。" cta="用語集を表示" href="/ja/docs/glossary?term=Universal+Login">Universal Login</Tooltip> にリダイレクトするか、アプリケーションにログイン機能を埋め込むことで実装できます。Auth0 では、Universal Login の実装を常に推奨しています。その理由については、[集中管理型 Universal Login と埋め込みログイン](/ja/docs/authenticate/login/universal-vs-embedded-login)を参照してください。

パスワードレス認証の実装方法については、以下の記事を参照してください。

* [Universal Login でパスワードレスを使用する](/ja/docs/authenticate/passwordless/passwordless-with-universal-login)
* [Universal Login を使用したパスワードレス認証](/ja/docs/authenticate/passwordless/implement-login/universal-login)
* [埋め込みログインを使用したパスワードレス認証](/ja/docs/authenticate/passwordless/implement-login/embedded-login)

<div id="use-sms-and-email-as-authentication-factors">
  ## SMS とメールアドレスを認証要素として使用する
</div>

Auth0 のパスワードレス実装では、単一の要素でユーザーを認証できます。その単一要素として使用できるのは、メールアドレスまたは SMS で送信される使い捨てのワンタイムコード、あるいはメールアドレスで送信されるマジックリンクです。

メールアドレスや SMS は、脆弱なパスワードより安全な場合もありますが、どちらにも既知の問題があります。

* 電話番号だけでは、ユーザー認証には十分ではありません。[携帯電話ネットワークで使用される SS7 電話ルーティングシステムには、確認済みの脆弱性があります](https://thehackernews.com/2017/05/ss7-vulnerability-bank-hacking.html)。そのため、認証要素としては推奨されていません。攻撃経路は数多く存在し、ソーシャルエンジニアリングの悪用から、SIM カードの差し替え、SS7 ネットワークへのアクセス権の購入まで多岐にわたります。
* メールアドレスを保有しているだけでは、ユーザー認証には十分ではありません (エイリアス、転送、1 つのアカウントを複数のユーザーで共有しているケースなどがその例です) 。メールプロバイダーによってセキュリティ対策は異なり、ユーザーの本人確認をまったく要求しないものもあります。SMTP は非常に古いプロトコルであり、多くのプロバイダーでは現在でも SMTP トラフィックが暗号化されずにルーティングされているため、傍受攻撃を受ける可能性が高まります。

これらの理由から、パスワードレス認証を使用する場合は、ユーザーがセキュリティ上重要な操作を実行するときに、別の要素を使用した [多要素認証 (MFA)](/ja/docs/secure/multi-factor-authentication) も実装することを推奨します。

<div id="prevent-phishing-attacks">
  ## フィッシング攻撃を防ぐ
</div>

フィッシング攻撃の例として、次のようなものが考えられます。

1. ユーザーが、悪意のあるメールや Web サイト内のリンクをクリックします。
2. ユーザーは攻撃者が用意した偽サイトに誘導され、そこで認証のために電話番号の入力を求められます。
3. ユーザーが電話番号を入力すると、攻撃者は同じ電話番号を正規のアプリケーションに入力します。
4. 正規のアプリケーションがユーザーに SMS を送信します。
5. ユーザーがワンタイムコードを攻撃者の Web サイトに入力します。
6. すると、攻撃者は正規の Web サイトにログインできるようになります。

この攻撃が成功する可能性を下げるには、SMS にアプリケーションを明確に識別できる情報が含まれていることを、ユーザーが確認できるようにする必要があります。SMS テンプレートには、テナント名やアプリケーション名、またはその両方が記載されるように設定してください。

```http wrap lines theme={null}
Your verification code for accessing's Acme @@application.name@@ is @@code@@
```

<div id="prevent-brute-force-attacks">
  ## ブルートフォース攻撃を防ぐ
</div>

Auth0 には、ブルートフォース攻撃に対する次の保護機能があります。

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

ワンタイムコードの有効期限は、[Auth0 Dashboard > Authentication > Passwordless](https://manage.auth0.com/#/connections/passwordless) で変更できます。

<div id="prevent-user-enumeration-attacks">
  ## ユーザー列挙攻撃を防ぐ
</div>

ユーザー列挙とは、悪意のある攻撃者が総当たりの手法を使って、システム内の有効なユーザーを推測または確認することです。

**Disable Sign Ups** を有効にすると、アプリケーションがユーザー列挙攻撃に対して脆弱になる可能性があります。アプリケーションとそのユーザーのセキュリティを最大限に確保するため、Auth0 ではこの設定を有効にしないことを推奨しています。

**Disable Signs Ups** を有効にする場合でも、[Brute-force Protection](/ja/docs/secure/attack-protection/brute-force-protection) によってこれらの攻撃の一部は軽減できる可能性がありますが、アプリケーションを完全に保護できるわけではありません。

<div id="link-accounts">
  ## アカウントをリンクする
</div>

ユーザーは、利用していく中で別のパスワードレス認証要素を使って認証したくなることがあります。たとえば、最初は SMS でサインアップし、その後はメールアドレスで認証するようになる場合があります。これを実現するには、[アカウントリンク](/ja/docs/manage-users/user-accounts/user-account-linking/link-user-accounts)を有効にして、異なるプロフィールをリンクできるようにします。

<div id="set-the-auth0-forwarded-for-header-for-rate-limit-purposes">
  ## レート制限対応のために auth0-forwarded-for ヘッダーを設定する
</div>

`/passwordless/start` エンドポイントには、IP アドレスごとに 1 時間あたり 50 リクエストの[レート制限](/ja/docs/troubleshoot/customer-support/operational-policies/rate-limit-policy)があります。サーバーサイドから API を呼び出す場合、バックエンドの IP アドレスがこのレート制限に達しやすくなります。この問題への対処方法については、[Using Passwordless APIs](/ja/docs/authenticate/passwordless/implement-login/embedded-login/relevant-api-endpoints) の「Rate Limiting in Passwordless Endpoints」セクションを参照してください。