レート制限ポリシー

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

​

テナントのリクエスト上限

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

​

API レート制限

Auth0 では、API エンドポイントにかかわらず、特定の API に対するリクエスト数が制限されます。API の制限は、次の要素によって異なる場合があります。

• API
  • 認証
  • Management
• テナント種別 (Production、Development、Staging の別)
• サブスクリプションレベル (Free、Essential、Professional、Enterprise Public と Private)

たとえば、Free の非本番テナントでは、有料サブスクリプションの本番テナントとは異なる制限が適用される場合があります。具体的なレート制限の構成については、レート制限の構成を参照してください。

​

ユーザーリクエスト

1 回のエンドユーザーリクエスト (例: Login や Signup) によって、通常は Authentication API Endpoints に対する複数のリクエストが発生します。エンドユーザーリクエスト数と Authentication API へのリクエスト数の実際の比率は、主に次のような要因によって決まります。

• 認証対象のエンティティ (例: マシン、またはエンドユーザーのモバイル / デスクトップ アプリケーション)
• 認証エクスペリエンス (例: 新しい Universal Login または クラシックログイン)
• 認証フロー (例: Login、Signup、または Change Password)
• 認証フローの種類 (例: ユーザー名 / パスワード による Login、Social Login による Login、既存の Authentication Token がすでに存在する場合の Login)

拡張を活用しているお客様は、拡張の Configuration に応じて、Authentication API だけでなく Management API へのリクエストがさらに増える可能性もあります。 Auth0 の構成が API 使用量にどのような影響を与えるかを見積もる方法については、Rate Limit Use Cases を参照してください。

​

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

Auth0 では、API エンドポイントに対するリクエスト数を制限しており、場合によってはエンドポイントの操作回数も制限しています。 API エンドポイントの制限は、次の要素によっても異なります。

• API
• テナントの種類
• サブスクリプションレベル

たとえば、Free の非本番テナントには、有料サブスクリプションの本番テナントとは異なる制限があります。

​

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

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

​

その他の制限

​

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

データベース接続では、Auth0 はユーザーアカウントと IP アドレスに基づいて、特定の種類の繰り返しログイン試行を制限します。システム全体の稼働状況を守るため、Auth0 では負荷を軽減する目的で、ユーザー名/パスワードに対するレート制限を設けています。Auth0 は高度にカスタマイズできるため、サービス品質の低下につながるおそれがあります。原因としては、次のようなものが考えられます。

• 高負荷のストレステスト
• ベンチマークテスト
• ユーザーに複数回のログインを発生させる非効率なコード

リクエストには、Auth0 API ごとの各ポリシーに記載された制限が適用されます。 さらに、同一ユーザーに対するログインのレート制限もあります。1 つの IP アドレスから同じユーザーアカウントに対して 1 分間に 20 回ログイン試行が行われると、レート制限が適用されます。その後は、そのユーザーに対して 1 分あたり 10 回まで試行できます。成功・失敗を問わず、すべてのログイン試行がこの制限のカウント対象になります。

​

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

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

​

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

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

​

Public Performance Burst

Public Performance Burst は、既存の Public Cloud デプロイを強化する、Enterprise サブスクリプション向けのアドオンです。この提供により、Authentication API のリクエスト上限を、既定の Enterprise リクエスト上限である 100 RPS の倍率まで、毎月最大 48 時間動的に引き上げることができます。 現在、Public Performance Burst には 3 つの修飾要因 (2x、3x、4x) があり、それぞれ Authentication API に対して 200、300、400 RPS を毎月最大 48 時間まで利用できます。この 48 時間は 1 分単位で集計され、毎月の許可枠から差し引かれるため、毎月 2880 回の 1 分間隔で API をその倍率レベルで利用できます。 Authentication API へのリクエスト量が既定の 100 RPS を超えると、毎月の利用枠から 1 分分が差し引かれ、その倍率に対応するレートでトラフィックが許可されます。その時点から連続する 1 分間は、追加の差し引きなしで、その倍率の範囲内にトラフィックを維持できます。 差し引き間隔イベントは、テナントログ で監視できます。差し引きが発生するたびに、消費済みの利用枠と残りの利用枠に関する情報を含む、対応する 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 か月を通して 1,500 RPS
• バースト/ピーク容量: 月あたり最大 80 時間まで 3,000 RPS

認証トランザクションがベース API リクエスト上限を超えて急増すると、月間割り当てから 1 時間分が差し引かれます。その時点から、トラフィックは連続する 1 時間を通して高いレートを維持できます。しきい値を再び超えた場合も、同様に追加で差し引かれます。 80 時間の割り当てを使い切ると、新しい月間割り当てが有効になるまで、認証トラフィックはベース容量までにレート制限されます。

​

拡張の同時実行制限

システムの可用性とリソースの公平な利用を確保するため、Auth0 では、Actions、フック、ルール、カスタムデータベース接続、Extensions、カスタム OAuth 2.0 接続を含むすべての拡張プロダクト全体で、同時に処理中のリクエスト数を制限しています。同時リクエスト数の上限を超えたテナントでは、処理中のリクエストが完了するまで、新しいリクエストでエラーが発生する可能性があります。同時実行制限は以下のとおりです。 同時実行数は、想定 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 分あたりのリクエスト数として計算される場合、新しいリクエストは秒単位で追加されます。

​

詳細情報

• エンティティ制限ポリシー
• レート制限のユースケース