占有の証明( 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>"
このフローを実行した結果、所有の証明にバインドされたトークンのセットが作成されます。 これは、トークン・イントロスペクションを使用して検証できます。
トークン・イントロスペクション
- token_type: bearerの代わりに、この値は DPoPになります。
- cnf: JWK サムプリント確認クレームは、公開鍵のハッシュを返します。
イントロスペクション応答の例:
{
...,
"cnf": {
"jkt": "yrFAH18WFPml9e9IIo6rB_fLdFX1pdbMgIcd_fW_4aM="
},
"token_type": "DPoP",
...
}