Authenticate
Manage Users
Customize
Platformカスタムレート制限ポリシーは、すべてのパブリッククラウド環境で利用できます。
カスタムレート制限ポリシーは、安全のための上限であり、容量を分割するものではありません。テナント全体のレート制限の割り当てをアプリケーション間で均等に分配することを目的としたものではありません。通常のトラフィックでは上限に達しない程度に高く設定しつつ、問題のあるアプリケーションがテナントに影響を及ぼす前に制限される程度に低く設定してください。
カスタムレート制限とテナントのレート制限の関係
テナントには、サブスクリプションプランに応じたグローバル認証レート制限があります。カスタムレート制限ポリシーは、このグローバル制限より低い、アプリケーションごとの上限を設定します。この2つの制限は連携して機能します。- カスタムレート制限のチェックを通過したすべてのリクエストは、テナントのグローバルレート制限にもカウントされます。
- アプリケーションがカスタム制限を超えると、Auth0 はそのアプリケーションに HTTP 429 を返します。拒否されたリクエストは、テナントのグローバルレート制限にはカウントされません。
- テナントのグローバル制限に先に達すると、個々のアプリケーションがカスタム制限内に収まっているかどうかにかかわらず、すべてのアプリケーションがスロットリングされます。
ポリシー評価の仕組み
Auth0 では、カスタムレート制限ポリシーを最も具体的なものから最も一般的なものへと、厳格な階層に従って評価します。最初に一致したレベルが適用され、それより広い範囲のレベルはすべてスキップされます。- クライアント ID: クライアント ID によって特定のアプリケーションを対象とするポリシーです。一致するポリシーが存在する場合、評価はここで終了します。
- グループ: グループ化されたプロファイル (サードパーティアプリケーションや CIMD など) に対し、グループ内のすべてのアプリケーションからの合計トラフィックに単一の共有制限を適用します。グループ内のすべてのアプリケーションは同じポリシーを共有します。グループ内ではアプリケーションごとに制限が分割されることはありません。アプリケーションがポリシーを持つグループに属している場合、評価はここで終了します。
- グローバル / デフォルト: クライアント ID またはグループのポリシーの対象外となるすべてのアプリケーションに適用されるフォールバックポリシーです。各アプリケーションには、設定された制限に基づく独立したポリシーが適用されます。制限値は共通ですが、ポリシーは共有されません。つまり、各アプリケーションは同じ上限に対して個別に評価されます。
共有カウンター (グループポリシー)
グループポリシーでは、グループ内のすべてのアプリケーションで単一の共有カウンターを使用します。グループメンバーからのすべてのリクエストは、同じバケットを消費します。 たとえば、100 RPS の制限を持つ「Third-Party Clients」というグループポリシーを作成し、そのグループに5つのアプリケーションが含まれている場合、100 RPS の制限はそれらの合計トラフィックに適用されます。1つのアプリケーションが90 RPSを送信し、他のアプリケーションがそれぞれ5 RPSを送信すると、グループは制限を超過します (90 + 5 + 5 + 5 + 5 = 110 RPS) 。Auth0 は、グループ内のいずれかのアプリケーションからの後続のリクエストをスロットリングします。グループ内のアプリケーションごとの割り当ては保証されません。 1つのサードパーティアプリケーションに異なる扱いが必要な場合は、グループ制限よりも優先されるクライアント ID ポリシーを割り当ててください。サードパーティアプリケーションとCIMDクライアント
Client ID Metadata Document (CIMD) を使用して登録されたアプリケーションは技術的にはサードパーティアプリケーションに該当しますが、Auth0では従来のサードパーティアプリケーションとは別のグループとして扱われます。つまり、次の2つの異なるグループバケットが存在します。- サードパーティアプリケーション (クライアント IDの接頭辞:
tpa_) ：Management APIまたはDynamic Client Registration (DCR) を使用して作成されたものを含む、従来のサードパーティアプリケーション。 - CIMDクライアント (クライアント IDの接頭辞:
https://) ：Client ID Metadata Documentを通じて作成されたアプリケーション。
独立したカウンター (グローバル／デフォルトポリシー)
グローバルポリシーでは、カウンターがアプリケーションごとに独立しています。各アプリケーションには、同じ設定上限に対して評価される個別のカウンターがあります。アプリケーション間で容量を取り合うことはありません。 たとえば、グローバルデフォルトポリシーを 50 RPS に設定した場合、アプリケーション A、アプリケーション B、アプリケーション C はそれぞれ独立して 50 RPS を送信できます。アプリケーション A が上限に達しても、アプリケーション B や C には影響しません。各アプリケーションは、個別に 50 RPS を超えた場合にのみスロットリングされます。 アプリケーションのグループ全体からの合計負荷に上限を設ける必要がある場合 (たとえば、合計トラフィックによってテナントに過剰な負荷がかかる可能性があるサードパーティ連携など) は、グループポリシーを使用します。アプリケーション間で調整することなく、アプリケーションごとに一律の安全上限を設ける必要がある場合は、グローバルデフォルトを使用します。カスタムレート制限の対象となるリクエスト
カスタムレート制限ポリシーでは、アプリケーションのclient_id に紐付く Authentication API リクエストがカウントされます。エンドユーザーのブラウザーがリクエストを送信する HTTP クライアントであっても、そのリクエストを発生させるかどうかや頻度をアプリケーションが制御している場合、Auth0 はそのリクエストをカウントします。
カスタムレート制限の除外
Auth0 が認証フローを開始した後 (/authorize の後) 、エンドユーザーのブラウザは Auth0 と直接通信してログインを完了します。こうした後続のリクエスト (ログインページのレンダリング、資格情報の送信、MFA チャレンジの完了) は、カスタムレート制限の対象にはなりません。アプリケーションはこれらのリクエストを開始するものではなく、その頻度やタイミングを制御することもできません。
たとえば、一般的なログインフローは次のとおりです。
- アプリケーションがユーザーを
/authorizeにリダイレクトする → カウントされる (アプリが開始するため) 。 - Auth0 がログインページをレンダリングする → カウントされない (ブラウザから Auth0 へのリクエストであり、アプリでは制御できないため) 。
- ユーザーが資格情報を送信する → カウントされない。
- ユーザーが MFA チャレンジを完了する → カウントされない。
- Auth0 が認可コードとともにリダイレクトする → カウントされない。
- アプリケーションが
/oauth/tokenでコードを交換する → カウントされる (アプリが開始するため) 。
ブラウザから開始されるリクエストは除外されるため、カスタムレート制限ポリシーにより、完全な認証フローをトリガーしてテナント全体のレート制限を使い果たす攻撃のリスクは低減されますが、完全になくなるわけではありません。このような攻撃パターンへの対策については、攻撃対策を参照してください。
ログのみモード
ポリシーでログのみモードを有効にすると、Auth0 は設定された上限に対するリクエストを追跡し、action: log を含む api_limit ログイベントを出力します。ただし、HTTP 429 レスポンスは実際には返されません。トラフィックは通常どおり流れ続けます。
ログのみモードは、次の用途に使用します。
- トラフィックをブロックする前に、新しい上限が適切に設定されていることを検証する。
- ポリシーの変更による影響を受けるアプリケーションを特定する。
- アプリケーションまたはグループのベースラインとなるトラフィックパターンを把握する。
レート制限値を選択する
適切な制限値は、アプリケーションのトラフィックパターンを制御できるかどうかに応じて決定します。ファーストパーティアプリケーション (クライアント ID ポリシー)
自社で所有・運用するアプリケーションでは、トラフィックを直接測定できます。- ポリシーでログのみモードを有効にします。
- アプリケーションのリクエストパターンを3～7日間観察します。
api_limitログイベントを確認し、リクエストレートのピークを特定します。- 観測されたピークの2～3倍に制限を設定します。たとえば、アプリケーションのピークが10 RPSの場合は、制限を20～30 RPSに設定します。
サードパーティアプリケーション (グループポリシーまたはグローバルポリシー)
パートナー連携、顧客が構築したアプリ、マーケットプレイスコネクターなど、自身で制御できないアプリケーションでは、トラフィックパターンを事前に予測できません。テナントが安全に処理できる範囲に基づいて制限を設定してください。- 他のアプリケーションに影響を与えずに、単一の送信元からテナントが許容できる最大 RPS を算出します。
- 制限をそのしきい値以下に設定します。
- 適用前に実際のトラフィックで制限を検証するため、ログのみモードを有効にします。
api_limitイベントを監視し、サードパーティの利用パターンが明らかになったら調整します。
目標とすべき上限は、通常のトラフィックが決して到達しない値です。アプリケーションが恒常的に制限値に近づく場合は、制限が低すぎます。制限を引き上げ、トラフィックパターンを調査してください。
アプリケーションを完全にブロックする
カスタムレート制限を0 に設定すると、レート制限の容量を消費することなく、そのアプリケーションからのすべての Authentication API リクエストが直ちにブロックされます。調査中に、侵害されたアプリケーションや重大な問題を引き起こしているアプリケーションを停止するために使用します。
カスタムレート制限ポリシーを作成する
Management API を使用してカスタムレート制限ポリシーを作成するには、create:rate_limit_policies スコープを持つ Management API トークンで POST /api/v2/rate-limit-policies を呼び出します。
- 単一のアプリケーション
- アプリケーショングループ
- グローバルデフォルト
特定のアプリケーションに対して、Client ID を指定してRate Limitを設定します。これは最も具体的なポリシーレベルであり、グループポリシーおよびグローバルポリシーよりも優先されます。制限を適用せずログのみを記録するモードを有効にするには、
Auth0 CLIを使用していますか？まだセットアップしていない場合は、このコマンドを実行する前にCLIセッションをセットアップして認証してください。
actionを"log"に設定します。Auth0は制限に対するリクエスト数を追跡し、api_limitログイベントを出力しますが、HTTP 429レスポンスは返しません。ログによる監視
テナントログを使用して、カスタムレート制限ポリシーがトラフィックに与える影響を監視します。
Auth0 は、ポリシーとアプリケーションの組み合わせごとに、これらのログイベントを 1 分間に最大 1 回出力します。アプリケーションが継続的に制限を超過した場合、拒否されたリクエストごとではなく、1 分ごとに 1 件の
api_limit イベントが表示されます。これにより、過負荷が継続している間にログ量が増え続けるのを防ぎます。
これらのイベントを表示するには、Auth0 Dashboard > Monitoring > Logs に移動し、イベントタイプでフィルタリングします。ログイベントのフィールドの詳細については、ログイベントタイプコードを参照してください。
api_limit イベントタイプは、カスタムレート制限ポリシーとテナントのグローバルレート制限で共通して使用されます。カスタムポリシーによってトリガーされたイベントを特定するには、ログイベントの詳細でポリシー名と対象の client_id を確認してください。グローバルレート制限イベントにはポリシー名は含まれません。新しいポリシーではログのみモードを有効にして、トラフィックをブロックせずに影響を確認します。3～7 日後にログを確認し、制限が適切に設定されていることを確認してから強制適用に切り替えてください。HTTP 応答ヘッダーでの監視
Auth0 は、カスタムレート制限ポリシーの対象となるすべてのリクエストに対して、Auth0-RateLimit 応答ヘッダーを返します。このヘッダーはカスタムレート制限ポリシー専用であり、アプリケーションの現在のクォータのステータスを示します。
アプリケーションがカスタム レート制限 を超過すると、Auth0 は再試行までに待機する秒数を示す
Retry-After header を含む HTTP 429 Too Many Requests 応答を返します。
response body には JSON 形式のエラーが含まれます。
/authorize リクエストはブラウザーのリダイレクトによって開始されるため、Auth0 は JSON 形式のエラー応答を返しません。代わりに、エラーページをユーザーに直接表示します。ポリシーで Redirect オプションを有効にすると、エラーページを表示する代わりに、設定済みの URL にユーザーをリダイレクトします。
スロットリングは、制限を超過したアプリケーションにのみ適用されます。同じテナント内の他のアプリケーションには影響しません。
X-RateLimit-* ヘッダー (X-RateLimit-Limit、X-RateLimit-Remaining、X-RateLimit-Reset) は、カスタムポリシーの制限ではなく、テナント’s グローバルレート制限を反映します。これらのヘッダーは、成功した応答とスロットリングされた応答の両方に含まれますが、常にテナントレベル のキャパシティを報告します。カスタムポリシーのクォータ消費量を監視するには、Auth0-RateLimit ヘッダーを使用してください。