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 に影響が出る可能性があります。
環境レート制限を超過すると、サービスレベル契約 (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 を参照してください。

​
ユーザーリクエスト

1 回のエンドユーザー リクエスト (例: ログインやサインアップ) では、通常、Authentication API エンドポイントに対して複数のリクエストが発生します。エンドユーザー リクエストと Authentication API への実際のリクエスト数の比率は、主に次の要因によって異なります。
  • 認証対象のエンティティ (例: マシン、またはエンドユーザー向けのモバイル アプリケーションやデスクトップ アプリケーション)
  • 認証エクスペリエンス (例: 新しい または Classic Login)
  • 認証フロー (例: ログイン、サインアップ、パスワードの変更)
  • 認証フローの種類 (例: username / password でのログイン、ソーシャルログインでのログイン、既存の認証トークンがすでにある場合のログイン)
Extensibility を利用している場合は、Extensibility の設定によって、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 の最大 4 倍まで、月間合計 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) および 3000 RPS Burst (30x Burst)1200
Private Cloud Performance 6000 RPS (60x) および 6000 RPS Burst (60x Burst)1200
同時実行数は、想定される RPS に各リクエストのレイテンシを掛けて算出できます。たとえば、テナントに 2 つの post-login Actions がバインドされており、それぞれの処理時間が 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 分あたりのリクエスト数で計算される場合、新しいリクエストは秒単位で追加されます。

​
詳細