JWT 與 OAuth：主要差異、協同運作方式及最佳實踐
簡明指南，說明 JWT 和 OAuth 如何不同、如何互補，以及如何有效結合兩者的最佳實踐。
Product & Design
如果你剛接觸驗證，且正在開發一個處理登入、付款或用戶資料的應用程式，你很可能已經聽過 JWT 和 OAuth 這兩個詞。它們聽起來可能很複雜、像是「只屬於後端」的話題，但事實上並不只是安全工程師才需要了解。
有了 API、第三方整合，以及像 AI、MCP、代理型系統等新興技術，這兩個技術直接關係到你產品的易用性、安全性與成長。只要理解基本概念，你就可以：
- 從一開始就設計安全的功能
- 有效與你的工程團隊溝通
- 在驗證和用戶流程上做出更佳的產品決策
- 避免傷害用戶信任且成本高昂的安全失誤
舉例來說，在最新的 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，JSON 網頁權杖）與 OAuth（開放授權）通常會一起使用，但各自有不同目的。
你可以這樣想：
- OAuth 是你怎麼把鑰匙給別人，而且只能開他被允許進入的房間。
- JWT 是他隨身帶著的身分證明，證明他是誰、能做什麼。
下一節我們會用對照表詳細拆解它們，讓你清楚了解差異及互補之處。
什麼是 OAuth 2.0？
OAuth 2.0 是被廣泛採用的授權框架，讓應用程式（用戶端）在不用分享用戶憑證（例如密碼）的情況下，只取得有限權限，來存取用戶的資源。
OAuth 的核心角色
- Client（用戶端）： 請求存取權的應用程式。
- Resource owner（資源所有者）： 通常是用戶、授權存取。
- Authorization server（授權伺服器）： 在授權後發出存取權杖。
- Resource server（資源伺服器）： 儲存受保護資源並驗證權杖。
常見 OAuth 授權類型（流程）
- 授權碼流程（Authorization Code Grant）： 最安全且最建議使用，特別適合瀏覽器、SPA、行動 App，並結合 PKCE。
- 隱式流程（Implicit Grant）： 為資安考量，OAuth 2.1 已不建議使用。
- 資源所有者密碼型流程（ROPC）： 直接用帳號密碼換權杖，安全性較低。
- 用戶端憑證流程（Client Credentials Grant）： 適用伺服器對伺服器或機器間通訊。
- 裝置流程（Device Flow）： 適用沒有鍵盤的裝置（如智慧電視），用戶從第二台裝置授權。
什麼是 JWT（JSON Web Token）？
JWT 是一種開放標準（RFC 7519），用來在兩方之間以安全且精簡的 URL 友善方式傳遞權利聲明（claims）。
JWT 的結構
JWT 由三個 base64url 編碼的部分組成，用點（.）分隔：
- Header（標頭）： 指定簽章演算法（如 HS256、RS256）及權杖型態（JWT）。
- Payload（有效負載）： 包含權利聲明（claims），例如：
- iss（發行者）
- sub（主體，如用戶 ID）
- aud（受眾）
- exp（到期時間）
- 其他自訂聲明
- Signature（簽章）－用來保證權杖未被竄改。
範例：
JWT 範例
這是一個典型 JWT 編碼後的樣子，以及它的解碼結構，讓你明白每個部分代表什麼。
編碼後的 JWT（Base64URL）
這個權杖有三部分，用點號分隔：header.payload.signature
解碼後的結構
- Header
- Payload
Payload 中包含權利聲明
- 簽章
簽章確保權杖內容未 遭竄改。
主要特點
- 自包含： 所需資訊全在權杖本身。
- 無狀態： 不需在伺服器保存使用者工作階段。
- 已簽章（或選擇性加密）： 保證真實性。
JWT vs OAuth：核心差異
| 面向 | JWT | OAuth 2.0 |
|---|---|---|
| 定義 | 權杖格式 | 授權框架 |
| 目的 | 安全承載身分／權利聲明 | 定義給予與管理存取方式 |
| 範疇 | 數據表達 | 流程與操作模式 |
| 能單獨使用？ | 可以，供內部權杖處理 | 不可以，需要權杖格式（如 JWT） |
| 範例用途 | API 直接發 JWT 給用戶端 | App 透過 OAuth 流程拿到 access token |
簡言之：
- JWT 是容器： 像一本帶有身分資訊的護照。
- OAuth 是制度系統： 像移民管制，決定誰能拿到護照與擁有哪些權限。
只用 JWT 的場合
以下情境適合只用 JWT：
- 單一系統驗證： 你的 App 直接產生並驗證權杖，不需額外身份提供者。
- 無狀態工作階段管理： 不在伺服器存 session，只用 JWT 驗證身分。
- 簡單 API 驗證： 內部 API 僅需驗證基本存取權、無複雜同意流程。
- 重視效能的驗證： 資源伺服器自己驗證 JWT，不需聯絡認證伺服器。
範例：
你同時開發單頁應用和後端 API。API 發出一個內含 sub（用戶 ID）、role、exp（過期）權利聲明的 JWT。
只用 OAuth 的場合
在這些情況，你僅使用 OAuth 而省略 JWT：
- 你不需要自包含權杖，可以接受需要查找的黑盒權杖（opaque token）。
- 你的資源伺服器每次存取都必須詢問授權伺服器。
- 在傳統或有合規/監管要求的環境，JWT 不適用。
- 目的是安全地委派權限讓第三方應用有限存取。
範例：
你的 API 僅發黑盒存取權杖，每次請求都查詢一次授權伺服器判斷。
同時使用 JWT 和 OAuth 的場合
在這些狀況，你會同時用 JWT 和 OAuth：
- 有多個服務或 API，需要 OAuth 的安全流程 + JWT 能被各服務驗證。
- 支援如「Google 登入」這類第三方登入時，OAuth 處理同意，JWT 承載權杖或身分。
- 執行微服務架構，各服務可本地驗證 JWT。
- 需要同時擁有 OAuth 的授權委派、JWT 的無狀態效能。
範例：
你的 app 讓用戶用 Google 登入。OAuth 處理授權，Google 發 JWT 存取權杖，API 收到權杖本地驗證再回傳資料。
JWT 與 OAuth 的協作方式
在現代驗證／授權架構裡：
- OAuth 處理受權流程。
- 授權伺服器 發出 access token，通常格式為 JWT。
- JWT 隨 API 請求夾帶，證明身分與權限。
OAuth 內的特殊權杖
JWT 及 OAuth 的最佳實踐
- 用 HTTPS 保護權杖傳輸過程。
- 設定短效 JWT 有效期，需長時間則搭配 refresh token。
- 驗證簽章 後才信任權利聲明。
- 檢查 aud 聲明，確保權杖只給你的 app 使用。
- 避免存權杖在 localStorage，如果有 XSS 風險，建議用安全 cookie。
結語
- OAuth 2.0 定義怎麼取得及使用權杖。
- JWT 定義權杖格式與如何承載資訊。
- 兩者是互補非互換。
現代多數 API 都用 OAuth 控管授權流程，用 JWT 作為權杖表達。理解兩者，有助你設計安全、可擴充的驗證架構。