レート制限のユースケース

顧客の製品がAuth0のレート制限を受けているかを確認するには、いくつかの方法があります。可能性のあるレート制限の原因については、以下を参照してください。

、「ログ」をお読みください。

api_limitイベントは、特定のレート制限バケットでレート制限を超過すると即座にトリガーされます。1分経っても同じレート制限バケットでレート制限が超過したままの場合には、2つ目のログが作成されます。別のレート制限バケットでレート制限が超過した場合には、新たにapi_limitイベントが生成されます。そうすることで、どのレート制限の構成にAPI呼び出しが抵触しているのかを特定できます。これは根本原因を診断する重要な第一歩になります。

api_limit_warningログは、特定のレート制限バケットについて、要求トークンの80%が顧客の要求レートによって使用されている場合にトリガーされます。利用されている要求トークンの数が1分経っても同じレート制限バケットで80%を超えたままの場合には、2つ目の警告ログが生成されます。別のレート制限バケットで80%のしきい値を超えた場合には、新たにapi_limit_warningログが作成されます。

appiログは、パブリックパフォーマンスバーストアドオンのある顧客テナントがサステイン時のAuthentication API要求のレート制限である100 RPSを超過し、48時間のバースト割り当ての15分ブロックを消費するとトリガーされます。15分経ってもサステイン時の要求上限である100 RPSを超過したままの場合には、2つ目のappiログがトリガーされます。

Auth0のAPI応答は、HTTP 429 (Too Many Requests)応答に超過したレート制限を含めて送信します。これによって、レート制限の適用をリアルタイムで観察することができます。ただし、これはカスタムで構築された顧客のアプリケーションがAuth0 APIと直接やり取りする場合にのみ役立ちます。

SDKを使用している場合には、Management APIのSDKライブラリーのエラーページを参照してください。

エラーページ応答は、エンドユーザーにHTMLコンテンツを表示するエンドポイントに対して送信されます。テナントに（Auth0がホストする）汎用ページの使用が構成されている場合には、応答制限が超過すると、Auth0は予期されるページではなく、エラーページを表示します。  テナントにカスタムのエラーページの使用が構成されている場合には、クエリ文字列パラメーターのerror_descriptionに関連エラーを含めて、エラーページのURLにユーザーがリダイレクトされます。  詳細については、影響を受けるエンドポイントとJSONエラーの説明を参照してください。

テナント要求がレート制限を受けていると思われ、その理由を知るのに手助けが必要な場合には、サポートセンターを通してリクエストしてください。  リクエストには、問題を示している生のログを含めてください。

Auth0は、レート制限ポリシーが構成されているエンドポイントからHTTP応答ヘッダーを使用して、レート制限の現在のステータスについて最新情報を報告します。このステータスでは以下が通知されます。

• x-ratelimit-limit：使用可能な要求数の上限です。

• x-ratelimit-remaining：バケットに要求数が補充されるまでの残りの要求数です。

• x-ratelimit-reset：バケットに要求数が補充される予測時間を秒単位で表したUNIXタイムスタンプです。

例：

APIには以下のレート制限があります。

• バースト制限： 1000

• 持続的レート制限：100RPS（固定ウィンドウ）

この情報から以下が分かります。

• 持続的レート制限は固定ウィンドウで100RPSです。

• 固定ウィンドウのため、要求のバケットは毎秒補充されます。

API応答では以下のXヘッダーを受け取ります。

• x-ratelimit-limit: 1000

• x-ratelimit-remaining: 50

• x-ratelimit-reset: 1675452600

以下のことが分かります。

• テナントがそのAPIに対する要求数1000中の950をすでに使用し、要求数が補充されるまでに残っている要求数は50のみである

• 新しい要求数が1675452600秒後（2023年2月3日7:30:00 PM UTC）に補充される

• そのときに新たに1つの要求が追加される

このため、上記よりも速いレートで要求を行っていると、レート制限を受けることになります。  どのくらい早い時期にレート制限を受けるのかは、持続制限をどのくらい超過しているのかとバースト制限に依存します。

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応答を受信します。

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は実際のバースト制限と持続的レート制限ではなく、実施されるバースト制限と持続的レート制限のみを公開します。

認証フローには、ログイン、サインアップ、パスワード変更などいくつかがあります。このうち最も一般的なものがログインで、その次がサインアップです。

エンドユーザーがログインすると、Authentication APIエンドポイントへの複数のAPI呼び出しが始まります。これによって、エンドユーザーに認可トークンの受信が許可されているかを判断し、要求したアプリケーションにアクセスします。

API呼び出しを行う正確な数は、以下のいくつかの構成に応じて異なります。

• 認証エクスペリエンス（新しいユニバーサルログイン、クラシックログインなど）

• 認証フロー（ログイン、サインアップ、パスワード変更など）

• 認証フロータイプ（ユーザー名/パスワードを介したログイン、ソーシャルログインを介したログイン、既存の認証トークンがすでに存在するときのログインなど）

以下に、よくある顧客の構成とAPIの使用に対する影響についていくつか説明します。

Auth0のユニバーサルログインには、認可サーバーの重要な機能であるログインフローが備わっています。ユーザーがアプリケーションにアクセスするために本人確認を行う必要がある場合は、ユニバーサルログインにリダイレクトし、Auth0に認証プロセスを処理してもらうことができます。

特定の認証構成では基準の要求数が変わります。これらの調整は追加のセキュリティ対策や認証フローに依存します。

*組み合わせて使用されるものはすべて全体の要求数に追加されます。

クラシックログインはAuth0がホストするログインエクスペリエンスで、カスタマイズにJavaScriptを使用します。クラシックログインの実装はアプリで直接認証を埋め込むより複雑性が低く、クロスオリジン認証の危険を回避するのに役立ちます。

以下の要素ではクラシックログインの要求数が増加します。