1.1. 表記規則および 用語

この文書におけるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は、 ここに示すようにすべて大文字で出現する場合に限り、 BCP 14 [RFC2119] [RFC8174] に記載されているとおりに解釈される。¶

この仕様では、[RFC5234] の Augmented Backus-Naur Form (ABNF) 記法を使用する。¶

この仕様では、"The OAuth 2.0 Authorization Framework" [RFC6749] によって定義される "access token", "refresh token", "authorization server", "resource server", "authorization endpoint", "authorization request", "authorization response", "token endpoint", "grant type", "access token request", "access token response", "client", "public client", および "confidential client" という用語を使用する。¶

"request", "response", "header field", および "target URI" という用語は、[RFC9110] から取り込まれている。¶

"JOSE" および "JOSE Header" という用語は、[RFC7515] から取り込まれている。¶

この文書には、部分的および完全な HTTP メッセージの非規範的な例が含まれる。 一部の例では、長い値の行折り返しを示すために、 [RFC8792] に従って単一の末尾バックスラッシュを使用する。 折り返された行の文字および先頭のスペースは、値の一部ではない。¶

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

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

DPoP HTTP ヘッダーフィールド値は、 第11.2節 of [RFC9110] で定義される token68 構文を 使用し、参照しやすいように図 3に再掲する。¶

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

4.2. DPoP 証明 JWT の構文

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

typ:

第 3.11節 of [RFC8725] で推奨されているように、 DPoP 証明 JWT を明示的に型付けする値 dpop+jwt を持つフィールド。¶

alg:

[IANA.JOSE.ALGS] にある JWS 非対称デジタル 署名アルゴリズムの識別子。 none または対称アルゴリズム （Message Authentication Code (MAC)）の識別子であっては MUST NOT ならない。¶

jwk:

第4.1.3節 of [RFC7515] で定義されるように、JSON Web Key (JWK) [RFC7517] 形式で、クライアントが選択した公開鍵を表す。 秘密鍵を含めては MUST NOT ならない。¶

DPoP 証明のペイロードは、少なくとも以下のクレームを含め MUST。¶

jti:

DPoP 証明 JWT の一意な識別子。 同じ有効期間ウィンドウ内で同じコンテキストにおいて使用される 他の DPoP 証明に同じ値が割り当てられる確率が無視できる程度になるように、 値を割り当て MUST。 そのような一意性は、少なくとも 96 ビットの疑似ランダムデータを （base64url またはその他の適切なエンコーディングで）エンコードすること、 または [RFC4122] に従った バージョン 4 Universally Unique Identifier (UUID) 文字列を使用することで達成できる。 jti は、サーバーによるリプレイ検出および防止に使用できる。 第 11.1節を参照。¶

htm:

JWT が添付される要求の HTTP メソッド（第9.1節 of [RFC9110]）の値。¶

htu:

JWT が添付される要求の HTTP ターゲット URI（第7.1節 of [RFC9110]）。 ただし、query 部分および fragment 部分を含まない。¶

iat:

JWT の作成タイムスタンプ （第 4.1.6節 of [RFC7519]）。¶

DPoP 証明が、保護リソースアクセスにおけるアクセストークンの 提示と併用される場合（第7節を参照）、 DPoP 証明は以下のクレームも含め MUST。¶

ath:

アクセストークンのハッシュ。 値は、関連付けられたアクセストークン値の ASCII エンコーディングの SHA-256 [SHS] ハッシュを （第2節 of [RFC7515] で定義される） base64url エンコードした結果で MUST ある。¶

認証サーバーまたはリソースサーバーが応答内で DPoP-Nonce HTTP ヘッダーを 提供する場合（第8節および第9節を参照）、DPoP 証明は 以下のクレームも含め MUST。¶

nonce:

DPoP-Nonce HTTP ヘッダーを通じて提供された最近の nonce。¶

DPoP 証明は、拡張、プロファイル、またはデプロイメント固有の 要件によって定義される他の JOSE Header パラメーターまたはクレームを含んでも MAY よい。¶

図 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
}

HTTP 要求のうち、HTTP メソッドと URI のみが DPoP JWT に含まれる。したがって、この 2 つのメッセージ部分のみが DPoP 証明によってカバーされる。 この考え方は、HTTP 要求に関する所有証明として妥当なものを提供するために 必要十分な HTTP データだけに署名することである。 HTTP ヘッダーデータの最小限のサブセットのみを使用するこの設計方針は、 HTTP メッセージの正規化を試みることに本質的に伴う大きな困難を 回避するためである。 それにもかかわらず、DPoP 証明は HTTP 要求の他の情報を含むように 拡張できる（第 11.7節も参照）。¶

4.3. DPoP 証明の検査

DPoP 証明を検証するために、受信サーバーは以下を確実にし MUST。¶

