Skip to main content
Auth0 では、最適なパフォーマンスを確保し、、技術的なエラー、または過剰な正当なトラフィックから保護するため、サービスの利用を制限しています。最適なユーザー体験を実現できるようにアプリケーションを構成するには、Auth0 がどのように制限を適用しているかを確認することをお勧めします。
アカウントに適用されるレート制限を確認するには、すべてのレート制限ポリシーを一覧できる Rate Limit Configurations を参照してください。

​
レート制限の概要

Auth0 は、過剰なリクエストからサービスを保護し、サービスの中断やパフォーマンス低下からお客様を守るために、制限を適用しています。 Auth0 では、次のような各種制限を監視しており、多くの場合は実際に適用しています。
  • 環境へのリクエスト (Private Cloud のみ)
  • API または API エンドポイントを介したテナントへのリクエスト
  • その他の制限

​
環境ごとのリクエスト制限 (Private Cloud のみ)

Private Cloud では、環境ごとのリクエスト制限は Private Cloud Performance Tier に基づいて決まります。詳細については、Private Cloud for AWS または Private Cloud for Azure を参照してください。 現在、Private Cloud の環境レート制限は、Auth0 が SLA を満たせる最大負荷を示しています。ただし、現時点で Auth0 が制限を適用し、顧客に通知するのは、環境内の特定のテナントでレート制限を超過した場合のみです。顧客が単一の本番テナントを維持する大半の Private Cloud のユースケースでは、これは問題になりません。一方で、複数の本番テナントをプロビジョニングするユースケースでは、環境内のすべてのテナントにまたがる想定負荷を考慮し、必要に応じて追加の監視を実装する必要があります。
機能Authentication APIその他すべての API (Management API を含む)
テナントのレート制限すべてのテナントは、その API に対する環境全体で共有されるグローバル制限を消費しますが、環境レート制限はハードキャップです。テナント全体の合計負荷によって環境制限を超過すると、超過分のリクエストにレート制限が適用されます。テナントのレート制限は個別に適用され、環境レート制限はパフォーマンス低下や SLA への影響が生じる可能性を示すしきい値として機能しますが、テナントレベルで直接レート制限を引き起こすことはありません。
環境レート制限超過 (例)環境制限が 1500 rps の場合、テナント 1 が 1400 rps、テナント 2 が 900 rps (合計 2300 rps) であると、800 件のリクエストにレート制限が適用されます。環境制限が 1500 rps の場合、テナント 1 が 1400 rps、テナント 2 が 900 rps (合計 2300 rps) であっても、個々のテナントにレート制限は適用されませんが、環境全体でパフォーマンスが低下し、SLA に影響する可能性があります。
環境レート制限を超過すると、Service Level Agreement (SLA) は無効になります。
Private Cloud の負荷テストに関する考慮事項については、Private Cloud on AWS および Private Cloud on Azure を参照してください。

​
テナントのリクエスト制限

Auth0 では、テナントに対して実行できるリクエスト数に制限があります。これらの制限は API ごとに設定されており、さらに各 API 内の特定のエンドポイントごとにも設定されています。

​
API レート制限

Auth0 では、API エンドポイントにかかわらず、特定の API に対するリクエスト数が制限されます。API の制限は、次の要因によって異なる場合があります。
  • API
    • Authentication
    • Management
  • テナントの種類 (Production と Development または Staging)
  • サブスクリプションレベル (Free、Essential、Professional、Enterprise Public または Private)
たとえば、無料の非本番テナントでは、有料サブスクリプションの本番テナントとは異なる制限が設定されることがあります。具体的なレート制限の設定については、Rate Limit Configurations を参照してください。

​
ユーザーリクエスト

単一のエンドユーザーによるリクエスト (例: ログインまたはサインアップ) では、通常、Authentication API エンドポイントに対して複数のリクエストが発生します。エンドユーザーリクエストと Authentication API リクエストの実際の比率は、主に次の要因によって異なります。
  • 認証されるエンティティ (例: マシン、またはエンドユーザー向けのモバイル/デスクトップアプリケーション)
  • 認証エクスペリエンス (例: 新しい または Classic Login)
  • 認証フロー (例: ログイン、サインアップ、またはパスワード変更)
  • 認証フローの種類 (例: username / パスワードによるログイン、ソーシャルログインによるログイン、既存の認証トークンがすでにある場合のログイン)
