テナントへの要求がレート制限を受けていることを確認する
顧客の製品がAuth0のレート制限を受けているかを確認するには、いくつかの方法があります。可能性のあるレート制限の原因については、以下を参照してください。テナントログ
、「ログ」をお読みください。api_limit
api_limitイベントは、特定のレート制限バケットでレート制限を超過すると即座にトリガーされます。1分経っても同じレート制限バケットでレート制限が超過したままの場合には、2つ目のログが作成されます。別のレート制限バケットでレート制限が超過した場合には、新たにapi_limitイベントが生成されます。そうすることで、どのレート制限の構成にAPI呼び出しが抵触しているのかを特定できます。これは根本原因を診断する重要な第一歩になります。
api_limit_warning
api_limit_warningログは、特定のレート制限バケットについて、要求トークンの80%が顧客の要求レートによって使用されている場合にトリガーされます。利用されている要求トークンの数が1分経っても同じレート制限バケットで80%を超えたままの場合には、2つ目の警告ログが生成されます。別のレート制限バケットで80%のしきい値を超えた場合には、新たにapi_limit_warningログが作成されます。
appi（パブリックパフォーマンスバーストのみ）
appiログは、パブリックパフォーマンスバーストアドオンのある顧客テナントがサステイン時のAuthentication API要求のレート制限である100 RPSを超過し、48時間のバースト割り当ての15分ブロックを消費するとトリガーされます。15分経ってもサステイン時の要求上限である100 RPSを超過したままの場合には、2つ目のappiログがトリガーされます。
API応答
Auth0のAPI応答は、HTTP 429 (Too Many Requests)応答に超過したレート制限を含めて送信します。これによって、レート制限の適用をリアルタイムで観察することができます。ただし、これはカスタムで構築された顧客のアプリケーションがAuth0 APIと直接やり取りする場合にのみ役立ちます。SDKエラーの処理
SDKを使用している場合には、Management APIのSDKライブラリーのエラーページを参照してください。エラーページ
エラーページ応答は、エンドユーザーにHTMLコンテンツを表示するエンドポイントに対して送信されます。テナントに（Auth0がホストする）汎用ページの使用が構成されている場合には、応答制限が超過すると、Auth0は予期されるページではなく、エラーページを表示します。 テナントにカスタムのエラーページの使用が構成されている場合には、クエリ文字列パラメーターのerror_descriptionに関連エラーを含めて、エラーページのURLにユーザーがリダイレクトされます。 詳細については、影響を受けるエンドポイントとJSONエラーの説明を参照してください。
テナントがレート制限を受けている理由を調べる
テナント要求がレート制限を受けていると思われ、その理由を知るのに手助けが必要な場合には、サポートセンターを通してリクエストしてください。 リクエストには、問題を示している生のログを含めてください。テナントへの要求がレート制限を受ける時期を予測する
Auth0は、レート制限ポリシーが構成されているエンドポイントからHTTP応答ヘッダーを使用して、レート制限の現在のステータスについて最新情報を報告します。このステータスでは以下が通知されます。x-ratelimit-limit：使用可能な要求数の上限です。x-ratelimit-remaining：バケットに要求数が補充されるまでの残りの要求数です。x-ratelimit-reset：バケットに要求数が補充される予測時間を秒単位で表したUNIXタイムスタンプです。
- バースト制限：
1000 - 持続的レート制限：
100``RPS（固定ウィンドウ）
- 持続的レート制限は固定ウィンドウで
100RPSです。 - 固定ウィンドウのため、要求のバケットは毎秒補充されます。
x-ratelimit-limit: 1000x-ratelimit-remaining: 50x-ratelimit-reset: 1675452600
- テナントがそのAPIに対する要求数1000中の950をすでに使用し、要求数が補充されるまでに残っている要求数は50のみである
- 新しい要求数が
1675452600秒後（2023年2月3日7:30:00 PM UTC）に補充される - そのときに新たに1つの要求が追加される
レート制限を受ける仕組みの例
RPSの例
Auth0が/ratelimitexampleという新しいAPIの提供を開始し、以下のレート制限があるとします。
- バースト制限：5件の要求
- 持続的レート制限：10RPS。
- APIは5つの要求トークンから始まり、それが上限で、これはバースト制限と同じです。
- 固定ウィンドウを使用して、10個のトークンを保持したバケットが1秒ごとに補充されます。 新しいトークンがバケットに追加され、各秒の「頭」でバケットを補充します。
- T0 - T1秒： エンドユーザーが最初の1秒で6つの要求を行います。 バースト制限と同等の5つの要求は
200応答を受信します。 6つ目の要求は、バケットに要求トークンが残っていないため429エラーを受信します。 - T1秒 - T2秒： 固定ウィンドウのアルゴリズムにより要求トークンのバケットが満たされます。その結果、7つ目から11つ目の要求は成功し、12つ目の要求でバケットが空になり、
429エラーとなります。 - T2秒 - T3秒： 再びトークンバケットが補充されて、次の要求（13）で
200応答を受信します。
RPMの例
Auth0が/ratelimitexample2という新しいAPIの提供を開始し、以下のレート制限があるとします。
- バースト制限： 5件の要求
- 持続的レート制限： 6RPM。
- APIは5つの要求トークンから始まり、バースト制限と同じです。
- 固定ウィンドウを使用して、6個のトークンを保持したバケットが1分ごとに補充されます。 新しいトークンがバケットに追加され、毎分の「頭」でバケットを補充します。
- T0 - T+1分： エンドユーザーが最初の1分で6つの要求を行います。 バースト制限と同等の5つの要求は
200応答を受信します。 6つ目の要求は、要求トークンが残っていないため429エラーを受信します。 - T+1分 - T+2分： 固定ウィンドウのアルゴリズムにより要求トークンのバケットが満たされます。その結果、7つ目から11つ目の要求は成功し、12つ目の要求でバケットが空になり
429エラーとなります。 - T+2分：再びトークンバケットが補充されて、次の要求（13）で
200応答を受信します。
その他のシナリオ
Auth0は時には1つのAPIに2つのレート制限を割り当てることがあります。 これは、サービスの需要に合わせて、バースト制限と持続的レート制限の構成をさらにカスタマイズするためです。 その結果、最初のレート制限が実施されるバースト制限になり、2番目のレート制限が実施される持続的レート制限になります。 このシナリオでは、Auth0は実際のバースト制限と持続的レート制限ではなく、実施されるバースト制限と持続的レート制限のみを公開します。エンドユーザーのログインとサインアップAPIの使用
認証フローには、ログイン、サインアップ、パスワード変更などいくつかがあります。このうち最も一般的なものがログインで、その次がサインアップです。 エンドユーザーがログインすると、Authentication APIエンドポイントへの複数のAPI呼び出しが始まります。これによって、エンドユーザーに認可トークンの受信が許可されているかを判断し、要求したアプリケーションにアクセスします。 API呼び出しを行う正確な数は、以下のいくつかの構成に応じて異なります。- 認証エクスペリエンス（新しいユニバーサルログイン、クラシックログインなど）
- 認証フロー（ログイン、サインアップ、パスワード変更など）
- 認証フロータイプ（ユーザー名/パスワードを介したログイン、ソーシャルログインを介したログイン、既存の認証トークンがすでに存在するときのログインなど）
ユニバーサルログイン
Auth0のユニバーサルログインには、認可サーバーの重要な機能であるログインフローが備わっています。ユーザーがアプリケーションにアクセスするために本人確認を行う必要がある場合は、ユニバーサルログインにリダイレクトし、Auth0に認証プロセスを処理してもらうことができます。| 認証フロー | フローの種類 | Authentication APIエンドポイントへの要求数 |
|---|---|---|
| ログイン | ユーザー名/パスワードのチャレンジ* | 5 |
| ログイン | サードパーティIDプロバイダー（ソーシャルや職場のログインなど） | 6 |
| ログイン | Auth0の認証セッション存在 | 1 |
| サインアップ | ユーザー名/パスワードの使用 | 6 |
修飾子
特定の認証構成では基準の要求数が変わります。これらの調整は追加のセキュリティ対策や認証フローに依存します。| 修飾子 | 説明 | 追加の要求 |
|---|---|---|
| ID First | 資格情報を要求する前にユーザーを識別します。 | +2 |
| MFA | 多要素認証を追加します。 | 1要素あたり+2 |
| OTP | 認証のワンタイムパスワードです。 | +2 |
| エンタープライズログイン | エンタープライズ接続（例：SAML、OIDC、LDAP）を通して認証します。 | +1 |
| クライアント資格情報 | マシンツーマシン認証に使用されます。アクションが使用される場合でも例外なく適用されます。 | +1 |
クラシックログイン
クラシックログインはAuth0がホストするログインエクスペリエンスで、カスタマイズにJavaScriptを使用します。クラシックログインの実装はアプリで直接認証を埋め込むより複雑性が低く、クロスオリジン認証の危険を回避するのに役立ちます。| 認証フロー | フローの種類 | 要求数 |
|---|---|---|
| ログイン | ユーザー名/パスワードのチャレンジ | 8 |
| ログイン | サードパーティIDプロバイダー（ソーシャルや職場のログインなど） | 8 |
| ログイン | Auth0の認証セッション存在 | 2 |
| サインアップ | ユーザー名/パスワード | 8 |
カスタムデータベースを構成している場合は、必ず上記それぞれの認証フローに追加のAuthentication API呼び出しを2つ追加しておきます。詳細については、「カスタムデータベース接続」を参照してください。
修飾子
以下の要素ではクラシックログインの要求数が増加します。| 修飾子 | 説明 | 追加の要求 |
|---|---|---|
| SMS認証のみ | SMSを最優先の認証方法として使用する場合です。 | +7 |
| ネイティブソーシャルログイン | ネイティブのソーシャルプロバイダー（Google、Facebookなど）を使用したログインです。 | +1 |
| リダイレクト | 認証中の追加のリダイレクトは要求数に加算されます。 | +1 |