1. DPoP HTTP 要求ヘッダーフィールドが 2 つ以上存在しないこと。¶
2. DPoP HTTP 要求ヘッダーフィールド値が、単一で整形式の JWT であること。¶
3. 第4.2節に従うすべての必須クレームが JWT に含まれていること。¶
4. typ JOSE Header Parameter が値 dpop+jwt を持つこと。¶
5. alg JOSE Header Parameter が、登録済みの 非対称デジタル署名アルゴリズム [IANA.JOSE.ALGS] を示し、none ではなく、 アプリケーションによってサポートされ、ローカルポリシーに従って受け入れ可能であること。¶
6. JWT 署名が、 jwk JOSE Header Parameter に含まれる公開鍵で検証されること。¶
7. jwk JOSE Header Parameter が秘密鍵を 含まないこと。¶
8. htm クレームが現在の要求の HTTP メソッドと 一致すること。¶
9. htu クレームが、query 部分および fragment 部分を無視して、JWT が受信された HTTP 要求の HTTP URI 値と 一致すること。¶
10. サーバーがクライアントに nonce 値を提供した場合、 nonce クレームがサーバー提供の nonce 値と一致すること。¶
11. JWT の作成時刻が、iat クレームまたは nonce クレームを通じたサーバー管理タイムスタンプのいずれかによって 判断され、許容可能なウィンドウ内にあること（第 11.1節を参照）。¶

12. アクセストークンとともに保護リソースに提示される場合、¶

    • ath クレームの値がそのアクセストークンのハッシュと等しいことを確認し、かつ¶
    • アクセストークンがバインドされている公開鍵が DPoP 証明の公開鍵と一致することを確認する。¶

偽陰性の可能性を低減するため、サーバーは htu クレームを比較する前に、構文ベースの正規化 （第6.2.2節 of [RFC3986]）およびスキームベースの 正規化（第6.2.3節 of [RFC3986]）を採用 SHOULD する。¶

これらの検査は任意の順序で実行してよい。¶

5.1. 認可サーバー メタデータ

この文書は、DPoP の一般的なサポートと、認可サーバーが DPoP 証明 JWT 用に サポートする具体的な JWS alg 値を通知するため、以下の認可サーバー メタデータ [RFC8414] パラメーターを導入する。¶

dpop_signing_alg_values_supported:

認可サーバーが DPoP 証明 JWT 用に サポートする JWS alg 値（[IANA.JOSE.ALGS] レジストリ由来）のリストを含む JSON 配列。¶

5.2. クライアント登録 メタデータ

Dynamic Client Registration Protocol [RFC7591] は、OAuth 2.0 クライアントメタデータを 認可サーバーに動的に登録するための API を定義する。 [RFC7591] によって定義されるメタデータ、 およびそれに登録された拡張は、Dynamic Client Registration Protocol が使用されていない場合でも、 認可サーバー実装に有用なクライアントの一般的なデータモデルも含意する。 そのような実装では、通常、クライアント構成を管理するための何らかのユーザーインターフェイスが 利用可能である。¶

この文書は、クライアントが認可サーバーからトークンを要求する際に 常に DPoP を使用することを示すため、以下のクライアント登録メタデータ [RFC7591] パラメーターを導入する。¶

dpop_bound_access_tokens:

クライアントがトークン要求に常に DPoP を使用するかどうかを指定するブール値。省略された場合、既定値は false である。¶

値が true の場合、認可サーバーは、 DPoP ヘッダーを含まないそのクライアントからのトークン要求を拒否し MUST。¶

6.1. JWK サムプリント 確認方法

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

jkt:

JWK SHA-256 Thumbprint 確認方法。 jkt メンバーの値は、アクセストークンがバインドされる DPoP 公開鍵（JWK 形式）の JWK SHA-256 Thumbprint （[RFC7638] に従う）を base64url エンコード（[RFC7515] で定義）したもので MUST ある。¶

図 8の以下の例の JWT は、 図 9に示すデコード済み JWT ペイロードを伴い、 jkt JWK Thumbprint 確認方法メンバーを持つ cnf クレームを含む。 これらの例における jkt 値は、第5節の例で示された DPoP 証明の公開鍵のハッシュである。 この例では、[RFC8792] に従って "\" による行折り返しを使用している。¶

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

{
  "sub":"someone@example.com",
  "iss":"https://server.example.com",
  "nbf":1562262611,
  "exp":1562266216,
  "cnf":
  {
    "jkt":"0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"
  }
}

6.2. トークンイントロスペクションにおける JWK サムプリント確認方法

"OAuth 2.0 Token Introspection" [RFC7662] は、 保護リソースがアクセストークンのアクティブ状態について認可サーバーに問い合わせるための方法を定義する。 保護リソースは、トークンに関するメタ情報も判断する。¶

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

token_type メンバーがイントロスペクション応答に含まれる場合、 それは値 DPoP を含め MUST。¶

図 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

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

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

7.1. DPoP 認証スキーム

DPoP バインドアクセストークンは、 第11.6.2節 of [RFC9110] に従い、DPoP の認証スキームを用いて Authorization 要求ヘッダーフィールドで送信される。 DPoP スキームの Authorization ヘッダーフィールドの構文は、資格情報について 第11.2節 of [RFC9110] で定義される token68 構文を使用し、 参照しやすいように以下に再掲する。 DPoP 認証スキーム資格情報の ABNF 記法構文は次のとおりである。¶

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

credentials = "DPoP" 1*SP token68

そのようなアクセストークンについて、リソースサーバーは、 HTTP 要求の DPoP ヘッダーフィールド内で DPoP 証明も受信されていることを検査し、 第4.3節の規則に従って DPoP 証明を検査し、 かつ 第6節に従って、DPoP 証明の公開鍵がアクセストークンの バインド先である公開鍵と一致することを検査し MUST。¶

リソースサーバーは、すべての検査が成功しない限り、リソースへのアクセスを許可しては MUST NOT ならない。¶

