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

4. DPoP Proof JWTs (DPoP 証明 JWT)

4. DPoP Proof JWTs (DPoP 証明 JWT)​

DPoP は、DPoP 証明 (DPoP proof) という概念を導入します。これは、クライアントによって作成され、DPoP ヘッダーフィールドを使用して HTTP リクエストと共に送信される JWT です。各 HTTP リクエストには、一意の DPoP 証明が必要です。

有効な DPoP 証明は、DPoP 証明 JWT の署名に使用された秘密鍵をクライアントが保持していることをサーバーに示します。これにより、認可サーバーは発行されたトークンを対応する公開鍵にバインドすることができ（第 5 節で説明）、リソースサーバーは受信したトークンの鍵バインディングを検証できます（第 7.1 節を参照）。これにより、秘密鍵にアクセスできないエンティティによって当該トークンが使用されるのを防ぎます。

DPoP 証明は鍵の所有を実証するものであり、それ自体は認証またはアクセス制御メカニズムではありません。第 7.1 節で説明されているように、鍵にバインドされたアクセストークンと組み合わせて提示された場合、DPoP 証明はアクセストークンを提示するクライアントの正当性に関する追加の保証を提供します。ただし、有効な DPoP 証明 JWT だけでは、アクセス制御の決定を行うには不十分です。

4.1. DPoP HTTP ヘッダー​

DPoP 証明は、以下のリクエストヘッダーフィールドを使用して HTTP リクエストに含まれます。

DPoP: 第 4.2 節の構造と構文に準拠した JWT。

図 2 は、DPoP HTTP ヘッダーフィールドの例を示しています。この例では、[RFC8792] に従って "\" を使用して行を折り返しています。

DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\
 oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\
 WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg\
 4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg

                    図 2: DPoP ヘッダーの例

[RFC9110] によれば、ヘッダーフィールド名は大文字と小文字を区別しないため、DPoP, DPOP, dpop はいずれも有効で同等のヘッダーフィールド名であることに注意してください。ただし、ヘッダーフィールド値の大文字と小文字は区別されます。

DPoP HTTP ヘッダーフィールド値は、[RFC9110] のセクション 11.2 で定義されている token68 構文を使用します。便宜上、図 3 に再掲します。

DPoP       = token68
token68    = 1*( ALPHA / DIGIT /
                 "-" / "." / "_" / "~" / "+" / "/" ) *"="

                   図 3: DPoP ヘッダーフィールド ABNF

4.2. DPoP 証明 JWT 構文​

DPoP 証明は、クライアントが選択した秘密鍵（下記参照）を使用して署名された（JSON Web Signature (JWS) [RFC7515] を使用）JWT [RFC7519] です。DPoP JWT の JOSE ヘッダーには、少なくとも以下のパラメータを含める必要があります。

typ: [RFC8725] のセクション 3.11 で推奨されているように、DPoP 証明 JWT を明示的に型付けする、値 dpop+jwt を持つフィールド。

alg: [IANA.JOSE.ALGS] からの JWS 非対称デジタル署名アルゴリズム識別子。none や対称アルゴリズム（メッセージ認証コード (MAC)）の識別子であってはなりません。

jwk: [RFC7515] のセクション 4.1.3 で定義されているように、JSON Web Key (JWK) [RFC7517] 形式で表された、クライアントによって選択された公開鍵。秘密鍵を含んではなりません。

DPoP 証明のペイロードには、少なくとも以下のクレームを含める必要があります。

jti: DPoP 証明 JWT の一意の識別子。この値は、有効期間内の同じコンテキストで使用される他の DPoP 証明に同じ値が割り当てられる確率が無視できるほど小さくなるように割り当てる必要があります。このような一意性は、少なくとも 96 ビットの疑似乱数データをエンコードする（base64url またはその他の適切なエンコーディング）か、[RFC4122] に準拠したバージョン 4 の汎用一意識別子 (UUID) 文字列を使用することで実現できます。jti は、リプレイの検出と防止のためにサーバーによって使用できます（第 11.1 節を参照）。

htm: JWT が添付されているリクエストの HTTP メソッド（[RFC9110] セクション 9.1）の値。

htu: JWT が添付されているリクエストの HTTP ターゲット URI（[RFC9110] セクション 7.1）。クエリおよびフラグメント部分は含みません。

iat: JWT が作成された時刻のタイムスタンプ（[RFC7519] セクション 4.1.6）。

