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

​
レート制限の概要

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 のユースケースでは、お客様は単一の本番テナントを運用しているため、これは問題になりません。しかし、複数の本番テナントをプロビジョニングするユースケースでは、環境内のすべてのテナントにまたがる想定負荷を考慮し、必要に応じて追加の監視を実施する必要があります。
環境レート制限を超過すると、Service Level Agreement (SLA) は無効になります。
Private Cloud の負荷テストに関する考慮事項については、Private Cloud on AWS および Private Cloud on Azure を参照してください。

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

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

​
API のレート制限

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

​
ユーザーリクエスト

1 回のエンドユーザーリクエスト (例: Login や Signup) では、通常、Authentication API エンドポイントに対して複数のリクエストが発生します。  実際のエンドユーザーリクエスト数と Authentication API へのリクエスト数の比率は、いくつかの要因によって異なります。
  • 認証対象のエンティティ (例: マシン、またはエンドユーザー向けのモバイルアプリケーションやデスクトップアプリケーション)
  • 認証エクスペリエンス (例: 新しい または Classic Login)
  • 認証フロー (例: Login、Signup、または Change Password)
  • 認証フローの種類 (例: ユーザー名 / パスワードでの Login、Social Login での Login、既存の Authentication Token がすでに存在する状態での Login)
Extensibility を活用しているお客様は、その設定によっては、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時間以内にお使いの端末へ11件以上のSMSメッセージを送信しようとすると、レート制限の超過に関するエラーメッセージが表示されます。 メッセージ送信制限を超えた場合は、最初のメッセージのリクエストから少なくとも1時間待ってから、次のリクエストを行う必要があります。以降は、さらに1時間経過するごとに1回ずつ追加で試行できます。

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

ネイティブソーシャルログインフローのリクエストに適用される制限は、以下の初期条件に基づいてリクエスト本文から識別されます。

​
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
認証トランザクションが基本 API リクエスト上限を超えてバーストすると、月間割り当てから 1 時間分が差し引かれます。その時点から連続する 1 時間は、トラフィックを高いレートのまま維持できます。再びしきい値を超えた場合も、同様に追加で差し引かれます。 80 時間分の割り当てを使い切ると、新しい月間割り当てが適用されるまで、認証トラフィックには基本容量までのレート制限が適用されます。

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

システムの可用性とシステムリソースの公平な利用を確保するため、Auth0 ではすべての拡張機能製品 (Actions、Hooks、Rules、Custom Database Connections、Extensions、Custom 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 分あたりのリクエスト数で計算される場合、新しいリクエストは秒単位で追加されます。

​
詳しくはこちら