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

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

> パスワードレス接続に関するベストプラクティスを紹介します。

## ログインの実装

Auth0のユニバーサルログインにリダイレクトするか、アプリケーションにログインを埋め込むことで、パスワードレス認証を実装できます。ユニバーサルログインの実装を常に推奨します。その理由については、「[中央集中型のユニバーサルログインと埋め込みログイン](/docs/ja-jp/authenticate/login/universal-vs-embedded-login)」をお読みください。

パスワードレス認証の実装方法の詳細については、以下の記事をお読みください。

* [ユニバーサルログインによるパスワードレス](/docs/ja-jp/authenticate/passwordless/passwordless-with-universal-login)
* [ユニバーサルログインによるパスワードレス認証](/docs/ja-jp/authenticate/passwordless/implement-login/universal-login)
* [埋め込みログインによるパスワードレス認証](/docs/ja-jp/authenticate/passwordless/implement-login/embedded-login)

## SMSとメールを認証要素として使用する

Auth0のパスワードレス実装によって、1つの要素でのユーザー認証が可能になります。その1つの要素は、メールまたはSMSで送られるワンタイムコード、あるいはメールで送られるマジックリンクです。

メールまたはSMSを使用する方が脆弱なパスワードよりも安全ですが、どちらにも既知の問題があります。

* 電話番号はユーザー認証には十分ではありません。[携帯電話ネットワークで使用されているSS7電話ルーティングシステムには脆弱性が確認されているため、](https://thehackernews.com/2017/05/ss7-vulnerability-bank-hacking.html)認証要素としては推奨されません。ソーシャルエンジニアリングの利用からSIMカードの交換やSS7ネットワークへのアクセスの購入に至るまで、利用可能な攻撃ベクターは多く存在します。
* メールアドレスの所有は、ユーザー認証には十分ではありません（例として、エイリアス、転送、1つのアカウントに複数のユーザーがいる状態などが挙げられます）。メールプロバイダーのセキュリティ慣行はそれぞれ異なり、ユーザーの本人確認を求めないプロバイダーもあります。SMTPは非常に古いプロトコルであり、多くのプロバイダーは依然としてSMTPトラフィックを暗号化せずにルーティングしているため、横取り攻撃の可能性が高まります。

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

## フィッシング攻撃を防止する

考えられるフィッシング攻撃の例を以下に示します。

1. ユーザーが悪意のあるメールまたはウェブサイトのリンクをクリックする。
2. ユーザーが攻撃者の偽サイトにアクセスし、認証のために電話番号の入力を促される。
3. ユーザーが電話番号を入力し、攻撃者が正規のアプリケーションにその電話番号を入力する。
4. 正規のアプリケーションがユーザーにSMSを送信する。
5. ユーザーは、攻撃者のウェブサイトでワンタイムコードを入力する。
6. それによって攻撃者は正規のウェブサイトにログインできる。

この攻撃が成功する可能性を下げるため、ユーザーはSMSによってアプリケーションを明確に識別できるようにする必要があります。テナント名および/またはアプリケーション名を示すようにSMSテンプレートを構成する必要があります。

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

## 総当たり攻撃を防止する

Auth0は、総当たり攻撃に対して以下のような保護を行います。

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

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

## ユーザー列挙攻撃を防止する

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

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

**［Disable Sign Ups（サインアップを無効化）］** を有効にした場合、[総当たり攻撃防御](/docs/ja-jp/secure/attack-protection/brute-force-protection)によってこれらの攻撃の脅威を軽減できますが、アプリケーションを完全に保護することはできません。

## アカウントのリンク

ユーザーは、認証に使用するパスワードレス要素を変更したいと思うかもしれません。たとえば、最初はSMSでサインアップし、後にメールでの認証を開始する可能性があります。これは、[アカウントリンク](/docs/ja-jp/manage-users/user-accounts/user-account-linking/link-user-accounts)を使用して、複数のプロファイルをリンクできるようにすることで可能になります。

## レート制限目的でauth0-forwarded-forヘッダーを設定する

`/passwordless/start`エンドポイントは、IPアドレスごとに一時間に50要求の[レート制限](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy)があります。サーバー側からAPIを呼び出す場合、バックエンドのIPがこのレート制限にすぐに達する可能性があります。この問題の対処方法については、「[パスワードレスAPIの使用](/docs/ja-jp/authenticate/passwordless/implement-login/embedded-login/relevant-api-endpoints)」のパスワードレスエンドポイントのレート制限のセクションをご覧ください。