Google OAuth 支援 DPoP：強化 Refresh Token 安全性

Google OAuth 平台導入 DPoP，強化 Refresh Token 安全

Google 於 2026 年 10 月 15 日宣佈，OAuth 平台正式支援 DPoP（Demonstrating Proof-of-Possession，證明持有權）。這項更新用密碼學機制把長效的 Refresh Token 綁定到發送者，藉此抵禦 Infostealer 惡意軟體（如 RedLine、NodeStealer）和中間人攻擊（AiTM）。Google Identity 與其 OAuth 平台是面向開發者的服務，透過實作 OAuth 2.0 與 DPoP 等密碼學安全控制，保護 API 整合。此外，Google Workspace 的 Context-Aware Access (CAA) 也使用 DPoP，在 Gemini Enterprise Agent Platform 上，透過 Agent Gateway 以密碼學方式驗證 Agent 身分，確保企業 AI 工作負載的安全。

效能與安全的架構取捨

Google 只對 Refresh Token 支援 DPoP 綁定，這是務實的工程取捨。傳統 OAuth Bearer Token 採「拾獲者即擁有者」模式，容易被竊取與重放。DPoP 是 RFC 9449 定義的應用層安全規範，會把 Token 與客戶端產生的非對稱金鑰配對綁在一起。即使 Token 被竊，攻擊者沒有對應的私鑰，也無法重放。

不過，Google 的短效 Access Token 仍維持標準 Bearer Token 格式。原因是在 Gmail、Calendar、Drive 這類高吞吐量的資源 API 上，如果每個請求都要驗證非對稱密碼學簽章（如 ES256），API Gateway 會產生龐大的運算開銷，帶來可測量的延遲與擴展成本。Google 把 DPoP 綁定嚴格限定在 Refresh Token，就能保護最敏感的憑證（長效憑證可無限取得新的 Access Token），同時讓絕大多數 API 請求不需要任何密碼學驗證開銷，維持開發者預期的高效能與低延遲。

實作要求與架構建議

實作 DPoP 時，客戶端要處理密碼學金鑰生成、嚴格的時間戳記與 nonce、特定宣告的計算（htm、htu、iat、jti）、精確的標頭建構，以及 DPoP proof JWT 的建構。這些變更可能帶來額外的系統限制，用來支撐安全計算、處理與儲存。

依據 IETF 的 OAuth 2.0 安全最佳實務（RFC 9700）及針對瀏覽器應用程式的草案，Google 建議在 Backend-for-Frontend (BFF)、Token-Mediating Backend 和 Browser-based OAuth Client 等模型中使用 DPoP，限制 Refresh Token 的發送者。傳輸層的 Token 綁定（如 mTLS/RFC 8705）常在現代雲端代理伺服器或負載平衡器處被中斷或終止。DPoP 則運作於 HTTP 標頭層級，因此在複雜的多跳環境中相當穩健，包括新興的 Model Context Protocol (MCP) 與自主 Agent 架構。

多 Agent 委派與 MCP 支援

在自主 AI Agent 與 MCP 架構中，保護工具使用 Token 至關重要。在 Multi-Agent 工作負載裡，如果 Agent A 把任務委派給 Agent B，Agent B 沒有 Agent A 的私鑰就無法簽署 DPoP proof，而共享私鑰又違反 DPoP 的核心安全原則。

Google 的核心消費者 OAuth 端點（oauth2.googleapis.com）不支援 OAuth 2.0 Token Exchange (RFC 8693)。因此開發者建構多 Agent 或聯邦雲端工作負載時，應考慮使用 Google Cloud Secure Token Service (STS)。透過 STS 做委派路由，中間 Agent 可以把上游 Token 換成新的短效聯邦 Token，並將它密碼學綁定到自己本地的金鑰配對。這個做法能讓整條 Agent 鏈都維持發送者受限的安全模型，同時避免金鑰暴露。

與 DBSC 的互補防禦

DPoP 主要保護 API Token，不保護標準網頁應用程式的 Session Cookie，而 Session Cookie 仍是 Infostealer 的主要目標。為了解決 Cookie 竊取問題，Google 與 Web Incubator Community Group (WICG) 正積極開發 Device Bound Session Credentials (DBSC)。DBSC 運作於瀏覽器與網路層級，把 Session Cookie 以密碼學方式綁定到裝置硬體（如 TPM）。DPoP 與 DBSC 合在一起，構成針對 API 與網頁使用者會話憑證竊取的全面深度防禦策略。

開發者可參考 Google 提供的 DPoP Adoption Guide 與 DPoP adoption SKILL.md 來實作這項機制，提升平台安全性。