図 13は、 Authorization ヘッダー内に DPoP バインドアクセストークンを含み、 DPoP ヘッダー内に DPoP 証明を含む保護リソースへの要求例を示す。 この例では、[RFC8792] に従って "\" による行折り返しを使用している。 図 14は、その DPoP 証明のデコード済み内容を示す。JWT ヘッダーとペイロードの JSON が示されているが、 署名部分は省略されている。通常どおり、改行とインデントは書式設定と読みやすさのために 含まれている。¶

GET /protectedresource HTTP/1.1
Host: resource.example.org
Authorization: DPoP Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiJlMWozVl9iS2ljOC1MQUVCIiwiaHRtIj\
 oiR0VUIiwiaHR1IjoiaHR0cHM6Ly9yZXNvdXJjZS5leGFtcGxlLm9yZy9wcm90ZWN0Z\
 WRyZXNvdXJjZSIsImlhdCI6MTU2MjI2MjYxOCwiYXRoIjoiZlVIeU8ycjJaM0RaNTNF\
 c05yV0JiMHhXWG9hTnk1OUlpS0NBcWtzbVFFbyJ9.2oW9RP35yRqzhrtNP86L-Ey71E\
 OptxRimPPToA1plemAgR6pxHF8y6-yqyVnmcw6Fy1dqd-jfxSYoMxhAJpLjA

{
  "typ":"dpop+jwt",
  "alg":"ES256",
  "jwk": {
    "kty":"EC",
    "x":"l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs",
    "y":"9VE4jf_Ok_o64zbTTlcuNJajHmt6v9TDVrU0CdvGRDA",
    "crv":"P-256"
  }
}
.
{
  "jti":"e1j3V_bKic8-LAEB",
  "htm":"GET",
  "htu":"https://resource.example.org/protectedresource",
  "iat":1562262618,
  "ath":"fUHyO2r2Z3DZ53EsNrWBb0xWXoaNy59IiKCAqksmQEo"
}

DPoP 認証を必要とする保護空間内の保護リソースへの要求を受信した際、 要求が有効な資格情報を含まない場合、またはアクセスに十分なアクセストークンを含まない場合、 サーバーは DPoP 認証情報を提供するようクライアントにチャレンジで応答できる。 そのようなチャレンジは、401 (Unauthorized) 応答ステータスコード （[RFC9110], 第 15.5.2節）および WWW-Authenticate ヘッダーフィールド （[RFC9110], 第 11.6.1節）を使用して行われる。 サーバーは、他の条件への応答として WWW-Authenticate ヘッダーを含めても MAY よい。¶

そのようなチャレンジでは、次のとおりである。¶

• スキーム名は DPoP である。¶
• 認証パラメーター realm は、 [RFC9110], 第 11.5節 で説明される方法で保護範囲を示すために含めても MAY よい。¶
• scope 認証パラメーターは、 [RFC6750], 第 3節 で定義されるように含めても MAY よい。¶
• error パラメーター （[RFC6750], 第 3節）は、要求にアクセストークンが含まれていたが認証に失敗した場合に、 要求が拒否された理由を示すために含める SHOULD。 [RFC6750], 第 3.1節 で説明されるエラーパラメーター値は適しており、 拡張によって定義される適切な値も同様である。 値 use_dpop_nonce は、後続の要求の DPoP 証明で nonce が必要であることを 通知するために、第9節で説明するように 使用できる。さらに、invalid_dpop_proof は、 第4.3節の基準に基づいて DPoP 証明自体が無効と判断されたことを示すために使用される。¶
• error_description パラメーター （[RFC6750], 第 3節）は、エンドユーザーに表示することを意図しない、人間が読める開発者向けの説明を 提供するために、error パラメーターとともに含めても MAY よい。¶
• algs パラメーターは、 DPoP 証明 JWT に対して受け入れ可能な JWS アルゴリズムをクライアントに通知するために 含める SHOULD。 パラメーターの値は、空白で区切られた JWS alg (Algorithm) ヘッダー値のリストである（[RFC7515], 第 4.1.1節）。¶
• 追加の認証パラメーターを使用しても MAY よく、未知のパラメーターは受信者によって無視され MUST。¶

図 15は、認証なしの保護リソース要求に対する応答を示す。¶

 HTTP/1.1 401 Unauthorized
 WWW-Authenticate: DPoP algs="ES256 PS256"

図 16は、アクセストークン内の DPoP バインディングの確認に失敗したために 拒否された保護リソース要求に対する応答を示す。図 16では、[RFC8792] に従って "\" による行折り返しを使用している。¶

HTTP/1.1 401 Unauthorized
WWW-Authenticate: DPoP error="invalid_token", \
   error_description="Invalid DPoP key binding", algs="ES256"

Cross-Origin Resource Sharing (CORS) [WHATWG.Fetch] を使用する ブラウザーベースのクライアントアプリケーションは、既定では CORS セーフリストに含まれる 応答 HTTP ヘッダーにのみアクセスできることに注意。 アプリケーションが WWW-Authenticate HTTP 応答ヘッダー値を取得して使用できるようにするには、 サーバーは Access-Control-Expose-Headers 応答ヘッダーリスト値に WWW-Authenticate を含めることによって、それをアプリケーションに利用可能にする必要がある。¶

