認証
ユーザー管理
カスタマイズ
プラットフォーム仕組み
-
トランスポート層における Mutual-TLS (mTLS) 証明書バインディング:
- メカニズム: クライアントアプリケーションが Auth0 Authorization Server にアクセストークンをリクエストする際、相互 TLS (mTLS) 接続を確立します。この接続では、クライアントアプリケーションとサーバーの双方が互いの X.509 証明書を提示して検証します。
- バインディング: Auth0 Authorization Server は、発行されたアクセストークンに、クライアントアプリケーションの証明書のサムプリントを含む確認用の (
cnf) クレームを含めます。 - Proof of Possession: クライアントアプリケーションが、バインドされたアクセストークンを使用してリソースサーバーにアクセスする際には、同じ証明書を使って再び mTLS 接続を確立する必要があります。リソースサーバーは、クライアントアプリケーションが提示した証明書が、そのアクセストークンにバインドされている証明書と一致することを検証します。一致しない場合、リソースサーバーはリクエストを拒否します。
- 利点: 攻撃者がアクセストークンを盗んだとしても、それを使用することはできません。正しい mTLS 接続を確立するために必要な、対応する秘密キーと証明書を持っていないためです。mTLS による送信者拘束は通常、X.509 証明書とその秘密キーを安全に保存および管理できる、サーバー側アプリケーションのような機密クライアントで使用されます。
-
アプリケーション層における Demonstrating Proof-of-Possession (DPoP) :
- メカニズム: DPoP はアプリケーション層で動作し、mTLS を必要としません。代わりに、クライアントアプリケーションは自身の暗号鍵ペア (秘密キー / 公開鍵) を生成します。
- バインディング: アクセストークンをリクエストする際、クライアントアプリケーションは DPoP Proof JWT と呼ばれる JSON Web トークン (JWT) を作成します。この DPoP Proof JWT にはクライアントの公開鍵が含まれ、クライアントの秘密キーで署名されます。クライアントアプリケーションは、アクセストークンリクエストとともに DPoP Proof JWT を送信します。Auth0 Authorization Server は DPoP Proof JWT を検証し、その後、発行されたアクセストークンを公開鍵にバインドします。
- Proof of Possession: クライアントアプリケーションが、DPoP にバインドされたアクセストークンを使用してリソースサーバーを呼び出す際、その API リクエスト用に、自身の秘密キーで署名した別の DPoP Proof JWT を生成します。クライアントアプリケーションは、アクセストークンとあわせて DPoP Proof JWT をヘッダーで送信します。リソースサーバーは、アクセストークンが DPoP Proof JWT 内の公開鍵にバインドされていること、および DPoP Proof JWT 自体が対応する秘密キーで署名されていることを、確認用 (
cnf) クレームを使って検証します。 - 利点: DPoP は公開鍵基盤を必要としないため、mTLS より柔軟です。SPA やモバイルアプリケーションのようなパブリッククライアントを含む、さまざまなクライアントタイプで利用できます。
mTLS と DPoP の比較
詳しくは、mTLS 送信者拘束 と Proof-of-Possession (DPoP) のデモ をご覧ください。