送信者制約

Auth0 でトークンに送信者制約を適用する方法を学びます。

送信者制約は、OAuth 2.0 と OpenID Connect (OIDC) のセキュリティメカニズムで、アクセストークンと リフレッシュトークン を、それらを要求したアプリケーションに暗号学的に結び付けることで、トークンの窃取や不正利用を防ぎます。

従来、OAuth 2.0 の アクセストークン はベアラートークンです。つまり、トークンを「保持」または所持している者は誰でもそのトークンを使用できます。ベアラートークンが盗まれたり漏えいしたりすると、攻撃者はそれを リソースサーバー (API) に提示し、正当なクライアントアプリケーションまたはユーザーになりすまして、不正にアクセスできる可能性があります。

送信者制約により、リソースサーバーにアクセストークンを提示するクライアントアプリケーションが、そのアクセストークンの正当な所有者であることを保証できます。クライアントアプリケーションがアクセストークンの正当な所有者でない場合、リソースサーバーは API リクエストを拒否します。

​

仕組み

送信者制約は、次の 2 つの方法のいずれかで実装できます。

• トランスポート層での相互 TLS (mTLS) 証明書バインディング:

  • メカニズム: クライアントアプリケーションが Auth0 認可サーバーにアクセストークンを要求する際、相互 TLS (mTLS) 接続を確立します。この接続では、クライアントアプリケーションとサーバーの双方が互いの X.509 証明書を提示し、検証します。
  • バインディング: Auth0 認可サーバーは、発行したアクセストークンに、クライアントアプリケーションの証明書のサムプリントを含む確認 (cnf) クレームを直接含めます。
  • 所持証明: クライアントアプリケーションが mTLS にバインドされたアクセストークンを使用してリソースサーバーにアクセスする場合、同じ証明書を使用して再度 mTLS 接続を確立する必要があります。リソースサーバーは、クライアントアプリケーションが提示した証明書が、そのアクセストークンにバインドされている証明書と一致することを検証します。一致しない場合、リソースサーバーはリクエストを拒否します。
  • 利点: 攻撃者がアクセストークンを盗んだとしても、正しい mTLS 接続の確立に必要な対応する秘密鍵と証明書を持っていないため、それを使用できません。mTLS による送信者制約は通常、X.509 証明書とその秘密鍵を安全に保管および管理できる、サーバーサイドアプリケーションなどの機密クライアントで使用されます。

• アプリケーション層での Demonstrating Proof-of-Possession (DPoP) :

  • メカニズム: DPoP はアプリケーション層で動作し、mTLS を必要としません。代わりに、クライアントアプリケーションは自身のために暗号鍵ペア (秘密鍵/公開鍵) を生成します。
  • バインディング: アクセストークンを要求する際、クライアントアプリケーションは DPoP Proof JWT と呼ばれる JSON Web Token (JWT) を作成します。この Proof JWT にはクライアントの公開鍵が含まれ、クライアントの秘密鍵で署名されます。クライアントアプリケーションは、アクセストークン要求とともに DPoP Proof JWT を送信します。Auth0 認可サーバーは DPoP Proof JWT を検証し、その後、発行したアクセストークンをその公開鍵にバインドします。
  • 所持証明: クライアントアプリケーションが DPoP にバインドされたアクセストークンを使用してリソースサーバーを呼び出す場合、その API リクエスト用に、秘密鍵で署名した別の DPoP Proof JWT を生成します。クライアントアプリケーションは、アクセストークンとあわせてヘッダーで DPoP Proof JWT を送信します。リソースサーバーは、確認 (cnf) クレームを使用して、アクセストークンが DPoP Proof JWT 内の公開鍵にバインドされていること、および DPoP Proof JWT 自体が対応する秘密鍵で署名されていることを検証します。
  • 利点: DPoP は公開鍵基盤を必要としないため、mTLS よりも柔軟です。SPA やモバイルアプリケーションなどのパブリッククライアントを含む、さまざまな種類のクライアントで使用できます。

​

mTLS と DPoP の比較

次の表は、送信者制約トークンにおける mTLS と DPoP の主な違いをまとめたものです。

属性	mTLS	DPoP
動作レイヤー	トランスポート層 (TLS/SSL)	アプリケーション層 (HTTP ヘッダー)
暗号方式	公開鍵基盤 (X.509 証明書) を使用	非対称鍵 (クライアント生成の鍵ペア) を使用
所持証明	TLS ハンドシェイクと証明書の検証	DPoP プルーフ (各リクエストの HTTP ヘッダーに含まれる署名付き JWT)
クライアントタイプ	機密クライアント	パブリッククライアント (SPA、モバイルアプリ)

詳細については、mTLS Sender Constraining と Demonstrating Proof-of-Possession (DPoP) を参照してください。

​

はじめに

Auth0 で 送信者制約 を使い始めるには、次のドキュメントを参照してください。

参照先	学べること
mTLS 送信者制約	Auth0 における mTLS 送信者制約 の仕組みを、順を追って説明します。
Demonstrating Proof-of-Possession (DPoP)	Auth0 における DPoP の仕組みを、順を追って説明します。
Configure 送信者制約	Auth0 でクライアントアプリケーションとリソースサーバーの 送信者制約 を設定する方法。

​

詳細

• mTLS 送信者制約
• Demonstrating Proof-of-Possession (DPoP)
• 送信者制約 を設定する