この認証スキームは、オリジンサーバー認証専用である。 したがって、この認証スキームは Proxy-Authenticate または Proxy-Authorization ヘッダーフィールドとともに使用しては MUST NOT ならない。¶

この認証スキームの Authorization ヘッダーフィールドの構文は、 第2.1節 of [RFC6750] で定義される Bearer スキームの使用方法に従うことに注意。 これは [RFC9110] の推奨される資格情報構文ではないが、 そこにある一般的な認証フレームワークと互換であり、Bearer スキームとの 一貫性と親しみやすさのために使用される。¶

7.2. Bearer 認証スキームとの互換性

DPoP スキームと Bearer スキームの両方を同時にサポートする保護リソースは、DPoP バインドされたアクセストークンの ダウングレードされた使用を防ぐため、Bearer トークンに対する評価プロセスの実行方法を更新する必要がある。 具体的には、そのような保護リソースは、[RFC6750] に従って Bearer トークンとして受信した DPoP バインドアクセストークンを拒否し MUST。¶

第11.6.1節 of [RFC9110] は、保護リソースが 401 (Unauthorized) 応答の WWW-Authenticate ヘッダーフィールドで複数の認証スキーム （すなわち Bearer および DPoP）のサポートを示すことを許可している。¶

[RFC6750] のみをサポートし、DPoP を認識しない保護リソースは、 おそらく DPoP バインドアクセストークンを Bearer トークンとして受け入れるだろう （JWT [RFC7519] は認識できないクレームを 無視するよう述べており、Introspection [RFC7662] は、他のパラメーターが存在し得る一方で、その存在に関する機能要件を置いておらず、 [RFC6750] は、有効性に関係するためアクセストークンの内容について 実質的に何も述べていない）。 そのため、クライアントは、保護リソースから WWW-Authenticate: Bearer チャレンジを受け取った際に、DPoP バインド アクセストークンを Bearer スキームを使用して送信できる （または、保護リソースの機能を事前に知っている場合に DPoP バインドアクセストークンを送信できる）。 この効果により、保護リソースでの DPoP サポートへの段階的アップグレード、 または混在したトークン種別サポートを持つ保護リソースの長期デプロイメントの 運用が簡素化される可能性が高い。¶

Bearer および DPoP スキームの両方をサポートする保護リソースが、複数の WWW-Authenticate チャレンジで応答することを選択する場合、 どのチャレンジが実際のエラー情報を伝えるべきかに注意を払うべきである。 次の規則に従うことが RECOMMENDED される。¶

• 要求に認証情報が含まれていない場合、 チャレンジは、第 3.1節 of [RFC6750] に従い、 エラーコードまたはその他のエラー情報を含める SHOULD NOT （図 17）。¶

• 認証を試みるために使用されたメカニズムを 明確に確定できる場合、対応するチャレンジを使用してエラー情報を伝える SHOULD （図 18）。¶

• それ以外の場合、Bearer と DPoP の両方のチャレンジを使用してエラー情報を伝えても MAY よい（図 19）。¶

以下の例では、[RFC8792] に従って "\" による行折り返しを使用している。¶

GET /protectedresource HTTP/1.1
Host: resource.example.org

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer, DPoP algs="ES256 PS256"

GET /protectedresource HTTP/1.1
Host: resource.example.org
Authorization: Bearer INVALID_TOKEN

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_token", \
    error_description="Invalid token", DPoP algs="ES256 PS256"

GET /protectedresource HTTP/1.1
Host: resource.example.org
Authorization: Bearer Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU
Authorization: DPoP Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU

HTTP/1.1 400 Bad Request
WWW-Authenticate: Bearer error="invalid_request", \
 error_description="Multiple methods used to include access token", \
 DPoP algs="ES256 PS256", error="invalid_request", \
 error_description="Multiple methods used to include access token"

7.3. クライアントに関する考慮事項

DPoP 証明を含む認可は、サーバーによる jti、iat、および nonce クレームの適用方法によっては 冪等ではない場合がある。その結果、以前は冪等であった保護リソースへのすべての要求は、 もはや冪等ではなくなる可能性がある。 一般に一時的と理解される HTTP エラーへの応答として冪等な要求を再試行する場合でも、 クライアントが一意な DPoP 証明を生成することが RECOMMENDED される。¶

頻繁なネットワークエラーに遭遇するクライアントは、 より厳格な nonce 検証実装を持つサーバーとやり取りする際に、追加の課題に直面する可能性がある。¶

8.1. Nonce の構文

[RFC6749] で使用される ABNF における nonce 構文 （scope-token 構文と同じ）を以下に示す。¶

nonce = 1*NQCHAR

8.2. 新しい Nonce 値の提供

クライアントが使用する新しい nonce 値をいつ提供するかは、 認可サーバーに委ねられる。 クライアントは、認可サーバーが新しい nonce 値を提供するまで、 既存の提供済み nonce を DPoP 証明で使用することが期待される。¶

認可サーバーは、最初の nonce が提供されたのと同じ方法、 すなわち応答内の DPoP-Nonce HTTP ヘッダーを使用して、 新しい nonce を提供しても MAY よい。 DPoP-Nonce HTTP ヘッダーフィールドは、第8.1節で定義される nonce 構文を使用する。 これが発生するたびに、追加のプロトコル往復が必要になる。¶

