JWT vs OAuth：關鍵分別、如何協同運作及最佳實踐
快速指南，說明 JWT 和 OAuth 有何不同、如何互補，以及如何有效安全地使用它們。
Product & Design
如果你剛接觸認證，並正開發需要處理登入、支付或用戶資料的應用，你很可能已經聽過 JWT 和 OAuth 這兩個名詞。這些詞語乍聽之下好像很複雜、只屬於後端範疇，但其實並不僅限於安全工程師。
隨著 API、第三方整合，以及 AI、MCP 和基於 agent 的新科技興起，這兩項技術直接影響到 你的產品可用性、安全性和增長。了解基本概念讓你能夠：
- 從一開始就設計出安全的功能
- 能有效與工程團隊溝通
- 做出更好的產品決策，優化認證與用戶流程
- 避免損害用戶信任、帶來高昂代價的安全錯誤
例如，在最新的 MCP 規範 中，授權系統以成熟標準為基礎：
- OAuth 2.1 IETF 草案（draft-ietf-oauth-v2-1-13）
- OAuth 2.0 授權伺服器中繼資料（RFC8414）
- OAuth 2.0 動態客戶端註冊協議（RFC7591）
- OAuth 2.0 受保護資源中繼資料（RFC9728）
為什麼這很重要
即使你不會編寫後端程式碼：
- 開發者學會如何保障 API 安全、管理用戶會話與整合第三方服務。
- 產品經理懂得與團隊和合作夥伴討論登入流程、整合與合規性的詞彙。
- 創業者和初創團隊避免構建出一碰整合就壞、容易出現安全漏洞的脆弱登入系統。
JWT vs OAuth：兩個核心概念
JWT（JSON Web Token）和 OAuth（開放授權）經常一同使用，但用途不同。
可以這樣理解：
- OAuth 就是你如何給某人鑰匙，而且只給他可以進入的房間。
- JWT 是身份證件，證明他是誰，可以做什麼。
下一節會把兩者並列解釋，幫你清楚看清差異及如何互補。
什麼是 OAuth 2.0？
OAuth 2.0 是被廣泛採用的授權框架，允許應用（客戶端）在不必拿到用戶憑證（例如密碼）的情況下，以有限權限存取用戶資源。
OAuth 的核心角色
- 客戶端（Client）： 請求存取權的應用。
- 資源擁有者（Resource owner）： 一般是用戶，負責授權。
- 授權伺服器（Authorization server）： 在授權後發出 access token。
- 資源伺服器（Resource server）： 托管受保護資源，驗證 token。
常見的 OAuth 授權模式（流程）
- 授權碼模式（Authorization Code Grant）： 最安全、推薦使用，特別配合 PKCE，常見於瀏覽器、SPA 及手機應用。
- 隱式授權模式（Implicit Grant）： 出於安全考慮，在 OAuth 2.1 已不建議使用。
- 資源擁有者密碼模式（ROPC）： 直接用用戶名、密碼換取 token，安全性較低。
- 客戶端憑證模式（Client Credentials Grant）： 用於伺服器對伺服器、機器對機器溝通。
- 裝置流程（Device Flow）： 適合無鍵盤的裝置（如智能電視），讓用戶用另一裝置授權。
什麼是 JWT（JSON Web Token）？
JWT 是一項開放標準（RFC 7519），可讓兩方以簡潔、URL 安全的方式安全傳遞宣告（claims）。
JWT 的結構
一個 JWT 包含三個經 base64url 編碼，由點（.）分隔的部分：
- Header（標頭）： 指定演算法（如 HS256、RS256）及 token 類型（JWT）。
- Payload（負載）： 承載宣告，如：
- iss（簽發者）
- sub（主體，例如用戶 ID）
- aud（目標受眾）
- exp（過期時間）
- 需要時可加自訂宣告
- Signature（簽名）：驗證 token 沒有被竄改。
例子：
JWT 範例
以下是一個典型 JWT 的編碼形式，以及解碼後結構，讓你看到每部分代表什麼。
已編碼的 JWT（Base64URL）
這由三個用點分隔的部分組成：header.payload.signature
解碼後結構
- Header（標頭）
- Payload（負載）
Payload 包含宣告（claims）
- Signature（簽名）
簽名確保 token 沒 被竄改。
主要特性
- 自包含： token 內已含所需資料。
- 無狀態： 無需在伺服器儲存 session。
- 已簽署（可選加密），確保真實性。
JWT vs OAuth：核心分別
| 層面 | JWT | OAuth 2.0 |
|---|---|---|
| 定義 | Token 格式 | 授權框架 |
| 目標 | 安全傳遞身份／宣告 | 定義授權與權限管理流程 |
| 範疇 | 數據表達 | 流程設計 |
| 可獨立運作？ | 可以，用於內部 token 處理 | 不可以，需要某種 token 格式（如 JWT） |
| 使用例子 | API 直接發 JWT 給客戶端 | 應用透過 OAuth 流程獲取 access token |
簡單來說：
- JWT 是容器： 就像帶有身份詳細資料的護照。
- OAuth 是系統： 就像出入境控制，決定誰能拿到護照以及可進入哪些地方。
什麼情況只用 JWT
以下情境可單獨使用 JWT：
- 單一系統驗證： 應用自行簽發和驗證 token，無需外部身份提供者。
- 無狀態 session 管理： 驗證用戶身份，不用儲存 session data。
- 簡單 API 驗證： 只需驗證基本存取權，無需複雜授權流程的內部 API。
- 著重效能的驗證： 資源伺服器本地驗證 token，無需查詢授權伺服器。
例子：
你擁有的 SPA（單頁應用）和後端 API。API 發一個含 sub（用戶 ID）、role、exp（過期）等宣告的 JWT。
什麼情況只用 OAuth
以下狀況可單獨使用 OAuth，而不用 JWT：
- 不需要自包含 token，opaque token（需查詢授權端）的方案可接受。
- 需要每次存取資源時資源伺服器都查詢授權伺服器。
- 受限於舊系統或法規環境，無法用 JWT。
- 目的是透過授權流程給第三方應用有限存取權。
例子：
API 發出 opaque access token，每次請求都查詢授權伺服器以驗證。
什麼情況應同時用 JWT 和 OAuth
適用於：
- 你有多個服務／API，想要 OAuth 打造安全流程，同時跨服務用 JWT 驗證 token。
- 提供第三方登入（如「以 Google 登入」）：OAuth 負責用戶授權，JWT 作為 access 或 ID token 傳遞身份。
- 微服務架構時，每個服務都能本地驗證 JWT。
- 想利用 OAuth 的權限委派及 JWT 的無狀態效驗，提升可擴展性。
例子：
你的應用讓用戶能用 Google 登入。OAuth 掌管授權流程，Google 簽發 JWT access token，而你的 API 能本地驗證再回應數據。
JWT 和 OAuth 如何協同運作
現代認證／授權系統中：
- OAuth 管理存取授權流程。
- 授權伺服器 簽發 access token，通常是 JWT。
- JWT 隨 API 請求一同發送，以證明身份與權限。
OAuth 中的特殊 token
- ID token：OpenID Connect 用來證明用戶身份；永遠是 JWT。
- Access token：可以是 JWT 也可以是 opaque token。
使用 JWT 與 OAuth 的最佳實踐
- 用 HTTPS 傳輸 token，保護傳送過程的安全性。
- 將 JWT 存活期設得較短；若需長時登入，請用 refresh token。
- 一定要驗證簽名，確保宣告被信任前未被竄改。
- 檢查 aud 宣告，確保 token 屬於你的應用。
- 避免把 token 存在 localStorage，如有 XSS 風險，請優先考慮安全 cookie。
結語
- OAuth 2.0 定義如何取得與使用 token。
- JWT 定義 token 格式及承載資訊的方式。
- 兩者互補，不能互換。
大部分現代 API 都用 OAuth 管理授權流程，用 JWT 實現 token 表達。了解兩者有助你設計安全、可擴展的身份驗證系統。