Skip to main content

​
テナントへのリクエストがレート制限されているかを確認する

顧客の製品が Auth0 によってレート制限されているかどうかを確認する方法はいくつかあります。レート制限が発生する主な原因については、以下を参照してください。

​
テナントログ

さまざまなテナントログを購読することで、リクエスト量に関する問題を把握できます。Auth0 でテナントログとオペレーションイベントログがどのように機能するかについては、Logs を参照してください。

​
api_limit

api_limit イベントは、認証または のグローバルな レート制限バケット で レート制限 を超過した直後にトリガーされます。別の レート制限バケット で レート制限 を超過した場合は、新しい api_limit イベントが生成されます。これにより、どの レート制限 設定によって API 呼び出しがトリガーされているのかを顧客が特定できるため、根本原因を診断するための重要な第一歩となります。

​
api_limit_warning

api_limit_warning ログは、顧客のリクエスト率が特定のレート制限バケットのリクエストトークンの80%を消費したときに発生します。同じレート制限バケットで、使用されるリクエストトークン数が1分後も80%を超えたままの場合、2つ目の警告ログが生成されます。別のレート制限バケットで80%のしきい値を超えた場合は、新しい api_limit_warning ログが作成されます。

​
appi (Public Performance Burst のみ)

appi ログは、Public Performance Burst アドオンを利用している顧客テナントが、Authentication API の継続的なリクエストのレート制限である 100 RPS を超え、48 時間のバースト割り当てのうち 1 分間分を消費したときにトリガーされます。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 エラー の説明を参照してください。

​
テナントにレート制限が適用される理由を確認する

テナントへのリクエストにレート制限が適用されていて、その理由を確認するためのサポートが必要な場合は、Support Center からリクエストを送信してください。  その際、問題が発生したときの完全な生ログを含めてください。

​
テナントへのリクエストがレート制限されるタイミングを予測する

Auth0 は、レート制限ポリシーが設定されたエンドポイントの HTTP レスポンスヘッダーを使用して、現在のレート制限のステータスに関する最新情報を提供します。このステータスは次のように示されます。
  • x-ratelimit-limit: 利用可能なリクエストの最大数。
  • x-ratelimit-remaining: バケットに追加のリクエストが補充されるまでに残っているリクエスト数。
  • x-ratelimit-reset: 追加のリクエストがバケットに加えられる予定時刻を秒単位で示す UNIX タイムスタンプ。
例えば次のようになります。 ある API には、次のレート制限があります。
  • バースト制限: 1000
  • 持続レート制限: 100 requests per second (固定ウィンドウ)
この情報から、次のことが導き出せます。
  • 持続レート制限は、固定ウィンドウで 100 requests per second です。
  • 固定ウィンドウであるため、リクエストのバケットは毎秒補充されます。
API レスポンスで次の x-headers を受け取ったとします。
  • x-ratelimit-limit: 1000
  • x-ratelimit-remaining: 50
  • x-ratelimit-reset: 1675452600
この時点で、次のことがわかります。
  • テナントは、その API で許可されている 1000 件のリクエストのうち 950 件を使い切っており、追加のリクエストが加えられるまで残り 50 件しかありません。
  • 新しいリクエストは 1675452600、つまり 2023 年 2 月 3 日 19:30:00 UTC に追加されます。
  • その時点で新たに 1 件のリクエストが追加されます
したがって、上記のレートを上回る頻度でリクエストを行っている場合は、レート制限に達すると考えられます。実際にいつレート制限されるかは、バースト制限と、持続制限をどの程度超過しているかによって決まります。

​
レート制限の適用例

​
1 秒あたりのリクエスト数の例

Auth0 が /ratelimitexample という新しい API を、次のレート制限値で開始すると仮定します。
  • バースト制限: 5 リクエスト
  • 持続レート制限: 1 秒あたり 10 リクエスト。
重要なポイント:
  • API は 5 個のリクエストトークンから始まり、これを超えることはありません。これはバースト制限と同じです。
  • 10 個のトークンが入るバケットは、「固定ウィンドウ」に従って毎秒補充されます。新しいトークンがバケットに追加され、毎秒の切り替わり時点で満杯になります。
