> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.com/llms.txt
> Use this file to discover all available pages before exploring further.

# テナント ACL で HTTP Message Signature を構成する

> テナント ACL で HTTP Message Signature を使用して、信頼できるエッジプロキシや API ゲートウェイ以外から送信されたリクエストをブロックする方法について説明します。

この機能は、エンタープライズ計画をご利用のお客様のみが使用できます。詳細については、[価格](https://auth0.com/pricing)をお読みください。

Auth0 のテナントネットワークアクセス制御リスト (ACL) を使用すると、エンタープライズテナントは、[RFC 9421 HTTP Message Signature (HMAC-SHA256) ](https://www.rfc-editor.org/rfc/rfc9421)を用いて、受信 HTTP トラフィックの送信元を暗号学的にバリデーションし、その結果に基づいて制御を適用できます。

Auth0 のネットワーク境界でリクエストの署名を直接検査することで、トラフィックの送信元を信頼できるエッジプロキシまたは API ゲートウェイのみに限定できます。これにより、リクエストのなりすまし、パラメーターの改ざん、テナントへの直接アクセスによる迂回を防止できます。

## ユースケースとセキュリティ上の課題

認証フローをホストする際、組織ではカスタムのセキュリティポリシー、IP フィルタリング、ヘッダーの付加などを適用するために、Auth0 のダウンストリームにリバースプロキシやエッジゲートウェイ (Cloudflare Workers、Kong、Envoy など) を導入するケースがよくあります。

攻撃者に Auth0 テナントのドメイン (例：`https://YOUR_AUTH0_DOMAIN.com`) を突き止められると、`/oauth/token` や `/authorize` といった主要な認証エンドポイントに直接リクエストを送信され、エッジでのセキュリティチェックを回避されてしまいます。また、カスタムヘッダーに一般的な静的 API キーを含める方法では、キーが傍受されたり漏洩したりするおそれがあります。

## 仕組み

テナント ACL で HTTP Message Signatures を強制すると、次のように動作します。

1. エッジプロキシが、重要な HTTP 属性(`@method`、`@path`、生の `@query-param` のキーと値のペアなど)と必須のメタデータ(`created`、`expires`、`keyid`)を対象に、HMAC-SHA256 暗号署名を計算します。
2. トラフィックが Auth0 に到達すると、テナント ACL はリクエストを処理する前に、HMAC 署名とタイムスタンプのパラメーターを検証します。
3. 直接送信されたリクエスト、署名のないリクエスト、改ざんされたリクエスト、期限切れのリクエストは、Auth0 によってネットワーク層で即座にブロックされます。

### 署名の評価基準

Auth0は、署名について以下の点を確認します。

* アルゴリズムはHMAC-SHA256 (`hmac-sha256`) である必要があります。
* 署名の対象には、以下の派生HTTPリクエストコンポーネントを含めることができます。

| **HTTPメッセージコンポーネント** | **説明** |
| - | - |
| `@method` | HTTPリクエストメソッド (例：`POST`、`GET`) を検証します |
| `@path` | 対象パス (クエリパラメーターを除く) を検証します |
| `@query-param` | 特定の名前付きクエリパラメーターとその値 (例：`"@query-param";name="state"`) を検証します。署名を特定の認可リクエストに紐付けることで、リプレイ攻撃対策が強化されます |

* すべての署名入力文字列には、`created`、`expires`、`keyid`の各パラメーターを含める必要があります。これらのパラメーターがいずれか1つでも欠けているリクエストは、不一致として扱われます。
* 署名の有効期間は最大1時間 (`expires - created <= 3600`) です。また、Auth0には60秒のクロックスキュー許容範囲が組み込まれています (`created <= now + 60s` および `now <= expires + 60s`) 。
* 複数の署名ディクショナリラベルを含むリクエストは拒否されます。

## 設定

### エッジプロキシの署名鍵を登録する

エッジプロキシから送信される HTTP リクエストに署名するための HMAC-SHA256 キーを作成します。

```http theme={null}
POST /api/v2/keys/network-acls
Content-Type: application/json
Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}

{
  "name": "edge-proxy-signing-key-v1",
  "alg": "hmac-sha256",
  "value": "KEY_VALUE"
}
```

`value` フィールドには、Base64 エンコードされた文字列を指定する必要があります。デコード後のサイズは、生バイト列で 32 バイト以上 512 バイト以下である必要があります。

レスポンスの例

```json theme={null}
{
  "id": "key_aBcDeFgH",
  "name": "edge-proxy-signing-key-v1",
  "alg": "hmac-sha256",
  "fingerprint": "2af9255caa009789b913e5075072dc86af7b7c85d550201c04730431ecd335b5",
  "created_at": "2026-09-04T10:00:00.000Z",
  "updated_at": "2026-09-04T10:00:00.000Z"
}
```

返された`id` (例：`key_aBcDeFgH`) を保存してください。この値は、HTTPの`Signature-Input`ヘッダーで`keyid`パラメーターとして指定するとともに、テナント ACLのルールに紐付けます。

### アップストリームのリクエストヘッダーを構成する

エッジプロキシまたは署名サービスでは、転送するすべてのリクエストに、RFC 9421 で規定された 2 つの標準ヘッダー (`Signature-Input` と `Signature`) を付加する必要があります。プロバイダーがオープンソースのライブラリを使用している場合は、プロバイダーに確認することをお勧めします。

#### 署名ベースを構築する

RFC 9421 のセクション 2.5 に従い、署名ベースは、`Signature-Input` に記載された順序どおりに対象コンポーネントを1行ずつ並べ、最後の行に `@signature-params` を置いて構築します：

```text theme={null}
"@method": POST
"@path": /oauth/token
"@signature-params": ("@method" "@path");created=1752019200;expires=1752019500;keyid="key_aBcDeFgH"
```

#### ヘッダーの例

`Signature-Input` と `Signature` を使用したヘッダーの例を以下に示します。

##### メソッドとパス

`POST` `/oauth/token` の例

```http theme={null}
Signature-Input: sig1=("@method" "@path");created=1752019200;expires=1752019500;keyid="key_aBcDeFgH"
Signature: sig1=:Ic2zxAtZmz2iy0g7qMxEGAic6EH8t70Soh+pC6/Y5L8=:
```

##### クエリパラメーター

`GET` `/authorize?state=abc123xyz&client_id=myclient` で `state` パラメーターを使用する例

```http theme={null}
Signature-Input: sig1=("@method" "@path" "@query-param";name="state");created=1752019200;expires=1752019500;keyid="key_aBcDeFgH"
Signature: sig1=:OCnwy3NadPiHa1qmtFVHKaSxLebfdJMjqTPEOByO+yw=:
```

## テナント ACL ルールを構成する

有効な署名を必須にするには、`http_message_signature` シグナルに基づいてリクエストをブロックする[テナント ACL ルール](https://auth0.com/docs/ja-jp/secure/tenant-access-control-list)を作成してください。

### 署名のない、または無効なリクエストをブロックする

承認されたキーで署名された有効なHTTP Message Signatureを含まない受信リクエストをすべてブロックするには、以下のサンプルのような[`not_match`ルールを構成](https://auth0.com/docs/ja-jp/secure/tenant-access-control-list/configure-rules)します。`not_match`ルールの評価には、[監視モードをセットアップ](https://auth0.com/docs/ja-jp/secure/tenant-access-control-list/enable-monitoring-mode.md)することをお勧めします。

```http theme={null}
POST /api/v2/network-acls
Content-Type: application/json
Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}

{
  "description": "Block requests not signed by trusted edge proxy",
  "active": true,
  "priority": 10,
  "rule": {
    "action": { 
      "block": true 
    },
    "scope": "tenant",
    "not_match": {
      "http_message_signature": {
        "keys": [
          { "id": "key_aBcDeFgH" }
        ]
      }
    }
  }
}
```

## ダウンタイムなしのキーローテーション

ACLルールに複数の有効なキーIDを割り当てることで、ライブトラフィックを中断せずに署名シークレットをローテーションできます。

1. [Create a Network ACL key](https://auth0.com/docs/ja-jp/api/management/v2/keys/create-keys-network-acls.md)エンドポイントで新しいキーIDを生成します。

Management APIを使用するには、`create:network_acl_keys`、`update:network_acls`、`delete:network_acl_keys`のスコープを持つ[Management APIアクセストークン](https://auth0.com/docs/ja-jp/secure/tokens/access-tokens/management-api-access-tokens.md)を取得する必要があります。

2. ACLルールを更新します。具体的には、`http_message_signature.keys`配列に、現在有効なキーに加えて新しいキーIDを追加します (1つのルールにつき最大10個のキーを設定できます) 。

```json theme={null}
"keys": [
  { "id": "key_aBcDeFgH" },
  { "id": "key_xYzWvUtS" }
]
```

次のステップに進む前に、新しいキーが受け入れられることを手動で確認することをお勧めします。ルールを更新してから実際に適用されるまでに、時間差が生じる場合があります。

3. Edgeの署名を更新します。エッジプロキシを更新し、新しいkeyid (例：`key_xYzWvUtS`) を使用して受信トラフィックへの署名を開始します。

4. テナントのログを監視します。`acls_summary`ログイベントを確認し、ログの詳細にある`valid_signature_key_ids`フィールドをチェックして、受信トラフィックが新しいキーIDで正常に検証されていることを確認します。

```json theme={null}
{
  "type": "acls_summary",
  "details": {
    "stats": [
      {
        "acl_id": "acl_abc123",
        "action": "ACTION_TYPE_BLOCK",
        "valid_signature_key_ids": ["key_xYzWvUtS"]
      }
    ]
  }
}
```

5. 古いキーを廃止します。`valid_signature_key_ids`が`key_aBcDeFgH`を参照しなくなったら、ACLルールから古いキーIDを削除し、[Delete Network ACL Key](https://auth0.com/docs/ja-jp/api/management/v2/keys/delete-keys-network-acls.md)エンドポイントを呼び出します。

```http theme={null}
DELETE /api/v2/keys/network-acls/key_aBcDeFgH
```

## 制限事項

以下の制限事項を確認してください。

* テナントごとに最大10個のアクティブなキーを使用でき、ACLルールごとに最大10個のキーIDをバインドできます。
* Management APIのキーエンドポイントのレート制限は、読み取り (`network_acl_keys_read`) が10 RPS、書き込み (`network_acl_keys_write`) が5 RPSです。
