メインコンテンツへスキップ
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 のユースケースでは、これは問題になりません。一方、複数の本番テナントをプロビジョニングするユースケースでは、環境内のすべてのテナントをまたいだ想定負荷を考慮し、必要に応じて追加の監視を実装する必要があります。
FeatureAuthentication APIAll Other APIs (including 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)
  • 認証フロー (例: ログイン、サインアップ、またはパスワード変更)
  • 認証フローの種類 (例: ユーザー名 / パスワードによるログイン、ソーシャルログインによるログイン、既存の認証トークンがすでにある場合のログイン)
拡張機能を利用しているお客様は、拡張機能の設定によっては、Authentication API だけでなく に対しても、さらに多くのリクエストが発生する可能性があります。 Auth0 の設定が API 使用量にどのような影響を与えるかを見積もる方法については、レート制限のユースケースを参照してください。

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

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

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

テナントに対するリクエストが発生すると、Auth0 はまず API 全体の上限に対してそのリクエストを評価し、その後、特定の API エンドポイントのレート制限に対して評価します。

​
その他の制限事項

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

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

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

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

​
多要素認証の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 オファリングは、既存のパブリッククラウド環境を強化する、エンタープライズサブスクリプション向けのアドオンです。このオファリングでは、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 時間は 1 分単位で計測され、月間許容量から差し引かれるため、毎月 1 分間の区間 2880 回分まで、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、Custom Database Connections、Extensions、Custom OAuth2 connections) にまたがる同時処理中のリクエスト数を制限しています。同時リクエスト制限を超えたテナントでは、処理中のリクエストが完了するまで、新しいリクエストでエラーが発生する可能性があります。同時実行制限は次のとおりです。
Subscription同時実行制限 (テナントごと)
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 に各リクエストのレイテンシーを掛けることで計算できます。たとえば、それぞれ 250ms かかる 2 つの post-login Actions が関連付けられており、ログイン全体の 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 分あたりのリクエスト数で計算される場合、新しいリクエストは秒単位で追加されます。

​
参考情報