レート制限のシナリオ例:
このシナリオでは:
  • T0 - T1sec:  エンドユーザーは最初の 1 秒間に 6 件のリクエストを行います。5 件のリクエスト (バースト制限と同数) には 200 レスポンスが返されます。6 件目のリクエストには、バケット内のリクエストトークンが残っていないため、429 エラーが返されます。
  • T1sec - T2sec:  Auth0 は固定ウィンドウアルゴリズムにより、リクエストトークンのバケットを満杯まで補充します。その結果、7 件目から 11 件目までのリクエストは成功し、12 件目のリクエストでバケットが使い果たされるため、429 エラーになります。
  • T2sec - T3sec:  Auth0 は再度トークンバケットを補充するため、次のリクエスト (13) には 200 レスポンスが返されます。

​
1 分あたりのリクエストの例

Auth0 が /ratelimitexample2 という新しい API を、次のレート制限値で公開したとします。
  • バースト制限: 5 件のリクエスト
  • 持続レート制限: 1 分あたり 6 件のリクエスト。
重要なポイント:
  • API は 5 つのリクエストトークンを持つ状態で開始され、これはバースト制限と同じです。
  • 6 個のトークンを保持するバケットは、「固定ウィンドウ」を使用して 1 分ごとに補充されます。新しいトークンがバケットに追加され、毎分の開始時点で満杯まで補充されます。
レート制限のシナリオ例:
このシナリオでは:
  • T0 - T+1min: エンドユーザーは最初の 1 分間に 6 件のリクエストを行います。5 件のリクエスト (バースト制限と同数) には 200 レスポンスが返されます。6 件目のリクエストには、利用可能なリクエストトークンが残っていないため 429 エラーが返されます。
  • T+1min - T+2min: Auth0 は固定ウィンドウアルゴリズムによりトークンバケットを補充します。その結果、7 件目から 11 件目までのリクエストは成功しますが、12 件目のリクエストでバケットが使い果たされ、429 エラーになります。
  • T+2min: Auth0 は再びトークンバケットを補充するため、次のリクエスト (13 件目) には 200 レスポンスが返されます。

​
その他のシナリオ

場合によっては、Auth0 が 1 つの API に対して 2 つのレート制限を設定することがあります。  これは、バースト制限と、サービスの要件に合わせてより細かく調整された持続レート制限を構成するためです。  実際には、最初のレート制限が実効バースト制限となり、2 つ目のレート制限が実効持続レート制限となります。  このシナリオでは、Auth0 は実際のバースト制限と持続レート制限ではなく、実効バースト制限と実効持続レート制限のみを公開します。

​
エンドユーザーのログインおよびサインアップ API の使用

認証フローには、ログイン、サインアップ、パスワード変更など、いくつかあります。通常、もっとも一般的なのはログインで、次いでサインアップです。 エンドユーザーがログインすると、Authentication API のエンドポイントに対して複数の API 呼び出しが行われ、エンドユーザーが認可トークンを受け取る権限を持ち、要求したアプリケーションにアクセスできるかどうかが判定されます。 API 呼び出しの正確な回数は、いくつかの設定によって決まります。
  • 認証エクスペリエンス (例: 新しい または クラシックログイン)
  • 認証フロー (例: ログイン、サインアップ、またはパスワード変更)
  • 認証フローの種類 (例: ユーザー名 / パスワードによるログイン、ソーシャルログインによるログイン、既存の認証トークンがすでに存在する場合のログイン)
以下では、一般的な顧客設定のいくつかと、それらが API の使用状況に与える影響について説明します。

​
Universal Login

Auth0 Universal Login は、 の重要な機能であるログインフローを提供します。ユーザーがアプリケーションにアクセスするために本人確認を行う必要がある場合は、Universal Login にリダイレクトして、認証処理を Auth0 に任せることができます。

​
修飾要因

特定の認証構成では、基本のリクエスト数に補正が加わります。これらの補正は、追加のセキュリティ対策や認証フローによって異なります。 *組み合わせて使用するものは、すべてリクエスト総数に加算されます。

​
クラシックログイン

クラシックログインは、カスタマイズにJavaScriptを利用する Auth0 ホスト型のログイン体験です。クラシックログインの実装は、認証プロセスをアプリに直接組み込むよりも複雑さが少なく、クロスオリジン認証に伴うリスクの回避にも役立ちます。
カスタムデータベース接続を設定しているお客様は、上記の各認証フローに Authentication API 呼び出しを 2 回追加する必要があります。詳しくは、カスタムデータベース接続を参照してください。

​
修飾要因

以下の要因により、Classic Login のリクエスト数が増加します。