DPoP 証明が保護されたリソースへのアクセスでアクセストークンと組み合わせて使用される場合（第 7 節を参照）、DPoP 証明には以下のクレームも含める必要があります。

ath: アクセストークンのハッシュ。値は、関連するアクセストークン値の ASCII エンコーディングの SHA-256 [SHS] ハッシュの base64url エンコーディング（[RFC7515] セクション 2 で定義）の結果でなければなりません。

認可サーバーまたはリソースサーバーが DPoP-Nonce HTTP ヘッダーでノンスを提供した場合（第 8 節および第 9 節を参照）、DPoP 証明には以下のクレームも含める必要があります。

nonce: DPoP-Nonce HTTP ヘッダーを介して提供された最新のノンス。

DPoP 証明には、拡張、プロファイル、または特定の展開要件に応じて、他の JOSE ヘッダーパラメータまたはクレームが含まれる場合があります。

図 4 は、図 2 の DPoP 証明のデコードされた内容を示す概念的な例です。JWT ヘッダーとペイロードの JSON は表示されていますが、署名部分は省略されています。通常どおり、書式設定と読みやすさのために、改行と追加のスペースが含まれています。

{
  "typ":"dpop+jwt",
  "alg":"ES256",
  "jwk": {
    "kty":"EC",
    "x":"l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs",
    "y":"9VE4jf_Ok_o64zbTTlcuNJajHmt6v9TDVrU0CdvGRDA",
    "crv":"P-256"
  }
}
.
{
  "jti":"-BwC3ESc6acc2lTc",
  "htm":"POST",
  "htu":"https://server.example.com/token",
  "iat":1562262616
}

            図 4: DPoP 証明の JWT コンテンツの例

HTTP リクエストのうち、HTTP メソッドと URI のみが DPoP JWT に含まれるため、DPoP 証明はこれら 2 つのメッセージ部分のみをカバーします。この考え方は、HTTP リクエストに関して合理的な所有の証明を提供するために、十分な HTTP データのみに署名することです。HTTP ヘッダーデータの最小限のサブセットのみを使用するこの設計アプローチは、HTTP メッセージの正規化を試みることに固有の大きな困難を回避するためです。それにもかかわらず、DPoP 証明は、HTTP リクエストの他の情報を含むように拡張できます（第 11.7 節も参照）。

4.3. DPoP 証明のチェック​

DPoP 証明を検証するには、受信側サーバーは以下を確認する必要があります。

  1. DPoP HTTP リクエストヘッダーフィールドが 1 つだけであること。
  2. DPoP HTTP リクエストヘッダーフィールドの値が、単一の整形式の JWT であること。
  3. 第 4.2 節に記載されているすべての必須クレームが JWT に含まれていること。
  4. typ JOSE ヘッダーパラメータの値が dpop+jwt であること。
  5. alg JOSE ヘッダーパラメータが、登録された非対称デジタル署名アルゴリズム [IANA.JOSE.ALGS] を示しており、none ではなく、アプリケーションでサポートされており、ローカルポリシーに従って許容可能であること。
  6. JWT 署名が、jwk JOSE ヘッダーパラメータに含まれる公開鍵を使用して検証されること。
  7. jwk JOSE ヘッダーパラメータに秘密鍵が含まれていないこと。
  8. htm クレームが現在のリクエストの HTTP メソッドと一致すること。
  9. htu クレームが、JWT を受信した HTTP リクエストの HTTP URI 値（クエリおよびフラグメント部分は無視）と一致すること。
  10. サーバーがクライアントにノンス値を提供した場合、nonce クレームがサーバー提供のノンス値と一致すること。
  11. iat クレームによって、または nonce クレームを介してサーバーによって管理されるタイムスタンプによって決定される JWT 作成時刻が、許容可能なウィンドウ内にあること（第 11.1 節を参照）。
  12. アクセストークンと組み合わせて保護されたリソースに提示される場合、
    • ath クレームの値がそのアクセストークンのハッシュと等しいこと、および
    • アクセストークンがバインドされている公開鍵が DPoP 証明の公開鍵と一致することを確認すること。

誤検知の可能性を減らすために、サーバーは htu クレームを比較する前に、構文ベースの正規化（[RFC3986] セクション 6.2.2）およびスキームベースの正規化（[RFC3986] セクション 6.2.3）を採用すべきです (SHOULD)。

これらのチェックは任意の順序で実行できます。

に最終更新