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 がレート制限の超過を検知して顧客に通知するのは、環境内の特定のテナントでレート制限を超えた場合に限られます。顧客が単一の Production Tenant を維持する大半の Private Cloud のユースケースでは、これは問題になりません。一方で、複数の本番テナントをプロビジョニングするユースケースでは、環境内のすべてのテナントをまたいだ想定負荷を考慮し、必要に応じて追加の監視を実装する必要があります。
環境レート制限を超過すると、サービスレベル契約 (SLA) は無効になります。
Private Cloud の負荷テストに関する考慮事項については、Private Cloud on AWS および Private Cloud on Azure を参照してください。

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

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

​
API のレート制限

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

​
ユーザーリクエスト

1 回のエンドユーザーリクエスト (例: Login や Signup) では、通常、Authentication API エンドポイントに対して複数のリクエストが発生します。実際のエンドユーザーリクエストと Authentication API の比率は、主にいくつかの要因によって異なります。
  • 認証対象のエンティティ (例: マシン、またはエンドユーザー向けのモバイル / デスクトップアプリケーション)
  • 認証エクスペリエンス (例: 新しい または Classic Login)
  • 認証フロー (例: Login、Signup、または Change Password)
  • 認証フローの種類 (例: ユーザー名 / パスワードでの Login、Social Login での Login、既存の Authentication Token がすでにある状態での Login)
拡張を利用しているお客様は、拡張の設定に応じて、Authentication API だけでなく へのリクエストもさらに追加される可能性があります。 Auth0 の設定が API 使用量にどのように影響するかを見積もる方法については、Rate Limit Use Cases を参照してください。

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

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

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

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

​
その他の制限

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

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

ユーザーを保護する制限

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

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

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

​
Native social login の制限

Native social login フローのリクエストに適用される制限は、次の初期条件に基づいてリクエストボディから識別されます。

​
Public Performance Burst

Public Performance Burst は、既存の Public Cloud デプロイメントを強化する、Enterprise subscription で利用可能な add-on です。このオファリングにより、Authentication API の request 上限を、既定の enterprise request 上限である 100 RPS の倍率まで、月あたり最大 48 時間、動的に引き上げることができます。
この add-on で拡張されるのは Authentication API の request 上限のみであり、Management API や、Authentication API の scope 外でレート制限が適用されるその他のエンドポイントには適用されません。
現在、Public Performance Burst には 3 種類の倍率 (2x、3x、4x) があり、Authentication API に対して、それぞれ 200、300、400 RPS を月あたり最大 48 時間利用できます。この 48 時間は 5 分単位で集計され、月間許容量から差し引かれます。そのため、毎月 576 回の 5 分区間にわたって、API を倍率レベルで利用できます。 Authentication API への request 量が既定の 100 RPS を超えると、月間許容量から 5 分区間が 1 回分差し引かれ、その倍率に応じたレートでトラフィックが許可されます。その時点から連続する 5 分間は、追加の差し引きなしで、その倍率の範囲内にトラフィックを維持できます。 差し引き区間イベントは、tenant logs で監視できます。差し引きが発生するたびに、消費済みの許容量と残りの許容量に関する情報を含む、対応する appi tenant log event type が生成されます。 詳細については、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 か月を通して 1,500 RPS
  • バースト/ピーク容量: 月あたり最大 80 時間まで 3,000 RPS
認証トランザクションがベースの API リクエスト上限を超えた場合、月間許容量から 1 時間分が差し引かれます。その時点から、連続する 1 時間はトラフィックを高いレートのまま維持できます。しきい値を再び超えた場合も、同じ方法で追加の差し引きが行われます。 80 時間の許容量を使い切ると、新しい月間許容量が有効になるまで、認証トラフィックにはベース容量までのレート制限が適用されます。

​
拡張の同時実行数制限

システムの可用性とシステムリソースの公平な利用を確保するため、Auth0 では、Actions、Hooks、Rules、カスタムデータベース接続、Extensions、カスタム OAuth2 接続を含むすべての拡張機能において、処理中の同時リクエスト数を制限しています。同時リクエスト数の上限を超えたテナントでは、処理中のリクエストが完了するまで、新しいリクエストでエラーが発生することがあります。同時実行数制限は以下のとおりです。 同時実行数は、想定される RPS に各リクエストのレイテンシを掛けることで計算できます。たとえば、関連付けられた post-login Actions が 2 つあり、それぞれの実行に 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 分あたりのリクエスト数で計算される場合、新しいリクエストは秒単位で追加されます。

​
関連情報