背景：Bearer Token 的根本弱點
OAuth 2.0 是目前網際網路上最廣泛使用的授權框架，讓使用者不必把密碼交給第三方應用，就能授權對方存取自己的資料。然而傳統 OAuth 使用的 Bearer Token（持有者權杖）有一個長期為人詬病的設計缺陷：誰拿到權杖，誰就能使用它。這種「撿到就是你的」模式意味著，一旦權杖被竊取，攻擊者可以直接冒充合法客戶端呼叫 API，伺服器端完全無從分辨。
這不是理論上的風險。近年來 Infostealer（資訊竊取）類惡意軟體，例如 RedLine 和 NodeStealer，已經發展成規模化的產業，專門從受感染裝置上蒐集權杖與 Cookie。此外，AiTM（Adversary-in-the-Middle，中間人攻擊）也能攔截傳輸中的憑證。根據 InfoQ 在 2026 年 10 月 29 日由 Sergio De Simone 報導的消息，Google 的 OAuth 平台近期正式支援 DPoP 機制，正是為了緩解這兩類攻擊。
核心內容：DPoP 如何讓被偷走的權杖失效
DPoP 全名為 Demonstrating Proof-of-Possession（持有證明），是 OAuth 2.0 的安全擴充機制。它的核心想法是：把權杖和一把非對稱金鑰對綁定在一起。客戶端自行產生一組金鑰對，私鑰留在自己手上，公鑰則在申請權杖時交給伺服器。之後每次使用權杖，客戶端都要用私鑰對請求簽署一份 DPoP proof JWT（一種帶簽章的證明檔），證明「我確實是這把金鑰的持有者」。
這樣一來，攻擊者就算偷到權杖，因為沒有對應的私鑰，也無法重放（replay）這個權杖去呼叫 API。權杖從「誰撿到誰能用」變成「只有真正持有私鑰的人才能用」，攻擊的門檻大幅提高。
Google 的取捨：只保護 Refresh Token
值得注意的是，Google 的 OAuth 平台目前只在 refresh token（重新整理權杖）上支援 DPoP，生命週期較短的 access token（存取權杖）仍是標準 Bearer Token。這個取捨有明確的理由：長期有效的 refresh token 是「持續性線上冒充」的主要攻擊媒介，一旦外洩，攻擊者可以不斷換取新的 access token，危害最大，因此優先用密碼學綁定保護；而 access token 本身存活時間短，若也套用 DPoP，每個請求都要做非對稱加密驗證，會帶來明顯的運算開銷。
不過，導入 DPoP 對客戶端有額外要求：必須產生與管理加密金鑰、正確處理時間戳與 nonce（一次性隨機數，用來防止簽章被重放）、組出正確的 HTTP 標頭與 DPoP proof JWT。對既有應用來說，這代表實作複雜度的上升。
脈絡解讀：DPoP 之外還需要 DBSC
DPoP 保護的是 API 權杖，但涵蓋範圍有限——一般的網頁應用 session cookie 並不在保護範圍內，而這些 Cookie 同樣是 Infostealer 的目標。為了補上這一塊，Google 正與 WICG（Web Incubator Community Group，網頁孵化社群組）合作開發 DBSC（Device Bound Session Credentials，裝置綁定工作階段憑證）。DBSC 在瀏覽器與網路層運作，把瀏覽器的 session cookie 以密碼學方式綁定到裝置的硬體安全模組（例如 TPM 晶片），讓 Cookie 離開原裝置就失去作用。
兩者合起來，構成一套完整的「縱深防禦」策略：DPoP 負責 API 權杖，DBSC 負責網頁使用者工作階段，各自針對不同層面的憑證竊取威脅。
影響與限制：多代理工作流程與瀏覽器內金鑰的難題
DPoP 並非萬能，Google 自己也指出幾個限制。首先是多代理（multi-agent）工作流程不適用：如果一個 AI 代理要把任務委派給另一個代理，後者必須代表前者簽署請求，但這需要接觸前者的私鑰，直接違反 DPoP 的設計原則。Google 建議的替代方案是透過 Google Cloud Secure Token Service（STS）：中間代理把上游權杖交換成一份新的、短期有效、綁定自己本地金鑰對的聯合權杖，讓「發送方受限」的安全模型在整條代理鏈上延續，同時不必暴露任何私鑰。
其次是客戶端本身的信任問題。DPoP 的私鑰存放在客戶端，整體安全性最終取決於客戶端環境。Google 的 Dhruv Agnihotri 指出，跑在瀏覽器裡的單頁應用（SPA）並無法完全防止金鑰被濫用。IETF 針對瀏覽器應用的指導方針因此建議採用 Backend-for-Frontend（BFF）模式，把權杖與金鑰留在後端、不進瀏覽器。Agnihotri 另外提出一種零持久化（zero-persistence）做法，在沒有伺服器端基礎設施可用的情境下作為折衷方案。
對開發者而言，這波變化傳達的訊息很清楚：憑證竊取已是規模化威脅，單靠 HTTPS 與短期權杖不夠，密碼學綁定正在成為新一代安全基線。導入 DPoP 的成本主要落在客戶端實作與金鑰管理，但換來的是權杖被偷也難以濟事的基本保障。實務上應同時評估 BFF 架構、DBSC 進展，以及多代理場景下的 STS 委派模式，才能建立完整的防護。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。