背景：授權伺服器整併進 Spring Security
InfoQ 刊出的〈Server-Side DPoP and Token Exchange in Spring Security 7〉（作者 Dhruv Agnihotri）指出，Spring 在 2025 年底的發布分成三步：Spring Framework 7.0 於 11 月 13 日、Spring Security 7.0 於 11 月 17 日、Spring Boot 4.0 於 11 月 20 日。對自行維運身分提供者（IdP）的團隊而言，真正重要的變動藏在 OAuth 伺服器這一層。Spring 團隊早在 2025 年 9 月 11 日便宣布，自 2020 年起獨立、2022 年 11 月才正式 GA 的 Spring Authorization Server，將併入 Spring Security 7.0；1.5.x 是最後一個獨立發展的分支，之後新功能都在 Spring Security 內部進行。Spring Security 7.1.0 於 2026 年 6 月推出並搭配 Spring Boot 4.1，7.1.1 在 8 月跟上。
這場合併最容易被誤解的地方是 Maven 座標。artifactId 與 groupId 都沒有改變，仍是 org.springframework.security:spring-security-oauth2-authorization-server，變的只有版號從 1.5.x 換到 Spring Security 的版本線。這不是換套件，而是一次版號升級；並不存在名為 spring-authorization-server 的成品需要改名。唯一真正的重新命名發生在 Boot starter：spring-boot-starter-oauth2-authorization-server 已被 spring-boot-starter-security-oauth2-authorization-server 取代，兩者在 4.1.1 之前都仍會發布。
合併後的實際好處，是 DPoP 簽發、refresh token 的 DPoP 綁定、Token Exchange，以及資源伺服器端的 DPoP 驗證，終於落在同一個模組、同一個版號裡。過去要把這些湊齊，得把特定版本的獨立授權伺服器與特定版本的 Spring Security 綁在一起，祈禱相容矩陣剛好對上；現在只需要記一個版號。
升級要先付的基線成本
在談新功能之前，Spring Security 7 有一筆與 OAuth 無直接關係的基線成本：HttpSecurity builder 移除了 and()、Jackson 3 取代 Jackson 2，以及若干 JWT 解碼器的預設值變動。其中兩項對授權伺服器特別有感。第一是 typ 標頭的檢查方式。6.5 時期要求開發者自行呼叫 validateTypes(false) 關掉 Nimbus 內建的 typ 檢查，再自行註冊 JwtTypeValidator.jwt()；到了 7.0，這兩個動作由框架自動完成。聽起來像是放寬驗證，其實相反：JwtTypeValidator.jwt() 要求 typ 必須是 JWT 或不存在，因此任何帶有其他 typ 的權杖，例如 RFC 9068 定義的 at+jwt 存取權杖型別，在 7.0 之後會預設驗證失敗，除非明確註冊一個允許該型別的驗證器。真正的稽核重點不是「我的權杖還能不能過」，而是「我的權杖帶的是哪一種 typ」。
第二是持久化。若應用程式用 Spring 的 Jackson 模組把 OAuth2Authorization 物件寫進資料庫，模組註冊必須從 Jackson 2 的 SecurityJackson2Modules 換成 Jackson 3 的 SecurityJacksonModules，而且位於新的 org.springframework.security.jackson 套件；漏改會讓先前存下的授權狀態在反序列化時直接壞掉。若團隊本來就追上 6.5 的 deprecation，這一段基線遷移大約是一個 sprint 的工作量；若落後好幾個版本，建議把基線遷移與新功能導入拆成兩件事做。
DPoP 在伺服器端：簽發與驗證
DPoP（Demonstrating Proof of Possession，RFC 9449）的目標是把存取權杖綁定到客戶端持有的一把金鑰。客戶端產生非對稱金鑰對，每次請求附上一枚短效的 proof JWT；授權伺服器在權杖端點驗證這枚 proof，並把簽發的權杖綁到 proof 的公鑰上。資源伺服器之後若沒收到同一把金鑰簽出的新 proof，就拒絕該權杖。被偷走的權杖少了私鑰等於無用，這就是整套機制的重點。
proof 的格式由 RFC 9449 §4.2 定義：標頭帶 typ: dpop+jwt、非對稱演算法，以及以 jwk 內嵌的客戶端公鑰；內容以 htm（HTTP 方法）、htu（去掉查詢與 fragment 的目標 URI）、iat 與唯一的 jti 把 proof 綁到該次請求。當 proof 伴隨存取權杖送到資源伺服器時，還會多帶該權杖的 base64url SHA-256 雜湊值。在授權伺服器端，Spring 會自動組好驗證機制：DPoPProofVerifier 與搭配的 DPoPProofJwtDecoderFactory 會執行 §4.3 要求的檢查，包括 JWT 格式正確、typ 為 dpop+jwt、使用非 none 的非對稱演算法、簽章可用內嵌 jwk 驗證，以及 htm／htu 與權杖請求相符。
有兩件看起來像需要決策的事其實不用管。cnf.jkt 的綁定由 Spring 自動填入，存取權杖上的 cnf 宣告其 jkt 成員即為 proof 公鑰的 RFC 7638 JWK SHA-256 指紋，唯一要留意的是別讓 token customizer 意外覆寫掉 cnf；資源伺服器之後比對的是這個指紋，不是公鑰、也不是憑證雜湊。相對地，公開客戶端的 refresh token 綁定也已由框架處理：RFC 9449 §5 要求公開客戶端在權杖端點出示 proof 時，取得的 refresh token 必須綁到同一把金鑰，之後換發也得證明持有同一把金鑰。Spring Authorization Server 從 2025 年 4 月的 1.5.0-RC1 起自動加入並延續到 7.x，沒有開關可翻；機密客戶端沿用既有的客戶端憑證綁定，因此這項機制對單頁應用與原生應用最為關鍵。
真正留給維運者的是兩件事。首先是 nonce 挑戰。RFC 9449 §8 允許授權伺服器要求 proof 內含一個由伺服器指定、無法事先製造的 nonce，資源伺服器端的對應機制在 §9；當伺服器要求而客戶端沒帶時，回應是 error: use_dpop_nonce 加上 DPoP-Nonce 標頭，授權伺服器端回 400、資源伺服器端回 401。但在 Spring Security 7.1.1 為止，Spring 的 DPoP 程式碼兩端都沒有實作：不發 DPoP-Nonce 標頭、不處理 use_dpop_nonce、也沒有任何驗證器檢查 proof 中選用的 nonce 宣告。RFC 把 nonce 定為 SHOULD 而非 MUST，這大概是不做的理由；但若威脅模型需要它，就得自行打造整套機制。其次是重放快取。RFC 9449 §11.1 要求在合理時間窗內拒絕 jti 已出現過的 proof。在 Spring Security 7.0.x 與 7.1.0 上，這個檢查是寫死的：一個固定一千筆的記憶體快取藏在 DPoPProofJwtDecoderFactory 裡，無法替換。從 Spring Security 6.5.12／7.1.1 起改為可插拔的 DPoPProofReplayValidator，預設搭配自己的 InMemoryCache（十萬筆、依金鑰分別設上限）。這個預設實作的 Javadoc 直接寫明它只適用單節點部署，並點名 Redis 與 Hazelcast 這類分散式快取才是叢集環境該提供的替代品。
資源伺服器：驗證改為明確 opt-in
資源伺服器端是 Spring 7 刪掉最多自製程式碼的地方。DPoP 綁定權杖的驗證自 Spring Security 6.5.0 系列進入 GA（2025 年 5 月）。版本細節在這裡很關鍵：7.0 只要 classpath 上出現 DPoP 類別就自動套用驗證，沒有 DSL 掛勾；7.1 則加入明確的 dPoP(Customizer) 方法，把支援改為 opt-in 且可自訂。這是升級時真正的行為變更，不只是多一個選項：原本依賴 6.5 或 7.0 自動套用驗證的應用程式，包括完全靠 Spring Boot 預設資源伺服器自動組態、從未呼叫新掛勾的那些，一旦升上 7.1，若沒有明確加上 .dPoP()，就會默默停止強制 DPoP。
另外，DPoP 綁定的權杖是以 DPoP 認證方案送達，而不是 Bearer；用 Bearer 送是常見卻錯誤的捷徑。實際驗證工作由 DPoPAuthenticationProvider 執行。程式碼審查時有個命名陷阱值得先記住：資源伺服器端的 provider 叫 DPoPAuthenticationProvider，沒有 OAuth2 前綴，和下一段的 OAuth2TokenExchangeAuthenticationProvider 不同；而且轉換器與 provider 分屬不同套件，DPoPAuthenticationConverter 位於 ...resource.web.authentication，DPoPAuthenticationProvider 與 DPoPAuthenticationToken 則在 ...resource.authentication，少了 web 這一段。
Token Exchange：把委派變成標準授權類型
多數自建 IdP 都長著某種「服務帳號交換」的變體：服務 A 需要以使用者名義呼叫服務 B，於是去拿第二組憑證、透過側通道另發一枚權杖，或直接把使用者的權杖往下游送，祈禱對方的 audience 檢查夠寬鬆。RFC 8693 的 Token Exchange 用標準授權類型取代這些做法，該功能自 Spring Authorization Server 1.3.0-M3（2024 年 3 月）進入，現已在 7.x 模組中。授權類型為 urn:ietf:params:oauth:grant-type:token-exchange，請求中帶 subject_token（代表被代理一方的權杖）、選用的 actor_token（代表實際行動一方的權杖），以及呼叫端想要的 audience、resource 與 scope。
RFC 8693 §1.1 區分的兩種語意是這項功能的核心。模擬（impersonation）簽出的權杖看起來就是主體本人，行動者消失；委派（delegation）則保留雙方身分，簽出的權杖同時帶主體與 act（actor）宣告，記錄誰在代誰行動。決定拿哪一種的只是單一參數：只送 subject_token，Spring 的 OAuth2TokenExchangeAuthenticationProvider 會簽出不含 act 的模擬權杖；同時送 actor_token，provider 就會建立委派權杖，act 宣告由 actor_token 推導，而非來自已驗證的客戶端。多跳鏈結則由巢狀 act 宣告表達（§4.1）：最外層是目前的行動者，內層依序是較早的行動者，這些巢狀項目來自 subject_token；若閘道先前的交換已在權杖上留下 act，Spring 會把它當成巢狀項目一併帶過。
在 Spring 端，這個授權類型由 OAuth2TokenExchangeAuthenticationProvider 處理，並透過授權伺服器 configurer 註冊，但不會對每個客戶端預設開啟；呼叫端客戶端的 RegisteredClient 必須宣告 AuthorizationGrantType.TOKEN_EXCHANGE，否則 provider 會以 unsupported_grant_type 拒絕。act 宣告本身由框架依 actor token 建立，不需手工組裝。真正留給開發者的是縮減簽出權杖的權限，也就是丟掉部分 scope 或換掉 audience，這項工作交給 OAuth2TokenCustomizer<JwtEncodingContext> bean，和處理任何宣告塑形用的是同一個掛勾。這裡有個原則必須守住：交換是縮減權限的地方，永遠不該放大。一個能被利用來取得比 subject token 更大範圍的交換端點，是權限提升漏洞，不是功能。
兩者合用：受限且不可重放的跨服務授權
DPoP 與 Token Exchange 各自都有用，組合起來才補上彼此都補不了的缺口：在服務鏈上傳遞受限的權限，而不必讓每一跳都拿到一枚可重放的 bearer 權杖。設想一個邊緣服務從客戶端收到 DPoP 綁定的存取權杖，需要以使用者名義呼叫訂單服務，但不該把使用者的權杖原封轉送——那枚權杖的 audience 是邊緣服務，轉送一枚 bearer 複本等於給訂單服務一個可以拿去別處重放的東西。正確做法是執行一次權杖交換：以使用者的權杖作為 subject_token、自己的權杖作為 actor_token，並在交換請求上附 DPoP proof，要求簽出一枚 scope 為 orders:read、audience 為訂單服務的權杖。授權伺服器會簽出縮減後的權杖，依 actor token 把邊緣服務記進 act 宣告，並因為對方送了 proof，透過 cnf.jkt 把新權杖綁到邊緣服務自己的金鑰。結果是訂單服務收到的權杖可驗證為發自它真正對話的對象、權限恰好是這次呼叫所需，並留有誰委派給誰的稽核軌跡，鏈上沒有任何一跳持有它不會用到的可重放憑證。
限制也很明確：縮減要自己執行。Spring 提供授權類型與 customizer 掛勾，卻不會阻止你寫出放大 scope 或忘記切換 audience 的交換邏輯。這個模式的安全性活在你自己寫的 OAuth2TokenCustomizer 裡，那段程式碼值得有專屬測試。
落地順序與尚未補上的缺口
兩種起點涵蓋多數團隊。全新專案直接落在 Spring Boot 4.1，DPoP 與 Token Exchange 第一天就能用，工作是設定而非遷移：註冊客戶端、決定 nonce 政策、寫好縮減用的 customizer，並在每個資源伺服器打開 .dPoP()；OAuth2TokenCustomizer 從第一次提交就該當成安全關鍵程式碼對待。既有獨立授權伺服器 1.5.x 的團隊則是單純的版號升級：換到 Boot 4.1／Spring Security 7.1 的 BOM，把 spring-security-oauth2-authorization-server 從 1.5.x 升到 7.1.x（座標不變），把殘留的 and() 風格過濾鏈改成 lambda DSL，稽核 JwtDecoder 設定與新的 JwtTypeValidator 預設是否接受自家權杖，更新持久化授權狀態的 Jackson 模組註冊，最後才把啟用 DPoP 與架設權杖交換當成獨立變更處理。
上線時另外有幾個決定要下：切換期間保持 issuer URL 不變；在授權伺服器的中繼資料中宣告 DPoP 與權杖交換授權類型，讓客戶端可探索，也就是在 /.well-known/oauth-authorization-server 文件裡列出可接受的 DPoP 簽章演算法，並把 urn:ietf:params:oauth:grant-type:token-exchange 放進 grant_types_supported；先部署資源伺服器的 .dPoP() 支援，再開始簽發 DPoP 綁定權杖；規劃一段 bearer 與 DPoP 綁定權杖並存的雙軌期；並且逐客戶端註冊開啟 DPoP，而非全域打開。
最後要盯住的是 nonce 缺口。RFC 把它定為 SHOULD，Spring Security 的問題追蹤器中目前也沒有相關功能請求，因此想要這個防護的 IdP 得自行實作。更長遠的趨勢則在單一版本之上：多跳服務呼叫，以及愈來愈多跨越信任邊界的自主代理鏈，需要的是金鑰持有證明與可稽核、可縮減的委派鏈，而不只是 bearer 權杖加一次 scope 檢查。RFC 8693 的巢狀 act 宣告已經為這條鏈建模；當這種架構普及，DPoP 綁定加上權杖交換，看起來就不再只是 Spring Security 7 的一組功能，而會成為身分提供者的基本期待。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。