拡張機能 を利用しているお客様は、その設定に応じて、Authentication API だけでなく へのリクエストをさらに追加する場合があります。 Auth0 の構成が API 使用量にどのように影響するかを見積もる方法については、レート制限のユースケースを参照してください。

​
エンドポイントのレート制限

Auth0 では、API エンドポイントに対するリクエスト数が制限されており、場合によってはエンドポイント操作の回数も制限されます。API エンドポイントの制限は、次の要素によっても異なります。
  • API
  • テナントの種類
  • サブスクリプションレベル
たとえば、無料の非本番テナントに適用される制限は、有料サブスクリプションの本番テナントに適用される制限とは異なります。

​
テナントへのリクエスト制限の適用順序

テナントに対してリクエストが行われると、Auth0 はまず API 全体のグローバル制限に照らしてそのリクエストを評価し、次に特定の API エンドポイントに設定されたレート制限に照らして評価します。

​
その他の制限

​
データベースログインの制限

データベース接続では、Auth0 はユーザーアカウントと IP アドレスに基づいて、特定の種類の繰り返しログイン試行を制限します。システム全体の健全性を維持するため、Auth0 では負荷を抑えるユーザー名/パスワードのレート制限を設けています。Auth0 は高度なカスタマイズが可能なため、サービス低下のリスクが生じる場合があります。原因としては、次のようなものが挙げられます。
  • 高負荷のストレステスト
  • ベンチマークテスト
  • ユーザーが何度もログインする原因となる非効率なコード
リクエストには、Auth0 API の各ポリシーに記載されている制限が適用されます。 さらに、同一ユーザーに対するログインレート制限もあります。1 つの IP アドレスから同じユーザーアカウントに対して 1 分間に 20 回ログインが試行されると、レート制限が適用されます。その後、そのユーザーに対して Auth0 が許可する試行回数は 1 分あたり 10 回になります。ログイン試行が成功か失敗かを問わず、どの組み合わせでもこの制限の対象としてカウントされます。

ユーザー保護のための制限

Auth0 の ブルートフォース対策 と 不審な IP のスロットリング でも、ログインやサインアップが制限される場合がありますが、これらはレート制限とは独立しています。Auth0 が悪意のある可能性がある異常をどのように検出して処理するかについて詳しくは、Attack Protection を参照してください。

​
多要素認証の SMS メッセージ送信上限 (エンドユーザーのみ)

1 時間以内にお使いのデバイスへ 10 件を超える SMS メッセージを送信しようとすると、レート制限超過に関するエラーメッセージが表示されます。 メッセージ送信の上限を超えた場合は、最初のメッセージ送信リクエストから少なくとも 1 時間待ってから、再度リクエストする必要があります。その後は、さらに 1 時間経過するごとに 1 回ずつ追加で試行できます。

​
ネイティブ ソーシャルログインの制限

ネイティブ ソーシャルログインフローのリクエストに適用される制限は、リクエスト本文に基づき、次の初期条件で識別されます。
リクエストタイプ本文
grant_typeurn:ietf:params:oauth:grant-type:token-exchange
subject_token_typehttp://auth0.com/oauth/token-type/apple-authz-code

​
Public Performance Burst

Public Performance Burst は、既存の Public Cloud デプロイメントを強化する、エンタープライズサブスクリプション向けのアドオンです。このオファリングにより、Authentication API のリクエスト上限を、デフォルトのエンタープライズリクエスト上限である 100 RPS の倍数まで、月あたり最大 48 時間動的に引き上げることができます。
このアドオンで拡張されるのは Authentication API のリクエスト上限のみであり、Management API や、Authentication API の範囲外でレート制限されるその他のエンドポイントには適用されません。
現在、Public Performance Burst には 3 つの倍率オプション (2x、3x、4x) があり、Authentication API に対して、それぞれ 200、300、400 RPS を月あたり最大 48 時間まで利用できます。この 48 時間は 5 分単位で計測され、月間許容量から差し引かれるため、毎月 576 回の 5 分枠で、API をその倍率レベルで使用できます。 Authentication API へのリクエスト量がデフォルトの 100 RPS を超えると、月間許容量から 5 分枠分が差し引かれ、トラフィックはその倍率に対応するレートで許可されます。その時点から連続する 5 分間は、追加で差し引かれることなく、トラフィックをその倍率範囲内に維持できます。 差し引きイベントは、テナントログで監視できます。差し引きが発生するたびに、すでに消費した許容量と残りの許容量に関する情報を含む、対応する appi テナントログイベントタイプが生成されます。 詳細については、Rate Limits - Enterprise の Authentication API セクションを参照してください。

