占有の証明( DPoP )

DPoP クライアントが公開鍵と秘密鍵のペアの所有証明を提供することで、送信者制限付き OAuth トークンを取得する仕組みを提供する。

仕様は草案段階です: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-11

DPoP HTTP

DPoP ヘッダーは、所有権の証明のための鍵情報を含む署名付き JWT です。

DPoP JWT の JOSE ヘッダーには、少なくとも以下のパラメーターが含まれている必要があります。

パラメーター 説明
typ JWT のタイプ。 この値は「dpop + jwt」でなければなりません。
alg 署名アルゴリズム。 有効な値は、 RS256、 RS384、 RS512、 PS256、 PS384、 PS512、 ES256、 ES384、 ES512
JWK 公開鍵を表す JSON Web Key (JWK)。 秘密鍵が含まれていてはなりません。

JOSE ヘッダーの例:

{
  "typ": "dpop+jwt",
  "alg": "RS256",
  "jwk": {
    "kty": "RSA",
    "n": "...",
    "e": "AQAB"
  }
}

DPoP JWT のペイロードには、少なくとも以下のクレームが含まれている必要があります。

クレーム名 説明
jti この JWT の固有 ID。
HTM JWTが添付されたリクエストHTTP。
HTS HTTP (クエリーおよびフラグメント部分を除く)。 これは、プッシュされた許可要求 (PAR) エンドポイントまたはトークン・エンドポイントになります。
iat JWT の作成タイム・スタンプ。

JWT ペイロードの例:

{
  "jti": "3765f59c-43cd-4cf8-8180-73bc9ae4ff3c",
  "htm": "POST",
  "htu": "https://<tenant-hostname>/oauth2/token",
  "iat": 1661847227
}

DPoP JWT は秘密鍵で署名されている必要があり、署名は JWT の JOSE ヘッダーで提供される公開鍵で検証可能でなければなりません。 JWT は、30 分を超えて有効にすることはできません。 exp クレームがない場合、この JWT の有効期限は、 iatで指定された作成タイム・スタンプの 30 分後と想定されます。

JWT は、 DPoPという名前のヘッダーで送信されます。

要求の例:


curl -ki https://<tenantId>/oauth2/token
 -H "DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6Il..."
 -d "grant_type=client_credentials&client_secret=<secret>&client_id=<clientId>"

要求の許可

許可要求の照会パラメーターまたは POST 本体に、JSON Web Key のサムプリントが含まれています。

パラメーター 説明
dpop_ジャケット この許可要求に関連付けられる JSON Web Key のサムプリント。
https://<tenantId>/oauth2/authorize?grant_type=authorization_code&client_id=<clientId>&redirect_uri=<redirect_uri>&dpop_jkt=<dpop_jkt>&...

この要求に対して生成された許可コードは、そのサムプリントにバインドされ、トークン要求での検証に使用されます。 これにより、トークンのコードを交換するときに、トークン要求に署名するための同じ秘密鍵を持たない別のものによって許可コードが盗まれて使用されることを防止できます。

安全な dpop_jkt 方法で拇印を送信するには、 プッシュ認証リクエストDPoP, (PAR)またはリクエストオブジェクトを組み合わせて使用することを推奨します。 また、PAR では、 dpop_jktの代わりに DPoP ヘッダーを使用することもできます。 詳しくは、上記の DPoP HTTP header セクションを参照してください。 プッシュされた許可要求は、 OpenID Connect アプリケーションの構成時に Require pushed authorization request (PAR) を選択することで適用できます。

トークン要求

アクセストークンおよびリフレッシュトークンのリクエストには DPoP HTTPヘッダーが必要です。 詳しくは、上記の DPoP HTTP header セクションを参照してください。

許可コード・フローの場合、この JWK のサムプリントは、許可要求中に送信された JWK サムプリント (dpop_jkt) と一致している必要があります。

要求の例:


curl -ki https://<tenantId>/oauth2/token
 -H "DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6Il..."
 -d "grant_type=client_credentials&client_secret=<secret>&client_id=<clientId>"

このフローを実行した結果、所有の証明にバインドされたトークンのセットが作成されます。 これは、トークン・イントロスペクションを使用して検証できます。

トークン・イントロスペクション

DPoP アクセス・トークンがイントロスペクトされると、追加のクレームが返されます。
  • token_type: bearerの代わりに、この値は DPoPになります。
  • cnf: JWK サムプリント確認クレームは、公開鍵のハッシュを返します。
トークンをイントロスペクトするクライアントは、公開鍵のハッシュをイントロスペクション応答の cnf jkt クレームと比較することにより、アクセス・トークンの DPoP バインディングを検証する必要があります。

イントロスペクション応答の例:


{
    ...,
    "cnf": {
        "jkt": "yrFAH18WFPml9e9IIo6rB_fLdFX1pdbMgIcd_fW_4aM="
    },
    "token_type": "DPoP",
    ...
}