![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -戻る --[[OAuth 2.0 拡張]]（[[OAuth2.0 Proof of Possession]]）~ [[Financial API (FAPI)]]（[[FAPI1>FAPI Part 1 (Read Only API Security Profile)]]、[[FAPI2>FAPI Part 2 (Read and Write API Security Profile)]]）、[[OAuth 2.1]] --[[UserAgentでOAuth2のTokenを取得するベスト・プラクティス]] ---[[OAuth2.0 mTLS>OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens]]（最初の派生） ---[[Token Binding]]（廃止の傾向） ---OAuth2.0 DPoP * 目次 [#gb549535] #contents *概要 [#re9c029a] [[記名式切符>トークン#b38de47f]]作成に関する仕様：TLSに依存せず、アプリケーション・レイヤで処理可能にしたセキュリティ拡張仕様（RFC 9449 として標準化）。~ フロントエンドから使用可能なプラットフォーム上の[[公開鍵・暗号化アルゴリズム>暗号化アルゴリズム#tfda0d72]]を使用する。 -[[記名式切符>トークン#b38de47f]]作成に関する仕様： --TLSに依存せず、アプリケーション・レイヤで処理可能にしたセキュリティ拡張仕様（RFC 9449 として標準化）。 --フロントエンドから使用可能なプラットフォーム上の[[公開鍵・暗号化アルゴリズム>暗号化アルゴリズム#tfda0d72]]を使用する。 -DPoP ＝ Demonstration of Proof-of-Possession at the Application Layer） -[[持参人切符から記名式切符>OAuth 2.0 のトークン#i5f79713]]へ切り替えることでよりセキュアにする。 -方法としては、OAuth 2.0 のアクセストークンを特定のクライアント（秘密鍵）に紐づける。 -このため、TokenリクエストとResourceリクエストにおいて、PoP Proof JWTを使用する。 -[[Token Binding]]のやりたかったことをTLSに依存せず実現した後継の位置付け。 **特徴 [#v11ed105] -SPAなどのPublic Clients全般をターゲットとして仕様が作成されている。 -名前の通り、アプリケーション・レイヤで、[[記名式切符>トークン#b38de47f]]を発行することができる。 -「アプリケーション・レイヤで」とは[[OAuth2.0 mTLS>OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens]]と異なりインフラ・レイヤを必要としないの意味。 ※ [[OAuth2.0 mTLS>OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens]] も [[Token Binding]]もTLSに依存した設計となっている。~ ※ ただし、後者はブラウザ・サポートによりインフラ構築不要になる予定だったが、実現せずに、廃案と成った。 **課題 [#b1d99909] 秘密鍵を何処に保存すりゃいいのか？などの説明が不足している（明示的な規定を避けている）が、~ 一般的な回答としては、エクスポート不可のWeb Crypto API（extractable: false）でインメモリ生成するのが推奨。 *詳細 [#be6f6188] **クライアントが公開鍵・秘密鍵ペアを生成 [#h2063c44] ***Client generates: [#t8d71865] -PrivateKey (秘密・保持) -PublicKey (DPoP Proof JWTに埋め込む) ***プラットフォーム毎のAPI [#p39d131c] Web Crypto API（extractable: false） -ブラウザ：crypto.subtle -Node.js：webcrypto.subtle -iOS/Android ネイティブ：Secure Enclave / Android Keystore **Tokenリクエスト時に DPoP Proof JWT を送信 [#p2f40f59] クライアントは Authorization Server に以下を送る。 ***DPoP HTTPヘッダを入れる。 [#c261504a] POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7ImNydiI6IlAtMjU2Iiwia3R5IjoiRUMiLCJ4IjoiLi4uIiwieSI6Ii4uLiJ9fQ.eyJodG0iOiJQT1NUIiwiaHR1IjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vdG9rZW4iLCJpYXQiOjE2MjM0MjA4MDAsImp0aSI6InVuaXF1ZS1pZCJ9.signature grant_type=authorization_code&code=xxxxx&... ***DPoP Proof JWT の構造： [#u29bee27] json// Header { "typ": "dpop+jwt", "alg": "ES256", "jwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." } } // Payload { "htm": "POST", // HTTPメソッド "htu": "https://server.example.com/token", // エンドポイントURL "iat": 1623420800, // 発行時刻（リプレイ攻撃対策） "jti": "unique-id" // 一意なID（リプレイ攻撃対策） } // Signature (秘密鍵で署名) **Authorization Server がトークンを発行 [#l7fa5e79] -DPoP Proof JWTの署名を検証 --htm・htu の一致確認で当該処理を目的としているか確認。 --jti・iat を用いてリプレイ攻撃チェックを行う。 -Accessトークンの発行 --公開鍵のハッシュ（cnf.jkt）をAccessトークンに埋め込む --json // アクセストークン（JWT）のペイロードに含まれる { "sub": "user123", "cnf": { "jkt": "0ZcO...（公開鍵のSHA-256ハッシュ）" } } ***Resource Serverへのリクエスト [#b68e159d] 毎回 新しい DPoP Proof JWT を生成 GET /resource HTTP/1.1 Authorization: DPoP eyJhbGciOi... ← Bearer ではなく DPoP スキーム DPoP: eyJ0eXAiOiJkcG9wK2p3dCIs... ← Proof JWT ***Resource Serverが検証 [#e99ec573] -Accessトークンの cnf.jkt（公開鍵ハッシュ）を取得 -DPoP Proof の署名を検証 --htm・htu の一致確認で当該処理を目的としているか確認。 --jti・iat を用いてリプレイ攻撃チェックを行う。 --DPoP Proof JWT の jwk ハッシュ と cnf.jkt との一致確認（トークンと鍵の紐づけ確認） *参考 [#re074ec0] -SPAなClientがトークンを安全に扱えるかもしれない拡張仕様「OAuth2.0 DPoP」とは - r-weblife~ https://ritou.hatenablog.com/entry/2019/04/19/070000 -draft-fett-oauth-dpop-01 - OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer~ https://tools.ietf.org/html/draft-fett-oauth-dpop ---- Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]