​
Private Performance Burst

Private Performance Burst オファリング (現在は AWS の 30x および 60x ティアで利用可能) には、月あたり最大 80 時間まで、30x (3,000 RPS) または 60x (6,000 RPS) のバースト (ピーク時) パフォーマンス容量が含まれます。ベースパフォーマンス容量はバーストパフォーマンス容量の半分で、月の残りの期間に利用できます。 言い換えると、30x Private Performance Burst には以下が含まれます。
  • ベース容量: 月間を通じて 1,500 RPS
  • バースト/ピーク容量: 月あたり最大 80 時間まで 3,000 RPS
Authentication トランザクションが Base API-Request 制限を超えて急増した場合、月次割り当てから 1 時間分が差し引かれます。その時点から連続する 1 時間は、トラフィックを高いレートのまま維持できます。しきい値を再度超えた場合も、同じ方式で追加の差し引きが行われます。 80 時間の割り当てを使い切ると、新しい月次割り当てが有効になるまで、Authentication トラフィックはベース容量までレート制限されます。

​
拡張機能の同時実行数の上限

システムの可用性を確保し、システムリソースを公平に利用できるようにするため、Auth0 はすべての拡張機能 (Actions、Hooks、Rules、カスタムデータベース接続、Extensions、カスタム OAuth2 接続) を対象に、同時に処理中のリクエスト数を制限しています。同時リクエスト数の上限を超えたテナントでは、処理中のリクエストが完了するまで、新しいリクエストでエラーが発生することがあります。同時実行数の上限は以下のとおりです。
サブスクリプション同時実行数の上限 (テナントごと)
Public Cloud250
Tier Dev Private Cloud100
Private Cloud Basic 100 RPS (1x)200
Private Cloud Performance 500 RPS (5x)400
Private Cloud Performance 1500 RPS (15x)1200
Private Cloud Performance 3000 RPS (30x) and 3000 RPS Burst (30x Burst)1200
Private Cloud Performance 6000 RPS (60x) and 6000 RPS Burst (60x Burst)1200
同時実行数は、想定される RPS に各リクエストのレイテンシを掛けることで算出できます。たとえば、2 つの post-login Action が関連付けられており、それぞれの処理時間が 250ms、ログイン全体の RPS が 400 のテナントでは、想定される同時実行数は (2 * (400 requests / 1 second) * (.25 seconds / 1 request)) = 200 です。 これらの同時実行数の上限による影響をテナントが受けないようにするには、外部 API の呼び出しなど、長時間実行される可能性がある拡張機能ロジックに妥当なタイムアウトを設定してください。

​
レート制限アルゴリズム

Auth0 は、API に対してレート制限とバースト制限を設定しています。レート制限は、システムが継続的に許容できるトラフィック量の最大値です。一方、バースト制限は、一定の時間間隔内でシステムが許容できる短期的なトラフィック量の最大値です。Auth0 のレート制限とバースト制限は連携して機能し、変動するトラフィック量に対して、より適切な制限を実現します。 Auth0 のレート制限では、次の構成を持つトークンバケットアルゴリズムを使用します。
  • 制限キー:
    • 通常、レート制限キーは主に次の 2 つの要素に基づきます。
      • API とエンドポイント
      • テナントの種類
    • 場合によっては、追加の要素として次も含まれます。
      • 送信元 IP
      • 対象ユーザー ID
  • 制限値:
    • バケットサイズ: 新しいリクエストが追加されるまでに、API またはエンドポイント全体、あるいは特定のユーザーまたは IP アドレスから受信できるリクエスト数の最大値です。
    • 補充レート: 新しいリクエストがバケットに追加される速度です。
Auth0 は、これら 2 つの数値からバースト制限と持続レート制限を計算します。
  • バースト制限:  バケットサイズと同じです。
  • 持続レート制限: 1 分あたりまたは 1 秒あたりのリクエスト数で表される補充レートです。
持続レート制限が 1 秒あたりのリクエスト数で計算される場合、新しいリクエストはミリ秒単位で追加されます。持続レート制限が 1 分あたりのリクエスト数で計算される場合、新しいリクエストは秒単位で追加されます。

​
詳細情報