テナントへの要求がレート制限を受けていることを確認する
テナントログ
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応答
SDKエラーの処理
エラーページ
error_descriptionに関連エラーを含めて、エラーページのURLにユーザーがリダイレクトされます。 詳細については、影響を受けるエンドポイントとJSONエラーの説明を参照してください。
テナントがレート制限を受けている理由を調べる
テナントへの要求がレート制限を受ける時期を予測する
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の例
/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の例
/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応答を受信します。
その他のシナリオ
エンドユーザーのログインとサインアップAPIの使用
- 認証エクスペリエンス（新しいユニバーサルログイン、クラシックログインなど）
- 認証フロー（ログイン、サインアップ、パスワード変更など）
- 認証フロータイプ（ユーザー名/パスワードを介したログイン、ソーシャルログインを介したログイン、既存の認証トークンがすでに存在するときのログインなど）
ユニバーサルログイン
| 認証フロー | フローの種類 | Authentication APIエンドポイントへの要求数 |
|---|---|---|
| ログイン | ユーザー名/パスワードのチャレンジ* | 5 |
| ログイン | サードパーティIDプロバイダー（ソーシャルや職場のログインなど） | 6 |
| ログイン | Auth0の認証セッション存在 | 1 |
| サインアップ | ユーザー名/パスワードの使用 | 6 |
修飾子
| 修飾子 | 説明 | 追加の要求 |
|---|---|---|
| ID First | 資格情報を要求する前にユーザーを識別します。 | +2 |
| MFA | 多要素認証を追加します。 | 1要素あたり+2 |
| OTP | 認証のワンタイムパスワードです。 | +2 |
| エンタープライズログイン | エンタープライズ接続（例：SAML、OIDC、LDAP）を通して認証します。 | +1 |
| クライアント資格情報 | マシンツーマシン認証に使用されます。アクションが使用される場合でも例外なく適用されます。 | +1 |
クラシックログイン
| 認証フロー | フローの種類 | 要求数 |
|---|---|---|
| ログイン | ユーザー名/パスワードのチャレンジ | 8 |
| ログイン | サードパーティIDプロバイダー（ソーシャルや職場のログインなど） | 8 |
| ログイン | Auth0の認証セッション存在 | 2 |
| サインアップ | ユーザー名/パスワード | 8 |
修飾子
| 修飾子 | 説明 | 追加の要求 |
|---|---|---|
| SMS認証のみ | SMSを最優先の認証方法として使用する場合です。 | +7 |
| ネイティブソーシャルログイン | ネイティブのソーシャルプロバイダー（Google、Facebookなど）を使用したログインです。 | +1 |
| リダイレクト | 認証中の追加のリダイレクトは要求数に加算されます。 | +1 |