この機能は、エンタープライズ計画をご利用のお客様のみが使用できます。詳細については、価格をお読みください。
ユースケースとセキュリティ上の課題
認証フローをホストする際、組織ではカスタムのセキュリティポリシー、IP フィルタリング、ヘッダーの付加などを適用するために、Auth0 のダウンストリームにリバースプロキシやエッジゲートウェイ (Cloudflare Workers、Kong、Envoy など) を導入するケースがよくあります。 攻撃者に Auth0 テナントのドメイン (例：https://YOUR_AUTH0_DOMAIN.com) を突き止められると、/oauth/token や /authorize といった主要な認証エンドポイントに直接リクエストを送信され、エッジでのセキュリティチェックを回避されてしまいます。また、カスタムヘッダーに一般的な静的 API キーを含める方法では、キーが傍受されたり漏洩したりするおそれがあります。
仕組み
テナント ACL で HTTP Message Signatures を強制すると、次のように動作します。- エッジプロキシが、重要な HTTP 属性(
@method、@path、生の@query-paramのキーと値のペアなど)と必須のメタデータ(created、expires、keyid)を対象に、HMAC-SHA256 暗号署名を計算します。 - トラフィックが Auth0 に到達すると、テナント ACL はリクエストを処理する前に、HMAC 署名とタイムスタンプのパラメーターを検証します。
- 直接送信されたリクエスト、署名のないリクエスト、改ざんされたリクエスト、期限切れのリクエストは、Auth0 によってネットワーク層で即座にブロックされます。
署名の評価基準
Auth0は、署名について以下の点を確認します。- アルゴリズムはHMAC-SHA256 (
hmac-sha256) である必要があります。 - 署名の対象には、以下の派生HTTPリクエストコンポーネントを含めることができます。
- すべての署名入力文字列には、
created、expires、keyidの各パラメーターを含める必要があります。これらのパラメーターがいずれか1つでも欠けているリクエストは、不一致として扱われます。 - 署名の有効期間は最大1時間 (
expires - created <= 3600) です。また、Auth0には60秒のクロックスキュー許容範囲が組み込まれています (created <= now + 60sおよびnow <= expires + 60s) 。 - 複数の署名ディクショナリラベルを含むリクエストは拒否されます。
設定
エッジプロキシの署名鍵を登録する
エッジプロキシから送信される HTTP リクエストに署名するための HMAC-SHA256 キーを作成します。value フィールドには、Base64 エンコードされた文字列を指定する必要があります。デコード後のサイズは、生バイト列で 32 バイト以上 512 バイト以下である必要があります。id (例：key_aBcDeFgH) を保存してください。この値は、HTTPのSignature-Inputヘッダーでkeyidパラメーターとして指定するとともに、テナント ACLのルールに紐付けます。
アップストリームのリクエストヘッダーを構成する
エッジプロキシまたは署名サービスでは、転送するすべてのリクエストに、RFC 9421 で規定された 2 つの標準ヘッダー (Signature-Input と Signature) を付加する必要があります。プロバイダーがオープンソースのライブラリを使用している場合は、プロバイダーに確認することをお勧めします。
署名ベースを構築する
RFC 9421 のセクション 2.5 に従い、署名ベースは、Signature-Input に記載された順序どおりに対象コンポーネントを1行ずつ並べ、最後の行に @signature-params を置いて構築します：
ヘッダーの例
Signature-Input と Signature を使用したヘッダーの例を以下に示します。
POST /oauth/token の例
GET /authorize?state=abc123xyz&client_id=myclient で state パラメーターを使用する例
テナント ACL ルールを構成する
有効な署名を必須にするには、http_message_signature シグナルに基づいてリクエストをブロックするテナント ACL ルールを作成してください。
署名のない、または無効なリクエストをブロックする
承認されたキーで署名された有効なHTTP Message Signatureを含まない受信リクエストをすべてブロックするには、以下のサンプルのようなnot_matchルールを構成します。not_matchルールの評価には、監視モードをセットアップすることをお勧めします。
ダウンタイムなしのキーローテーション
ACLルールに複数の有効なキーIDを割り当てることで、ライブトラフィックを中断せずに署名シークレットをローテーションできます。- Create a Network ACL keyエンドポイントで新しいキーIDを生成します。
Management APIを使用するには、
create:network_acl_keys、update:network_acls、delete:network_acl_keysのスコープを持つManagement APIアクセストークンを取得する必要があります。- ACLルールを更新します。具体的には、
http_message_signature.keys配列に、現在有効なキーに加えて新しいキーIDを追加します (1つのルールにつき最大10個のキーを設定できます) 。
次のステップに進む前に、新しいキーが受け入れられることを手動で確認することをお勧めします。ルールを更新してから実際に適用されるまでに、時間差が生じる場合があります。
-
Edgeの署名を更新します。エッジプロキシを更新し、新しいkeyid (例：
key_xYzWvUtS) を使用して受信トラフィックへの署名を開始します。 -
テナントのログを監視します。
acls_summaryログイベントを確認し、ログの詳細にあるvalid_signature_key_idsフィールドをチェックして、受信トラフィックが新しいキーIDで正常に検証されていることを確認します。
- 古いキーを廃止します。
valid_signature_key_idsがkey_aBcDeFgHを参照しなくなったら、ACLルールから古いキーIDを削除し、Delete Network ACL Keyエンドポイントを呼び出します。
制限事項
以下の制限事項を確認してください。- テナントごとに最大10個のアクティブなキーを使用でき、ACLルールごとに最大10個のキーIDをバインドできます。
- Management APIのキーエンドポイントのレート制限は、読み取り (
network_acl_keys_read) が10 RPS、書き込み (network_acl_keys_write) が5 RPSです。