新しい nonce 値を提供する、より効率的な方法も定義されている。 それは、前回の要求に対する HTTP 200 (OK) 応答に DPoP-Nonce HTTP ヘッダーを含めることである。 クライアントは、認可サーバーが新しい nonce を提供するまで、 次のトークン要求およびすべての後続のトークン要求で、提供された新しい nonce 値を使用し MUST。¶

DPoP-Nonce HTTP ヘッダーを含む応答は、 後続の要求を処理するために応答が使用され、その結果として古い nonce 値が 使用されることを防ぐため、キャッシュ不可にすべきである （たとえば、GET 要求への応答で Cache-Control: no-store を使用する）。¶

新しい nonce 値を提供する 200 OK 応答の例を以下に示す。¶

 HTTP/1.1 200 OK
 Cache-Control: no-store
 DPoP-Nonce: eyJ7S_zG.eyJbYu3.xQmBj-1

10.1. Pushed Authorization Requests における DPoP

Pushed Authorization Requests (PARs) [RFC9126] が DPoP と併用される場合、PAR 要求で DPoP 鍵を伝達できる方法は 2 つある。¶

• dpop_jkt パラメーターは、 発行される認可コードを特定の鍵にバインドするため、第10節で 説明されるように使用できる。この場合、dpop_jkt は、PAR 要求の POST 本文内で 他の認可要求パラメーターとともに含め MUST。¶
• あるいは、DPoP ヘッダーを PAR 要求に追加できる。この場合、認可サーバーは、第4.3節で 定義されるように、提供された DPoP 証明 JWT を検査し MUST。さらに、含まれる公開鍵のサムプリントが dpop_jkt を使用して提供されたかのように振る舞い、すなわち同じ鍵に対する DPoP 証明が提供されない限り、後続のトークン要求を拒否し MUST。 これは、クライアントが要求の種別に関係なく、認可サーバーへのすべての要求に DPoP ヘッダーを「盲目的に」添付できるため、 クライアントの実装を簡素化するのに役立つ可能性がある。 さらに、DPoP ヘッダーには秘密鍵の所有証明が含まれるため、 より強力なバインディングを提供する。¶

PAR と DPoP をサポートする認可サーバーは、両方のメカニズムを サポートし MUST。両方のメカニズムが同時に使用される場合、 dpop_jkt 内の JWK Thumbprint が DPoP ヘッダー内の公開鍵と 一致しなければ、認可サーバーは要求を拒否し MUST。¶

両方のメカニズムを許可することで、dpop_jkt を使用するクライアントは フロントチャネル認可要求とプッシュ型認可要求を区別する必要がなくなる。 同時に、認可サーバーエンドポイントへのすべての呼び出しを保護するための コードパスが 1 つしかないクライアントは、PAR エンドポイントへの要求と トークンエンドポイントへの要求を区別する必要がなくなる。¶

11.1. DPoP 証明のリプレイ

攻撃者が DPoP 証明 JWT を入手できた場合、 攻撃者は同じエンドポイントでそのトークンをリプレイできる可能性がある （HTTP エンドポイントおよびメソッドは JWT 内のそれぞれのクレームによって強制される）。 これを制限するため、サーバーは DPoP 証明を、その作成後の限られた時間 （望ましくは秒または分の単位の比較的短い期間）に限って受け入れ MUST。¶

ターゲット URI のコンテキストにおいて、サーバーは、 それぞれの DPoP 証明 JWT が受け入れられる時間ウィンドウの間、 各 DPoP 証明の jti 値を保存できる。 これにより、同じ DPoP 証明の複数回使用を防止できる。 以前にその jti 値が確認された同じ URI への HTTP 要求は拒否される。 厳格に適用される場合、そのような単回使用検査は DPoP 証明リプレイに対して 非常に強力な保護を提供するが、実際には常に実現可能とは限らない。 たとえば、単一のエンドポイントの背後にある複数のサーバーが共有状態を持たない場合である。¶

メモリ枯渇攻撃を防ぐため、jti 値を追跡するサーバーは、 不必要に大きい jti 値を持つ DPoP 証明 JWT を拒否するか、 そのハッシュのみを保存すべきである。¶

注: クロックオフセットに対応するため、サーバーは、 iat 時刻が妥当に近い将来（秒または分の単位）である DPoP 証明を 受け入れても MAY よい。 サーバーとクライアント間のクロックスキューは大きくなる可能性があるため、 サーバーは、クライアント提供の iat 時刻をサーバー時刻と比較するのではなく、 サーバー時刻を含むサーバー提供 nonce 値を使用して DPoP 証明の有効期間を制限しても MAY よい。この方法で作成された nonce は、任意に大きなクロックスキューが ある場合でも同じ結果をもたらす。¶

サーバー提供 nonce は、DPoP 証明リプレイが成功する可能性を さらに低減する有効な手段である。 暗号学的 nonce とは異なり、クライアントが同じ nonce を複数回使用し、サーバーが同じ nonce を複数回受け入れることは許容される。 nonce の有効期間中に jti 値が追跡され、重複が拒否される限り、 トークンリプレイの追加リスクはない。¶

11.2. DPoP 証明の 事前生成

