Sender Constraining用にリソースサーバーを構成する

APIのSender Constrainingを有効にすると、リソースサーバーは、クライアントが証明書バウンドアクセストークンでリソースサーバーを呼び出した時はいつでもSender Constrainingを強制しなければなりません。以下により、リソースサーバーがこれを強制します。

1. 確率されたmTLS接続にクライアント証明書を要求する

2. クライアント証明書のサムプリントがアクセストークンのサムプリントと一致するか検証

Sender Constraining用にリソースサーバーを構成するには、「リソースサーバーのSender Constrainingを有効にする」をご覧ください。

認可サーバーまたはカスタマーエッジとは異なり、リソースサーバーは、証明書チェーン全体の代わりに、クライアント証明書のサムプリントのみを検証する必要があります。mTLS Sender Constrainingのために、リソースサーバーは、アクセストークンの cnfクレームを確認します。

"cnf":{"x5t#S256":"A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0"}

上記のcnfクレームの例では、x5t#S256は、アクセストークンがA4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0のサムプリントのmTLSクライアント証明書にバインドされていることを示します。クライアント証明書の検証に合格するには、リソースサーバーは、クライアント証明書にA4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0と一致するサムプリントがあることを検証しなければなりません。サムプリントの計算方法の詳細については、RFC 8705の「 JWT証明書サムプリント確認方法」のセクションをご覧ください。

クライアント証明書が送信されなかった場合、またはクライアント証明書のサムプリントが一致しなかった場合、リソースサーバーは、 HTTP 401ステータスコードおよびinvalid_tokenエラーコードを使用して、要求を拒否します。詳細については、RFC 8705の「相互TLSクライアント証明書バウンドアクセストークン」および「リソースサーバー」のセクションをご覧ください。

mTLSを使用するためにクライアントを徐々に移行するリソースサーバーについては、2つのドメインにAPIを公開することを検討するといいでしょう。1つは、非mTLSクライアントのための非mTLSドメイン、そしてもう１つはmTLS対応クライアントのためのmTLS有効ドメインです。または、mTLS有効ドメインにまったく別のmTLSのみのリソースサーバーを作成することもできます。

Auth0が発行するアクセストークンは、リソースサーバーのAPIにアクセスする必要がある送信者（つまり、クライアントアプリケーション）に制限できます。

Auth0 DashboardまたはManagement APIを使用して、リソースサーバーのSender Constrainingを有効にできます。

"proof_of_possession": {
    "mechanism": "mtls",
    "required": true
  }