メインコンテンツへスキップ

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

お客様のプロダクトが Auth0 によってレート制限されているかどうかを確認する方法はいくつかあります。レート制限の原因として考えられるものについては、以下を参照してください。

​
テナントログ

さまざまなテナントログをサブスクライブすることで、リクエスト量に関連する問題を追跡できます。Auth0 におけるテナントログとオペレーションイベントログの仕組みについては、ログを参照してください。

​
api_limit

api_limit イベントは、Authentication または のグローバルレート制限バケットでレート制限を超過した直後にトリガーされます。同じレート制限バケットで、消費されたリクエストトークン数が 1 分後も 80% を超えたままの場合は、2 件目の警告ログが生成されます。別のレート制限バケットでレート制限を超過した場合は、新しい 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 (リクエストが多すぎます) が返されます。これにより、お客様はレート制限の適用をリアルタイムで確認できます。ただし、これは 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 です。
  • 固定ウィンドウであるため、リクエストのバケットは 1 秒ごとに補充されます。
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 個のトークンが入るバケットは、「固定ウィンドウ」を使用して毎分補充されます。新しいトークンがバケットに追加され、各分の開始時にバケットが上限まで補充されます。
レート制限のシナリオ例:
このシナリオでは:
  • 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 Flow には、Login、Signup、Change Password など、いくつかのフローがあります。これらの中で最も一般的なのは通常 Login で、その次に Signup が続きます。 エンドユーザーがログインすると、エンドユーザーに認可トークンを発行して、要求したアプリケーションへのアクセスを許可できるかどうかを判断するために、Authentication API エンドポイントに対して複数の API 呼び出しが実行されます。 API 呼び出しの正確な回数は、いくつかの設定によって異なります。
  • 認証エクスペリエンス (例: New または Classic Login)
  • Authentication Flow (例: Login、Signup、または Change Password)
  • Authentication Flow Type (例: Username / Password によるログイン、Social Login によるログイン、既存の Authentication Token がすでに存在する場合のログイン)
以下では、一般的な顧客設定の例と、それらが API の使用状況に与える影響について説明します。

​
Universal Login

Auth0 Universal Login は、 の中核機能であるログインフローを提供します。ユーザーがアプリケーションへのアクセスのために本人確認を行う必要がある場合は、Universal Login にリダイレクトして、認証プロセスを Auth0 に任せることができます。
認証フローフロー種別Authentication API エンドポイントへのリクエスト
ログインユーザー名/パスワード チャレンジ*5
ログインサードパーティのIDプロバイダー (例: ソーシャルログイン、社内ログイン)6
ログインAuth0 の認証セッションが存在する1
サインアップユーザー名/パスワード経由6

​
加算要素

特定の認証構成では、基本のリクエスト数に加算が発生します。これらの調整は、追加のセキュリティ対策や認証フローによって異なります。
修正要素説明追加リクエスト数
ID First資格情報を要求する前にユーザーを識別します。+2
MFA多要素認証を追加します。ファクターごとに +2
OTP認証用のワンタイムパスワード+2
Enterprise Loginエンタープライズ接続 (例: SAML、OIDC、LDAP) を介した認証。+1
Client Credentialsマシン間認証に使用されます。Actions を使用する場合でも、常に適用されます。+1
*組み合わせて使用する要素はすべて、リクエスト総数に加算されます。

​
Classic login

Classic Login は、カスタマイズに JavaScript を利用する Auth0 がホストするログイン体験です。Classic Login の実装は、認証プロセスをアプリに直接埋め込むよりも複雑さが低く、クロスオリジン認証に伴うリスクの回避にも役立ちます。
認証フローフローの種類リクエスト数
ログインユーザー名/パスワード チャレンジ8
ログインサードパーティのIDプロバイダー - 例: ソーシャルログインまたは社内ログイン8
ログインAuth0 の認証セッションが存在する場合2
サインアップユーザー名/パスワード8
カスタムデータベースを設定している場合は、上記の各認証フローに Authentication API への呼び出しを 2 回追加する必要があります。詳細については、Custom Database Connections を参照してください。

​
増加要因

以下の要因により、Classic Login のリクエスト数が増加します。
増加要因説明追加リクエスト数
SMS Authentication OnlySMS を主要な認証方法として使用する場合。+7
Native Social Loginネイティブのソーシャルプロバイダー (例: Google、Facebook) を使用してログインする場合。+1
Redirects認証中に追加のリダイレクトが発生した場合。+1