OAuth 2.0 安全最佳實務：PKCE、state 參數與更多

驗證與授權是現代軟體的骨幹。每次使用者登入、呼叫 API 或執行受保護動作時，系統都必須確認身分與權限。在分散式系統中，這些檢查不僅要安全，還要快且可靠。

OAuth 2.0 是廣泛採用的框架，讓應用程式安全存取使用者資源，且從不暴露密碼或憑證。其彈性與擴展性適合網頁、行動與 API 系統，但設定錯誤或略過防護會帶來嚴重安全風險。

本指南以實務角度拆解 OAuth 2.0 安全。你將了解其運作方式、須防範的漏洞，以及最佳實務——涵蓋 PKCE、state 參數、權杖管理等——協助你建置可上線的安全授權系統。

為何 OAuth 2.0 安全很重要

OAuth 2.0 讓客戶端代表使用者或服務存取資源，而無須共用密碼。它將驗證與授權解耦，支援可擴展的整合、微服務與跨平台應用。

然而 OAuth 的彈性也帶來潛在攻擊面。若無適當防護，攻擊者可能：

• 攔截存取權杖
• 偽造授權請求
• 取得敏感資源的未授權存取

因此確保 OAuth 2.0 流程安全，與保護密碼或 API 金鑰同等重要。安全決策必須刻意為之，涵蓋權杖如何發行、驗證、傳輸與撤銷。

理解 OAuth 2.0

OAuth 2.0 定義數種角色與元件：

• 資源擁有者（Resource Owner）——擁有資料或資源的使用者
• 客戶端（Client）——請求存取的應用程式
• 授權伺服器（Authorization Server）——在使用者驗證後發行存取權杖
• 資源伺服器（Resource Server）——託管受保護資源

權杖是 OAuth 的核心。最常見類型為：

• 存取權杖（Access Tokens）——短期、授予特定資源存取的權杖
• 重新整理權杖（Refresh Tokens）——較長期，用於取得新的存取權杖

OAuth 流程依客戶端類型（機密 vs. 公開）與平台而異。例如：

• 授權碼流程（Authorization Code）——適合伺服器端應用；使用中繼碼交換存取權杖
• 隱含流程（Implicit）——適合瀏覽器應用（現因安全疑慮已不建議）
• 客戶端憑證流程（Client Credentials）——機器對機器通訊
• 資源擁有者密碼憑證流程——鮮少建議；涉及直接傳遞憑證

每種流程有特定安全考量；在錯誤情境使用錯誤流程會產生漏洞。

OAuth 2.0 的核心安全需求

安全的 OAuth 實作須滿足多項實務需求：

1. 權杖必須有效且不可偽造——僅授權伺服器能產生有效權杖。
2. 流程必須防 CSRF 與重放——例如 state 參數可防跨站請求偽造。
3. 必須強制權杖過期——短期權杖降低外洩後的暴露時間。
4. 權杖儲存與傳輸必須安全——HTTPS 與安全儲存可防止攔截。
5. 必須支援撤銷——使用者或管理員應能作廢權杖。
6. 必須強制 scope——權杖僅應授予最小必要存取。

未滿足這些需求是 OAuth 安全事件的常見來源。

常見 OAuth 2.0 漏洞

多數 OAuth 安全問題來自實作錯誤，而非協定本身缺陷。

1. 缺少或薄弱的 PKCE

PKCE（Proof Key for Code Exchange）保護公開客戶端（如行動 App）的授權碼流程，對抗攔截攻擊。沒有 PKCE 時，攻擊者可能攔截授權碼並交換為權杖。

2. state 參數管理不當

state 參數可防跨站請求偽造（CSRF）。若參數缺失、可預測或驗證鬆散，攻擊者可誘使使用者授權非預期動作。

3. 存取權杖效期過長

權杖若長時間有效，外洩後攻擊者可長期濫用。使用短期存取權杖搭配重新整理權杖可降低暴露。

4. 不安全的儲存

權杖存在 localStorage、未加密資料庫或日誌中可能被竊。網頁應使用 HTTP-only、Secure cookie；行動應使用裝置安全儲存。

5. scope 與 audience 驗證不足

存取權杖僅應允許已明確授權的操作與資源。未驗證 scope 或 audience 可能讓攻擊者存取非預期資源。

6. 缺少權杖撤銷

若無撤銷機制，遭竊權杖在過期前仍有效。處理敏感資料的系統應提供撤銷端點或權杖版本化。

OAuth 2.0 安全最佳實務

遵循已驗證的最佳實務有助緩解常見漏洞並強化 OAuth 實作。

1. 公開客戶端務必使用 PKCE

PKCE 透過以下方式防止授權碼被攔截：

• 在客戶端產生隨機 code verifier
• 在授權請求一併送出雜湊後的 code challenge
• 以授權碼換權杖時驗證 code challenge

現今多數行動與 SPA 客戶端需要 PKCE。

2. 使用強健的 state 參數

state 參數應：

• 隨機產生
• 每次授權請求唯一
• 在回呼時驗證

這可防 CSRF 並確保回應與請求對應。

3. 短期存取權杖＋重新整理權杖

短期權杖降低外洩風險。重新整理權杖應安全地用於取得新存取權杖，並具備自身的撤銷與輪替機制。

4. 安全傳輸權杖

權杖必須一律經 HTTPS 傳輸以防攔截。混合內容或未加密通道是嚴重漏洞。

5. 安全儲存權杖

