Auth0 では、最適なパフォーマンスを維持し、、技術的なエラー、または正当であっても過剰なトラフィックから保護するために、サービスの利用を制限しています。最適なユーザー体験を実現できるよう、Auth0 がどのように制限を適用しているかを確認し、アプリケーションを設定することをお勧めします。
Auth0 は、過剰なリクエストからサービスを保護し、サービスの中断や性能低下からお客様を守るために、各種の制限を設けています。
Auth0 では、以下のようなさまざまな制限を監視しており、多くの場合は実際に適用しています。
- 環境へのリクエスト (Private Cloud のみ)
- API または API エンドポイント経由のテナントへのリクエスト
- その他の制限
環境のリクエスト制限 (Private Cloud のみ)
環境のレート制限を超過すると、Service Level Agreement (SLA) は無効になります。
-
API
-
テナントの種類 (Production、Development、Staging)
-
サブスクリプションレベル (Free、Essential、Professional、Enterprise Public、Private)
たとえば、無料の非本番テナントでは、有料サブスクリプションの本番テナントとは異なる制限が適用される場合があります。具体的なレート制限の設定については、Rate Limit Configurationsを参照してください。
1 回のエンドユーザーリクエスト (例: Login や Signup) によって、通常は Authentication API エンドポイントに対して複数の request が発生します。エンドユーザーリクエストと Authentication API の実際の比率は、主に次のような要因によって異なります。
- 認証対象のエンティティ (例: マシン、またはエンドユーザー向けのモバイル / デスクトップ アプリケーション)
- 認証エクスペリエンス (例: 新しい または Classic Login)
- 認証フロー (例: Login、Signup、またはパスワード変更)
- 認証フローの種類 (例: ユーザー名 / パスワードによる Login、ソーシャルログインによる Login、既存の Authentication Token がすでにある状態での Login)
Extensibility を利用している場合は、その設定内容によって、Authentication API だけでなく、 への request がさらに増える可能性もあります。
Auth0 の設定が API 使用量にどのような影響を与えるかを見積もる方法については、レート制限のユースケース を参照してください。
Auth0 では、API エンドポイントに対するリクエスト数が制限されており、場合によってはエンドポイント操作の回数も制限されます。API エンドポイントの制限は、次の要素によっても異なります。
たとえば、無料の非本番テナントには、有料サブスクリプションの本番テナントとは異なる制限が適用されます。
テナントへのリクエストが行われると、Auth0 はまず API 全体のグローバル制限に照らしてリクエストを評価し、次に特定の API エンドポイントのレート制限に照らして評価します。
データベース接続では、Auth0 はユーザーアカウントと IP アドレスに応じて、特定の種類の繰り返しログイン試行を制限します。システム全体の稼働状況を保つため、Auth0 では負荷を軽減するために、ユーザー名とパスワードを使ったログインに対してレート制限を設けています。Auth0 は高度にカスタマイズできるため、サービスの品質低下につながるリスクがあります。原因としては、次のようなものがあります。
- 高負荷のストレステスト
- ベンチマークテスト
- ユーザーが何度もログインすることになる非効率なコード
リクエストには、Auth0 API ごとの各ポリシーに記載されている制限が適用されます。
さらに、同一ユーザーのログインに対するレート制限もあります。1 つの IP アドレスから 1 分間に同じユーザーアカウントへ 20 回ログインが試行されると、レート制限が適用されます。その後は、そのユーザーに対して 1 分あたり 10 回まで試行できます。成功したログイン試行と失敗したログイン試行は、どのような組み合わせでもこの制限の対象としてカウントされます。
多要素認証のSMSメッセージ制限 (エンドユーザーのみ)
この add-on で拡張されるのは Authentication API のリクエスト上限のみであり、Management API や、Authentication API の範囲外でレート制限が適用されるその他のエンドポイントには適用されません。
appi テナントログイベント種別が生成されます。
詳細については、Rate Limits - Enterprise の Authentication API セクションを参照してください。
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、カスタムデータベース接続、Extensions、カスタム OAuth2 接続を含むすべての拡張機能において、同時に処理中のリクエスト数を制限しています。同時リクエスト数の上限を超えたテナントでは、処理中のリクエストが完了するまで、新しいリクエストでエラーが発生することがあります。同時実行数の上限は以下のとおりです。
同時実行数は、想定される RPS に各リクエストのレイテンシーを掛けることで計算できます。たとえば、2 つの Post-Login Action が関連付けられており、それぞれの実行に 250ms かかり、ログインの合計 RPS が 400 のテナントでは、想定される同時実行数は (2 * (400 requests / 1 second) * (.25 seconds / 1 request)) = 200 です。
これらの同時実行数の上限による影響をテナントが受けないようにするには、外部 API の呼び出しなど、長時間実行される可能性がある拡張機能のロジックに、適切なタイムアウトを設定してください。
Auth0 では、API に対してレート制限とバースト制限を設定しています。レート制限がシステムで継続的に許容される最大トラフィック量であるのに対し、バースト制限は一定時間内にシステムが許容する短期的な最大トラフィック量です。Auth0 のレート制限とバースト制限は連携して機能し、変動するトラフィック量に対してより適切な制限を実現します。
Auth0 のレート制限では、次の設定を含むトークンバケットアルゴリズムを使用します。
-
制限キー:
-
通常、レート制限キーは主に次の 2 つの要素に基づきます。
-
場合によっては、追加の要素として次のものが含まれます。
-
制限値:
- バケットサイズ: API またはエンドポイントが通常受け取るリクエスト、または特定のユーザーや IP アドレスから受け取るリクエストの最大数。この上限に達するまでは、新しいリクエストが追加されます。
- 補充レート: バケットに新しいリクエストが追加される速度。
Auth0 はこれら 2 つの数値から、バースト制限と持続レート制限を計算します。
- バースト制限: バケットサイズに等しい。
- 持続レート制限: 1 分あたりまたは 1 秒あたりのリクエスト数で表した補充レート。
持続レート制限が 1 秒あたりのリクエスト数で計算される場合、新しいリクエストはミリ秒単位で追加されます。持続レート制限が 1 分あたりのリクエスト数で計算される場合、新しいリクエストは秒単位で追加されます。
Authenticate
Manage Users
Customize
Platform