クライアントを制御する攻撃者は、DPoP 証明内の iat 値を選択し、 所有証明鍵で署名させることによって、特定のエンドポイント用の DPoP 証明を 任意に遠い将来まで事前生成できる。 そのような攻撃者の 1 人は、クライアントの正当なユーザーである人物であることに注意。 ユーザーは、DPoP 証明を事前生成し、それらが生成された所有証明鍵を持つマシンから 外部に持ち出して、その鍵を持たない別のマシンにコピーする可能性がある。 たとえば、銀行員が銀行のコンピューター上で DPoP 証明を事前生成し、 将来使用するために別のマシンにコピーすることで、銀行の監査管理を回避する可能性がある。 DPoP 証明を事前生成して外部に持ち出せる場合、 DPoP プロトコル相互作用で実際に証明されているのは、 所有証明鍵の所有ではなく、DPoP 証明の所有である。¶

攻撃者が予測できないサーバー提供 nonce 値の使用により、 この攻撃を防止できる。 サーバーは、自ら選択した時点で新しい nonce 値を提供することで、 DPoP 証明の有効期間を制限し、 事前生成された DPoP 証明が使用されることを防止できる。 サーバー提供 nonce が使用される場合、単なる DPoP 証明の所有ではなく、 所有証明鍵の所有が示されていることになる。¶

ath クレームは、事前生成された DPoP 証明の使用を アクセストークンの有効期間に制限する。 nonce メカニズムを利用しないデプロイメントは、長寿命の DPoP 制約付きアクセストークンを 発行すべきでは SHOULD NOT なく、 代わりに短寿命のアクセストークンとリフレッシュトークンを使用することが望ましい。 攻撃者がリフレッシュトークンを使用して新しいアクセストークンを取得するための DPoP 証明を 事前生成できたとしても、新たに発行されたアクセストークンを使用するための DPoP 証明を 現実的に事前生成することはできない。¶

11.3. DPoP Nonce のダウングレード

DPoP nonce がクライアントに提供されている場合、 サーバーは nonce クレームなしの DPoP 証明を受け入れては MUST NOT ならない。¶

11.4. クライアントコンテキスト内の 信頼されないコード

攻撃者がクライアントの実行コンテキスト内でコードを実行できる場合、 DPoP のセキュリティはもはや保証されない。 信頼されないコードの実行につながる Web アプリケーションの一般的な問題は、 XSS およびリモートコード取り込み攻撃である。¶

DPoP に使用される秘密鍵が、ハードウェアまたはソフトウェアの セキュリティモジュールなど、エクスポートできない方法で保存されている場合、 攻撃者は鍵を外部に持ち出し、任意の DPoP 証明を作成するために使用することはできない。 しかし、攻撃者は、クライアントがオンラインである限り新しい DPoP 証明を作成でき、 それらの証明を（それぞれのトークンとともに）被害者のデバイス上、 または攻撃者が制御するデバイス上で使用して、サーバーに受け入れられる任意の要求を 送信できる。¶

クライアントがオフラインのときでも要求を送信するため、 攻撃者は将来のタイムスタンプを使用して DPoP 証明を事前計算し、 これらをアクセストークンまたはリフレッシュトークンとともに外部に持ち出そうとする可能性がある。¶

攻撃者はさらに、トークンエンドポイントから発行されたトークンを、 攻撃者が制御する鍵ペアに関連付けようとする可能性がある。 これを達成する 1 つの方法は、たとえば暗号 API を置き換えることで既存コードを変更することである。 もう 1 つの方法は、iframe 内でクライアントと認可サーバーの間の新しい認可グラントを 開始することである。このグラントは「サイレント」である必要があり、すなわちユーザーとの 相互作用を要求しない必要がある。クライアントのオリジンで実行されるコードにより、 攻撃者は結果として得られる認可コードにアクセスでき、それを使用して、 自分の DPoP 鍵をトークンエンドポイントから返されるトークンに関連付けることができる。 その後、攻撃者は、クライアントがオフラインであっても、自分のデバイスで結果のトークンを 使用できる。¶

したがって、DPoP が使用される場合でも、信頼されないコードの実行から クライアントを保護することは極めて重要である。 安全なコーディングプラクティスに加えて、Content Security Policy [W3C.CSP] は XSS に対する第2の防御層として使用できる。¶

11.5. 署名付き JWT の入れ替え

署名付き DPoP 証明 JWT を受け入れるサーバーは、 攻撃者が他の目的のために作成された JWT を使用できないようにするため、 JWT のヘッダー内の typ フィールドが dpop+jwt であることを検証し MUST。¶

11.6. 署名アルゴリズム

実装者は、DPoP 証明の署名に使用できるのが、 安全と見なされる非対称デジタル署名アルゴリズム（ES256 など）のみであることを 保証し MUST。特に、 アルゴリズム none は許可しては MUST NOT ならない。¶

11.7. 要求の完全性

DPoP は、要求のペイロードまたはヘッダーの完全性を保証しない。 DPoP 証明には HTTP URI とメソッドのクレームのみが含まれ、 たとえばメッセージ本文や一般的な要求ヘッダーは含まれない。¶

これは DPoP を使いやすく保つことを意図した設計上の判断であるが、 説明したように、攻撃者がメッセージ内容やヘッダーを変更できる場合、 DPoP はリプレイ攻撃を受けやすくなる可能性がある。 多くの構成では、TLS によって提供されるメッセージ完全性と機密性で、 十分な保護レベルを提供できる。¶

注: 要求の他の部分をカバーする署名はこの仕様の範囲外であるが、 署名される追加情報を DPoP 証明に追加できる。¶

11.8. アクセストークンと 公開鍵のバインディング