安全儲存依平台而異：

• 網頁應用——HTTP-only、Secure cookie
• 行動應用——加密鑰匙圈或安全儲存 API
• 伺服器端應用——記憶體或受保護的設定儲存

避免將權杖暴露給腳本或未保護的日誌。

6. 驗證每個權杖

權杖須檢查：

• 簽章有效性
• 過期時間
• audience 與 scope
• 發行者身分

略過任一驗證步驟可能導致未授權存取。

7. 實作權杖撤銷

撤銷機制包括：

• 權杖黑名單
• 權杖版本化（敏感帳戶變更時遞增版本）
• 輪替簽章金鑰

撤銷確保遭竊權杖可在過期前作廢。

8. 限制權杖中的敏感資料

存取權杖應僅含授權所需最少資訊。避免嵌入密碼、祕密或敏感個資。若需額外資料，可考慮加密載荷或從安全後端取得。

9. 適當時使用非對稱簽章

權杖可對稱（共用密鑰）或非對稱（私鑰／公鑰）簽章。非對稱簽章在分散式環境較安全：

• 私鑰簽署權杖
• 公鑰驗證權杖
• 服務之間無須共用密鑰

此法簡化金鑰輪替，並在金鑰外洩時降低暴露。

10. 透過 scope 強制最小權限

務必定義並強制 scope，確保權杖僅授予最小必要權限。權杖外洩時可限制損害範圍。

可觀測性與營運效益

OAuth 2.0 權杖亦可支援營運可見度：

• 跨服務追蹤請求
• 關聯使用者活動
• 辨識異常存取模式
• 偵錯驗證問題

審慎設計的權杖結構可同時改善安全與可維護性。

何時適合採用 OAuth 2.0

OAuth 2.0 適合需要：

• 委派資源存取
• 分散式服務或 API
• 跨平台客戶端
• 行動或 SPA 應用

的系統。廣泛用於 API 授權、單一登入（SSO）與聯合身分系統。

何時 OAuth 2.0 未必理想

以下情況 OAuth 2.0 可能不適合：

• 需要立即撤銷權杖至關重要
• 需要嚴格集中控制
• 權杖大小必須極小
• 舊式或簡單應用不需要委派授權

此時傳統工作階段式驗證或專有協定可能更簡單且更安全。

設計安全的 OAuth 2.0 系統

安全應從系統設計一開始納入，而非事後補救。OAuth 2.0 可能處理權杖發行與存取委派，但整體安全仍取決於架構、基礎建設與營運的決策。

在建置或擴展系統前，團隊應仔細評估：

• 各流程的威脅模型——了解應用可能面臨的攻擊類型，例如權杖攔截、CSRF 或重放。早期對應威脅有助設計能抵抗它們的流程。
• 合規需求——GDPR、HIPAA 或產業規則可能規定權杖儲存、傳輸或撤銷方式。對齊合規可同時滿足安全與法遵。
• 基礎建設規模與複雜度——跨多服務、區域或客戶端的系統需要更嚴格的金鑰管理、監控與權杖驗證策略。
• 營運成熟度——團隊是否具備監控、日誌與撤銷能力，能快速回應可疑權杖活動或外洩。

預先規劃這些面向，可降低系統成長變複雜時引入漏洞的風險。安全會成為架構內建的一部分，而非日後貼上的補丁。

實務 OAuth 安全檢查清單

用此清單驗證你的 OAuth 實作：

• 公開客戶端已實作 PKCE
• 已使用並驗證 state 參數
• 權杖為短期；重新整理權杖處理安全
• 所有請求強制 HTTPS
• 權杖儲存安全
• 已驗證 scope 與 audience
• 撤銷機制存在且經測試
• 權杖不含敏感資料
• 簽章金鑰定期輪替
• 日誌與監控可捕捉可疑權杖活動

遵循此清單可降低 OAuth 相關安全事件的可能性。

結語

OAuth 2.0 是現代授權的彈性且強大框架。正確實作時，應用可在永不暴露使用者憑證的前提下，安全地委派存取。

多數安全問題並非來自 OAuth 本身，而是實作缺口——例如缺少 PKCE、state 處理薄弱、權杖過長、儲存不安全或驗證不完整。採用短期權杖、PKCE、強 state、撤銷策略與穩健簽章等最佳實務，可顯著降低風險。

安全應是系統設計的刻意選擇。審慎架構、仔細實作與持續營運實務，可確保 OAuth 流程在系統成長時仍可靠、可擴展且安全。

若團隊希望安全且自信地實作 OAuth 2.0，Authgear 提供可上線的工具，涵蓋安全權杖管理、流程驗證與營運可見度。

立即開始使用 Authgear，簡化 OAuth 採用、強制最佳實務，並從第一天起安全擴展你的授權系統。

常見問題

OAuth 2.0 最大的安全風險是什麼？

流程實作不當，特別是缺少 PKCE 或未驗證 state，可能讓攻擊者攔截授權碼或權杖。

OAuth 2.0 權杖預設就安全嗎？

僅在流程正確實作、具強簽章、完整驗證與安全儲存時才安全。薄弱實作會引入漏洞。

敏感資料應放在權杖內嗎？

不應。權杖僅應含最少必要資訊。敏感資料應留在安全後端系統。

簽章金鑰或密鑰應多久輪替一次？

應依風險與安全政策定期輪替。輪替可限制金鑰外洩後的暴露，屬標準實務。