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 によるログイン、Social Login によるログイン、既存の認証トークンがすでにある場合のログイン)
拡張機能 を利用している場合は、その設定内容によっては、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 の倍率まで、月あたり最大 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 トランザクションがベース API リクエスト上限を超えてバーストした場合、月間割り当てから 1 時間分が差し引かれます。その時点から連続する 1 時間の間は、トラフィックを高いレートのまま維持できます。しきい値を再び超えた場合も、同じ方式で追加の差し引きが行われます。 80 時間の割り当てを使い切ると、新しい月間割り当てが適用されるまで、Authentication トラフィックはベース容量までレート制限されます。

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

システムの可用性を確保し、システムリソースの公平な利用を維持するため、Auth0 はすべての拡張機能プロダクト (Actions、Hooks、Rules、Custom Database Connections、Extensions、Custom OAuth2 connections) 全体で、同時に処理中のリクエスト数を制限しています。同時リクエスト数の上限を超えたテナントでは、処理中のリクエストが完了するまで、新規リクエストでエラーが発生することがあります。同時実行数の上限は以下のとおりです。
サブスクリプション同時実行数の上限 (テナントごと)
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 に各リクエストのレイテンシを掛け合わせることで算出できます。たとえば、post-login Action が 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 分あたりのリクエスト数で計算される場合、新しいリクエストは秒単位で追加されます。

​
詳細情報