送信者制約を構成する

送信者制約（別名トークンバインディング）は、アクセストークンを秘密鍵などの暗号鍵にバインドできるようにします。これにより、アクセストークンを要求したアプリケーションのみが、これを使用して関連するリソースにアクセスできるようになり、トークンの盗難やリプレイ攻撃が軽減されます。

Highly Regulated Identityは、「mTLSトークンバインディング」としても知られる相互TLSクライアント証明書バインドアクセストークンを通じてトークン制約機能を提供します。送信者制約の構成方法の詳細は、以下を参照してください。

アクセストークンが証明書にバインドされる仕組み

アプリケーションをmTLS用に設定した後、アプリケーションは相互TLSを使用してアクセストークンを要求できるようになります。認可サーバーは、アクセストークンのペイロードに確認クレーム（cnf）を含めることによって、クライアント証明書を発行されたアクセストークンにバインドします。このcnfには、クライアント証明書のサムプリントを表すハッシュが含まれています。

以下のコード例は、証明書にバインドされたアクセストークンのペイロードを示しています。

{
  "iss": "https://server.example.com",
  "sub": "ty.webb@example.com",
  "exp": 1493726400,
  "nbf": 1493722800,
  "cnf":{
    "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
  }
}

Was this helpful?

/

トークンの検証

mTLSトークンバインディングが有効になると、アクセストークンは、これらを要求したアプリケーション（つまり「送信者」アプリケーション）の制約を受けることになります。リソースサーバーは、要求で送信されたクライアント証明書がアクセストークントークンに含まれるものと同じサムプリントを持っていることを検証する責任があります。これは「Proof-of-possession（所有の証明）」の検証とも呼ばれています。

アプリケーションが証明書にバインドされたアクセストークントークンを使用する権限があることを検証するために、リソースサーバーは要求で使用されたクライアント証明書のサムプリントを生成し、それをcnfクレームのサムプリントと比較する必要があります。cnfクレームの形式と証明書のサムプリントの生成方法に関する詳細は、RFC 8705の「JWT Certificate Thumbprint Confirmation Method（JWT証明書サムプリント確認方法）」に関するセクションを参照してください。

アプリケーションが要求にクライアント証明書を送信しなかった場合、またはクライアント証明書のサムプリントが一致しなかった場合、リソースサーバーは、HTTP 401ステータスコードおよびinvalid_tokenエラーコードを使用して、その要求を拒否します。

以下の表は、アプリケーション（OAuthクライアント）とAPI（OAuthリソースサーバー）のmTLS設定に基づいて、発行されたトークンが送信者制約を受けているかどうかを説明したものです。この表は、以下のシナリオに対応しています。

  • 要求されたオーディエンスのタイプ：userinfoのみ、またはuserinfoを含むカスタムオーディエンス

  • 送信者制約がクライアントによってrequiredとされているかどうか

  • リソースサーバーに対して送信者制約が設定されているかどうか：

    • none：リソースサーバーに対して送信者制約が設定されていません。

    • allowed：mTLSを送信者制約メソッドとして設定することで、リソースサーバーに対して送信者制約が構成されています。

    • required：リソースサーバーに対して送信者制約が必須とされています。つまりアクセストークンは、アプリケーションに対する送信者制約を受けている必要があります。送信者制約メソッドが必要です。

  • クライアントアプリケーションが、トークン要求にProof-of-Possession（所有の証明）アサーションを送信したかどうか。

null