メインコンテンツまでスキップ

6. Public Key Confirmation (公開鍵の確認)

6. Public Key Confirmation (公開鍵の確認)​

リソースサーバーは、アクセストークンが DPoP バインドトークンであるかどうかを確実に識別し、DPoP 証明（第 7.1 節を参照）とのバインディングを検証するのに十分な情報を決定できなければなりません。このバインディングは、保護されたリソースが公開鍵にアクセスできるように公開鍵をトークンに関連付けることによって行われます。たとえば、第 6.1 節で説明する構文を使用して発行されたアクセストークンに JWK ハッシュを直接埋め込むか、第 6.2 節で説明するトークンイントロスペクションを使用します。公開鍵をアクセストークンに関連付ける他の方法は、認可サーバーと保護されたリソースの間の合意によって可能です。ただし、それらはこの仕様の範囲外です。

DPoP をサポートするリソースサーバーは、DPoP 証明からの公開鍵がアクセストークンにバインドされている公開鍵と一致することを確認しなければなりません。

6.1. JWK サムプリント確認メソッド​

アクセストークンが JWT [RFC7519] として表現される場合、公開鍵情報はここで定義される jkt 確認メソッドメンバーを使用して表現されます。JWT 内で公開鍵のハッシュを伝達するために、本仕様では cnf クレームの下に以下の JWT 確認メソッド [RFC7800] メンバーを導入します。

jkt: JWK SHA-256 サムプリント確認メソッド。jkt メンバーの値は、アクセストークンがバインドされている DPoP 公開鍵（JWK 形式）の JWK SHA-256 サムプリント（[RFC7638] に準拠）の base64url エンコーディング（[RFC7515] で定義）でなければなりません。

図 8 の JWT の例（デコードされた JWT ペイロードは図 9 に示されています）には、jkt JWK サムプリント確認メソッドメンバーを持つ cnf クレームが含まれています。これらの例の jkt 値は、第 5 節の例に示されている DPoP 証明の公開鍵ハッシュです。この例では、[RFC8792] に従って "\" を使用して行を折り返しています。

eyJhbGciOiJFUzI1NiIsImtpZCI6IkJlQUxrYiJ9.eyJzdWIiOiJzb21lb25lQGV4YW1\
wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJuYmYiOjE\
1NjIyNjI2MTEsImV4cCI6MTU2MjI2NjIxNiwiY25mIjp7ImprdCI6IjBaY09DT1JaTll\
5LURXcHFxMzBqWnlKR0hUTjBkMkhnbEJWM3VpZ3VBNEkifX0.3Tyo8VTcn6u_PboUmAO\
YUY1kfAavomW_YwYMkmRNizLJoQzWy2fCo79Zi5yObpIzjWb5xW4OGld7ESZrh0fsrA

    図 8: JWK SHA-256 サムプリント確認を含む JWT
{
  "sub":"[email protected]",
  "iss":"https://server.example.com",
  "nbf":1562262611,
  "exp":1562266216,
  "cnf":
  {
    "jkt":"0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"
  }
}

 図 9: JWK SHA-256 サムプリント確認を含む JWT クレームセット

6.2. トークンイントロスペクションにおける JWK サムプリント確認メソッド​

「OAuth 2.0 トークンイントロスペクション」[RFC7662] は、保護されたリソースが認可サーバーに対してアクセストークンのアクティブ状態を問い合わせる方法を定義しています。保護されたリソースは、トークンに関するメタ情報も確認できます。

DPoP バインドされたアクセストークンの場合、トークンがバインドされている公開鍵のハッシュは、トークンイントロスペクションレスポンスでメタ情報として保護されたリソースに伝達されます。ハッシュは、JWK サムプリント確認メソッドについて第 6.1 節で説明したのと同じ jkt メンバー構造を含む cnf コンテンツを使用して、イントロスペクションレスポンス JSON のトップレベルメンバーとして伝達されます。リソースサーバーはイントロスペクションリクエストと共に DPoP 証明を送信せず、認可サーバーはイントロスペクションエンドポイントでアクセストークンの DPoP バインデイングを検証しないことに注意してください。むしろ、リソースサーバーはイントロスペクションレスポンスからのデータを使用して、アクセストークンのバインディングをローカルで独自に検証します。

イントロスペクションレスポンスに token_type メンバーが含まれている場合、その値は DPoP でなければなりません。

図 10 のイントロスペクションリクエストの例と図 11 の対応するレスポンスは、図 6 で発行された DPoP バインドアクセストークンの例に関するイントロスペクション交換を示しています。

POST /as/introspect.oauth2 HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic cnM6cnM6TWt1LTZnX2xDektJZHo0ZnNON2tZY3lhK1Rp

token=Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU

               図 10: イントロスペクションリクエストの例
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "active": true,
  "sub": "[email protected]",
  "iss": "https://server.example.com",
  "nbf": 1562262611,
  "exp": 1562266216,
  "cnf":
  {
    "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"
  }
}

      図 11: DPoP バインドアクセストークンのイントロスペクションレスポンスの例
に最終更新