第6節で規定される、 アクセストークンの DPoP 公開鍵へのバインディングは、 公開鍵の JWK 表現の暗号学的ハッシュを使用する。 これは、同じハッシュ出力値を生成する別の鍵を見つけたり作成したりすることを 計算上不可能にするのに十分な第二原像耐性をハッシュ関数が持つことに依存する。 SHA-256 ハッシュ関数は、上述の要件を満たしつつ広く利用可能であるため使用された。¶

同様に、DPoP 証明のアクセストークンへのバインディングは、 DPoP 証明内の ath クレームの値として、そのアクセストークンのハッシュを使用する （第4.2節を参照）。 これは、アクセストークンを確実に識別するのに十分に一意であるハッシュ値に依存する。 SHA-256 の衝突耐性はその要件を満たす。¶

11.9. 認可コードと 公開鍵のバインディング

認可コードの DPoP 公開鍵への暗号学的バインディングは、 第10節で規定される。 このバインディングは、攻撃者が認可コードを取得し、クライアントが保持するものとは異なる 所有証明鍵を使用して DPoP 証明を作成し、その DPoP 証明を使用して認可コードを 引き換える攻撃を防ぐ。クライアントの DPoP 鍵のみが使用できることをエンドツーエンドで 保証することにより、取得された認可コードが外部に持ち出され、 認可コードが発行された場所とは異なる場所で使用されることを防ぐ。¶

認可コードは、たとえば、それらを含む HTTP メッセージがログに記録される場所から 攻撃者によって収集される可能性がある。 認可コードを単回使用にする努力がなされている場合でも、実際には攻撃者がそれらを リプレイできる時間ウィンドウが存在することが多い。 たとえば、認可サーバーがスケーラブルな複製サービスとして実装されている場合、 一部のレプリカはリプレイを防止するために必要な情報を一時的にまだ持っていない可能性がある。 認可コードの DPoP バインディングは、これらの問題を解決する。¶

認可サーバーが認可コードの単回使用制限を厳格に強制しない（またはできない）場合、 かつ攻撃者が認可コード（PKCE が使用される場合は code_verifier）にアクセスできる場合、 攻撃者は偽造トークン要求を作成し、結果として得られるトークンを攻撃者が制御する鍵に バインドできる。 たとえば、XSS を使用して、攻撃者は認可コードおよび PKCE パラメーターにアクセスする可能性がある。 dpop_jkt パラメーターの使用はこの攻撃を防ぐ。¶

認可コードの DPoP 公開鍵へのバインディングは、 アクセストークンのバインディングと同様に、公開鍵の JWK Thumbprint を使用する。 同じ JWK Thumbprint に関する考慮事項が適用される。¶

11.10. ハッシュアルゴリズムの俊敏性

ここで定義される jkt 確認方法メンバー、 ath JWT クレーム、および dpop_jkt 認可要求パラメーターはすべて、 SHA-256 ハッシュ関数の出力を値として使用する。 この仕様で単一のハッシュ関数を使用することは意図的なものであり、 パラメーター化されたアルゴリズム俊敏性スキームの実装およびデプロイにおける 一般的な誤りから生じる可能性のあるセキュリティおよび相互運用性の問題を避け、 単純さを目指したものである。 しかし、将来の状況が変化し、SHA-256 がこの仕様の要件に不十分となる場合、 異なるハッシュ関数の使用は排除されない。 その必要が生じた場合、この仕様を更新する短い仕様が作成されることが期待される。 適切なハッシュ関数の出力を値として使用し、その仕様はおそらく新しい確認方法メンバー、 新しい JWT クレーム、および新しい認可要求パラメーターを定義するだろう。 これらの項目は、この仕様によって定義されるより大きなプロトコルの同じメッセージ構造と フローにおいて、それぞれ対応する既存項目の代わりに、または並行して使用される。¶

11.11. クライアント識別子への バインディング

DPoP がクライアント認証とともに使用される場合、 それは同じ TLS トンネル内で同時に存在することによってのみ認証にバインドされる。 DPoP 証明は暗号学的に認証へ直接バインドされていないため、 認証または DPoP メッセージがトンネル内にコピーされた可能性がある。 DPoP に URI を含めることでこのリスクの一部を部分的に緩和できるが、 認証メカニズムを変更して認証と DPoP の間に暗号学的バインディングを提供することで、 より良い保護が提供される可能性がある。 しかし、認証メカニズムの変更またはその他の手段によって認証との追加バインディングを 提供することは、この仕様の範囲外である。¶

12.1. OAuth アクセストークン 種別の登録

IANA は、[RFC6749] によって 確立された "OAuth Access Token Types" レジストリ [IANA.OAuth.Params] に、以下のアクセストークン種別を 登録した。¶

名前:

DPoP¶

追加のトークンエンドポイント応答パラメーター:

（なし）¶

HTTP 認証スキーム:

DPoP¶

変更管理者:

IETF¶

参照:

RFC 9449¶

12.2. OAuth 拡張エラー 登録

IANA は、[RFC6749] によって 確立された "OAuth Extensions Error" レジストリ [IANA.OAuth.Params] に、以下のエラー値を 登録した。¶

無効な DPoP 証明:

名前:

invalid_dpop_proof¶

使用場所:

トークンエラー応答、リソース アクセスエラー応答¶

プロトコル拡張:

Demonstrating Proof of Possession (DPoP)¶

変更管理者:

IETF¶

参照:

RFC 9449¶

DPoP nonce の使用:

名前:

use_dpop_nonce¶

使用場所:

トークンエラー応答、リソース アクセスエラー応答¶

プロトコル拡張:

Demonstrating Proof of Possession (DPoP)¶

変更管理者:

IETF¶

参照:

RFC 9449¶

12.3. OAuth パラメーター 登録

IANA は、[RFC6749] によって 確立された "OAuth Parameters" レジストリ [IANA.OAuth.Params] に、以下の認可要求パラメーターを 登録した。¶

名前:

dpop_jkt¶

パラメーター使用場所:

認可要求¶

変更管理者:

IETF¶

参照:

RFC 9449 の第10節¶

12.4. HTTP 認証 スキーム登録

IANA は、[RFC9110], 第 16.4.1節 によって確立された "HTTP Authentication Schemes" レジストリ [IANA.HTTP.AuthSchemes] に、以下のスキームを登録した。¶

認証スキーム名:

DPoP¶

参照:

RFC 9449 の第7.1節¶

12.5. メディアタイプ 登録

IANA は、application/dpop+jwt メディアタイプを、 DPoP JWT であることを示すために、 [RFC6838] で説明される方法で、 "Media Types" レジストリ [IANA.MediaTypes] に登録した [RFC2046]。¶

型名:

application¶

サブタイプ名:

dpop+jwt¶

必須パラメーター:

n/a¶

任意パラメーター:

n/a¶

エンコーディングに関する考慮事項:

binary。DPoP JWT は JWT であり、JWT 値は ピリオド ('.') 文字で区切られた一連の base64url エンコード値 （その一部は空文字列の場合がある）としてエンコードされる。¶

セキュリティに関する考慮事項:

RFC 9449 の第11節を参照¶

相互運用性に関する考慮事項:

n/a¶

公開された仕様:

RFC 9449¶

このメディアタイプを使用するアプリケーション:

アプリケーションレベルの所有証明のために RFC 9449 を使用するアプリケーション¶

フラグメント識別子に関する考慮事項:

n/a¶

追加情報:

ファイル拡張子:

n/a¶

Macintosh ファイルタイプコード:

n/a¶

詳細情報の連絡先となる人物およびメールアドレス:

Michael B. Jones, michael_b_jones@hotmail.com¶

想定される用途:

COMMON¶

使用上の制限:

none¶

著者:

Michael B. Jones, michael_b_jones@hotmail.com¶

変更管理者:

IETF¶

12.6. JWT 確認 方法登録

IANA は、[RFC7800] によって 確立された "JWT Confirmation Methods" レジストリ [IANA.JWT] に、以下の JWT cnf メンバー値を 登録した。¶

確認方法値:

jkt¶

確認方法の説明:

JWK SHA-256 Thumbprint¶

変更管理者:

IETF¶

参照:

RFC 9449 の第6節¶

12.7. JSON Web Token クレーム 登録

IANA は、[RFC7519] によって 確立された "JSON Web Token Claims" レジストリ [IANA.JWT] に、以下の Claims を 登録した。¶

HTTP メソッド:

クレーム名:

htm¶

クレーム説明:

要求の HTTP メソッド¶

変更管理者:

IETF¶

参照:

RFC 9449 の第4.2節¶

HTTP URI:

クレーム名:

htu¶

クレーム説明:

要求の HTTP URI （query 部分および fragment 部分なし）¶

変更管理者:

IETF¶

参照:

RFC 9449 の第4.2節¶

アクセストークンハッシュ:

クレーム名:

ath¶

クレーム説明:

関連付けられたアクセストークン値の ASCII エンコーディングの SHA-256 ハッシュを base64url エンコードしたもの¶

変更管理者:

IETF¶

参照:

RFC 9449 の第4.2節¶

12.8. Hypertext Transfer Protocol (HTTP) フィールド名登録

IANA は、この文書で規定される以下の HTTP ヘッダーフィールドを、 [RFC9110] によって確立された "Hypertext Transfer Protocol (HTTP) Field Name Registry" [IANA.HTTP.Fields] に登録した。¶

DPoP:

フィールド名:

DPoP¶

状態:

permanent¶

参照:

RFC 9449¶

DPoP-Nonce:

フィールド名:

DPoP-Nonce¶

状態:

permanent¶

参照:

RFC 9449¶

12.9. OAuth 認可 サーバーメタデータ登録

IANA は、[RFC8414] によって 確立された "OAuth Authorization Server Metadata" レジストリ [IANA.OAuth.Params] に、以下の値を 登録した。¶

メタデータ名:

dpop_signing_alg_values_supported¶

メタデータ説明:

DPoP 証明 JWT 用にサポートされる JWS アルゴリズムのリストを含む JSON 配列¶

変更管理者:

IETF¶

参照:

RFC 9449 の第5.1節¶

12.10. OAuth 動的クライアント 登録メタデータ

IANA は、[RFC7591] によって 確立された IANA "OAuth Dynamic Client Registration Metadata" レジストリ [IANA.OAuth.Params] に、 以下の値を登録した。¶

クライアントメタデータ名:

dpop_bound_access_tokens¶

クライアントメタデータ説明:

クライアントがトークン要求に常に DPoP を使用するかどうかを指定するブール値¶

変更管理者:

IETF¶

参照:

RFC 9449 の第5.2節¶