送信者制約は、および Connect (OIDC) のセキュリティメカニズムであり、アクセストークンとを、それらを取得した特定のクライアントアプリケーションに暗号学的に結び付けることで、トークンの盗難や不正利用を防ぎます。
Auth0は、mTLSによる送信者制約とDemonstrating Proof-of-Possession (DPoP) をサポートしています。クライアントアプリケーションで送信者制約を有効にする場合は、API呼び出し先のに対しても、送信者制約を強制する必要があります。
Auth0で送信者制約を設定するには、次の操作が必要です。
が Auth0 で送信者制約されるかどうかは、クライアントアプリケーションとリソースサーバーの送信者制約の設定方法によって決まります。
-
要求されたオーディエンス: トークンリクエストで、要求されたオーディエンスが
/userinfo のみか、/userinfo エンドポイントでのみ使用することを意図しているか、または openid スコープも要求した場合に /userinfo を含む可能性があるカスタム API かどうかによって、アクセストークンが送信者制約されるかどうかが決まります。
-
クライアントアプリケーション: クライアントアプリケーションで送信者制約を
required に設定しているかどうか。
-
リソースサーバー: リソースサーバーに送信者制約を設定しているかどうか。
none: リソースサーバーに送信者制約を設定していません。
allowed: 送信者制約方式を設定して、リソースサーバーに送信者制約を構成しています。
required: リソースサーバーに送信者制約を必須として設定しています。つまり、アクセストークンはアプリケーションに対して送信者制約されている必要があります。すべてのアプリケーション、またはパブリックアプリケーションのみに対して送信者制約を必須にできます。送信者制約方式が必要です。
送信者制約方式として mTLS を使用する場合、送信者制約は常にすべてのアプリケーションで必須です。mTLS はパブリックアプリケーションをサポートしていないため、mTLS 送信者制約をパブリッククライアントのみに限定することはできません。
-
所有証明: クライアントアプリケーションがトークンリクエストで所有証明アサーションを送信したかどうか。
- mTLS 送信者制約: 所有証明は、TLS ハンドシェイク中にクライアントが特定の秘密鍵 (クライアント証明書に関連付けられたもの) を正常に提示することで証明されます。
- DPoP: 所有証明は、クライアントが秘密鍵で暗号学的に署名した DPoP Proof JWT を作成し、関連付けられたアクセストークンを使用するすべてのリクエストの DPoP HTTP ヘッダーに
DPoP Proof JWT を含めることで実現されます。
次の表は、さまざまなクライアントリクエストパラメーターと Auth0 リソースサーバーの構成に基づいて、アクセストークンがどのように発行されるか、および送信者制約されるかどうかを示しています。
| 要求されたオーディエンスタイプ | クライアントで PoP が必須か | クライアントが Proof-of-Possession (PoP) を送信したか | Auth0 リソースサーバーポリシー: None | Auth0 リソースサーバーポリシー: Allowed (必須ではない) | Auth0 リソースサーバーポリシー: Required |
|---|
| Userinfo のみ | いいえ | いいえ | 発行される、送信者制約なし | 該当なし | 該当なし |
| Userinfo のみ | いいえ | はい | 発行される、送信者制約あり | 該当なし | 該当なし |
| Userinfo のみ | はい | いいえ | 発行されない | 該当なし | 該当なし |
| Userinfo のみ | はい | はい | 発行される、送信者制約あり | 該当なし | 該当なし |
| カスタムオーディエンス (Userinfo を含む可能性あり) | いいえ | いいえ | 発行される、送信者制約なし | 発行される、送信者制約なし | 発行されない |
| カスタムオーディエンス (Userinfo を含む可能性あり) | いいえ | はい | 発行される、送信者制約なし | 発行される、送信者制約あり | 発行される、送信者制約あり |
| カスタムオーディエンス (Userinfo を含む可能性あり) | はい | いいえ | 発行されない | 発行されない | 発行されない |
| カスタムオーディエンス (Userinfo を含む可能性あり) | はい | はい | 発行されない | 発行される、送信者制約あり | 発行される、送信者制約あり |
クライアントアプリケーションに送信者制約を必須にすると、アクセストークンはそのアプリケーションに紐付けられます。Auth0 はリクエストを検証し、トークンを要求したアプリケーションだけが、そのトークンを使用して関連するリソースにアクセスできるようにします。
クライアントアプリケーションで送信者制約を必須に設定すると、リソースサーバーの設定時に、送信者制約方式として mTLS または DPoP を指定できます。
クライアントアプリケーションの送信者制約は、 または で設定できます。
Auth0 Dashboard
Management API
- Dashboard > Applications > Applications に移動し、設定するアプリケーションを選択します。
- Settings で Token Sender-Constraining までスクロールします。
- Require Sender Constraining をオンにします。アプリケーションの送信者制約の必須設定を解除するには、オフにします。
クライアントの送信者制約を設定するには、Management API を使用します。クライアントで送信者制約を必須にするには、クライアント設定を更新する に対して PATCH リクエストを送信します。require_proof_of_possession パラメーターを true に設定します。curl -L -X PATCH 'https://{YOUR_DOMAIN}/api/v2/clients/{YOUR_CLIENT_ID}' \
-H 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \
-H 'Content-Type: application/json' \
-d '{"require_proof_of_possession": true}'
送信者制約の必須設定を解除するには、require_proof_of_possession パラメーターを false に設定します。curl -L -X PATCH 'https://{YOUR_DOMAIN}/api/v2/clients/{YOUR_CLIENT_ID}' \
-H 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \
-H 'Content-Type: application/json' \
-d '{"require_proof_of_possession": false}'
Auth0 が発行するアクセストークンは、リソースサーバー上の API へのアクセスに使用するクライアントアプリケーション (送信者) に制約できます。
Auth0 Dashboard または Management API を使用して、リソースサーバーの送信者制約を設定できます。
Auth0 Dashboard
Management API
トークンバインディングまたは送信者制約を有効にするには、API の API Settings で設定を行います。
-
Auth0 Dashboard > Applications > APIs に移動します。
-
設定する API を選択します。
-
Settings タブで、Token Sender-Constraining セクションを探します。
-
次の項目を設定します。
-
送信者制約方式:
- なし: リソースサーバーに送信者制約方式を設定しません。
- mTLS: リソースサーバーの送信者制約方式として mTLS を有効にします。
- DPoP: リソースサーバーの送信者制約方式として DPoP を有効にします。
-
トークン送信者制約を必須にする: この API に適用する送信者制約ポリシーを選択します。
- 常に: すべてのアプリケーションで送信者制約を必須にします。mTLS を使用する場合に選択できるのはこのオプションのみです。
- パブリックアプリケーションの場合: パブリックアプリケーションでのみ送信者制約を必須にします。このオプションは mTLS を使用する場合は選択できません。
- しない: 送信者制約は必須ではありません。
Management API で送信者制約を有効にするには、リソースサーバーの更新 に PATCH リクエストを送信します。proof_of_possession オブジェクトのパラメーターを次のように設定します。| パラメーター | 説明 |
|---|
mechanism | 送信者制約方式を設定します: none、mtls、または dpop。 |
required | 必須。true に設定すると、この API 向けにアプリケーションに発行されるアクセストークンは、そのアプリケーションに制約されます。この要件をどのアプリケーション種別に適用するかは required_for で指定します。false に設定すると、送信者制約は必須ではありません。 |
required_for | required が true の場合に、どのアプリケーション種別で送信者制約を必須にするかを絞り込みます: all_clients (すべてのアプリケーション) または public_clients (パブリックアプリケーションのみ) 。指定しない場合のデフォルトは all_clients です。mTLS を使用する場合、有効なのは all_clients のみです。 |
次のコードサンプルは、リソースサーバーに mTLS 送信者制約を設定するリクエストボディの例です。mTLS では required_for に all_clients のみをサポートしており (これがデフォルト値です) 、そのため指定する必要はありません。curl -L -X PATCH 'https://{YOUR_DOMAIN}/api/v2/resource-servers/{YOUR_RESOURCE_SERVER_ID}' \
-H 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-d '{
"proof_of_possession": {
"mechanism": "mtls",
"required": true
}
}'
次のコードサンプルは、パブリックアプリケーションでのみ必須となる DPoP 送信者制約をリソースサーバーに設定するリクエストボディの例です。curl -L -X PATCH 'https://{YOUR_DOMAIN}/api/v2/resource-servers/{YOUR_RESOURCE_SERVER_ID}' \
-H 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-d '{
"proof_of_possession": {
"mechanism": "dpop",
"required": true,
"required_for": "public_clients"
}
}'
次のコードサンプルは、すべてのアプリケーションで必須となる DPoP 送信者制約を設定します。all_clients はデフォルト値のため、required_for は省略できます。curl -L -X PATCH 'https://{YOUR_DOMAIN}/api/v2/resource-servers/{YOUR_RESOURCE_SERVER_ID}' \
-H 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-d '{
"proof_of_possession": {
"mechanism": "dpop",
"required": true
}
}'
次のコードサンプルは、リソースサーバーの送信者制約を無効にします (Dashboard で “Never” を選択するのと同等です) 。curl -L -X PATCH 'https://{YOUR_DOMAIN}/api/v2/resource-servers/{YOUR_RESOURCE_SERVER_ID}' \
-H 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-d '{
"proof_of_possession": null
}'