繁體中文（台灣）
什麼是 Bearer Token？
了解什麼是 Bearer Token、它們在 OAuth 2.0 和 JWT 中的運作方式、與 Access Token 的區別，以及最佳實踐。
Guamian
Product & Design
Product & Design
了解什麼是 Bearer Token、它們在 OAuth 2.0 和 JWT 中的運作方式、與 Access Token 的區別，以及最佳實踐。
幾乎每個現代應用程式登入或 API 請求背後，都有個默默工作的主角：Bearer Token。你可能沒注意到它，但每次連接服務、登入，或從雲端擷取資料時，它都存在。
本指南將帶你了解 Bearer Token 的作用、其重要性，以及如何安全處理。
Bearer Token 是一段資料，通常是一串字元，用來證明持有者有權存取某個資源。重點在於，無論誰持有此 Token，都能使用它，而無需額外的身分驗證。
就像一張登機證。一旦你拿到了，就能通過安檢並登機。如果登機證有效，沒有人會再要求你出示身分證。同理，Bearer Token 讓你的應用程式可以直接 "登機 API"，每次請求時不必重複驗證身分。
例如，你在手機登入 Spotify 後，每次播放歌曲時都不用再輸入密碼。這是因為 App 儲存了一組 Bearer Token，告訴 Spotify 伺服器「這個請求來自授權用戶」。
Bearer Token 的流程可分為幾個步驟：
用戶登入
假設你用帳號密碼登入銀行 App。
身分提供者發行 Token
驗證通過後，驗證伺服器會回傳一組 Bearer Token。例如：
客戶端使用 Token
每次你點擊「查詢餘額」或「轉帳」時，App 都會在 HTTP 請求中附上 Token：
API 驗證 Token
伺服器會檢查 Token 是否仍有效、有無過期，並是否包含正確的權限（例如 read:balance 或 write:transfer）。
授權成功
如果所有檢查通過，伺服器就會回傳請求的資訊。
這種模式廣泛用於如 GitHub API 的服務中，開發者以 Bearer Token 驗證，不必每次都輸入帳密。
Bearer Token 之所以廣受歡迎，是因為它解決了一些 Web 安全的通病。與伺服器端 Session 不同，它不需為每個登入用戶儲存資料，Token 本身就包含了足夠的資訊，讓伺服器可驗證請求。
例如，在微服務架構中，數十個服務彼此通訊，若還要維護集中式 Session Storage，會很複雜、低效。有了 Bearer Token，每個服務都能自行驗證請求，系統更輕量、易擴展。
具體例子：Slack API 就高度依賴 Bearer Token。打造 Slack 機器人時，你會獲得一組 Token，使 Bot 能執行 API 呼叫，而不用為每個使用者保存 Session。
許多 Bearer Token 是以 JWT (JSON Web Tokens) 來實作。JWT 是經過編碼的字串，其中包括使用者及其權限等資訊。
解碼一個範例 JWT：
說明如下：
sub：主體 (使用者唯一 ID)name：用戶名稱iat：發行時間戳exp：過期時間（即 Token 失效時間）scope：權限範圍，本例允許讀取和寫入訊息實際上，如果 Jane 的 Token 僅有 read:messages 權限，App 就能讀取她的訊息，但無法幫她發送新訊息。
Bearer Token 與 Access Token 常被混淆，兩者關係密切但不完全相同。
Access Token 是代表用戶獲准使用資源的憑證。它包含：
可將它想像成「校長簽的許可單」，教師（API）只要看到它，就知道你可以參加校外教學（存取資源）。
例如，登入雲端硬碟後，系統會發出一個帶有 read:files 權限的 Access Token。這個 Token 告訴 API：這位使用者只能讀取檔案，不能刪除。
Bearer Token 是 Access Token 的一種。「Bearer」指的是 Token 的使用方式：誰拿著它，誰就能憑此通行，不需額外身分驗證。
換句話說：
還有其他型態，例如持有密鑰(Holder-of-key) Token，需要用戶提供 Token 以外的密鑰證明。Bearer Token 省略此步驟，因此用法簡單，但如果被盜用則風險較高。
<token> 標頭傳送。因此，OAuth 教學裡的「access token」通常就是 Bearer Token，除非另有說明。
再比較 Bearer Token 與其他常見 Token：
Bearer Token 和 Access Token 並非對立概念，而是範圍相關：
Bearer Token 之驗證，是保護 API 免於未授權存取的關鍵。如果用的是 JWT，驗證可在本地快速完成，API 不必每次都向發行者查詢。
API Gateway 或 Middleware 實作時可用以下 Runbook：
簽章
根據標頭指定的演算法（如 RS256）驗證簽章。從發行者 JWKS Endpoint 取得 Key，挑出 kid 相符的 Key 並快取。
Issuer (iss)
Token 的 iss 必須精確比對信任的發行者網址及協議。
Audience (aud)
確保 Token 用於你的 API。比對 API 標識（如 https://api.example.com 或合適的受眾字串）。
Expiration (exp) 和 Not-Before (nbf)
拒絕已過期 Token。尊重 nbf，確保 Token 未到啟用時間不能用。容許小幅時鐘誤差，通常 30–60 秒。
Issued-At (iat)
有助於 Debug，也可於嚴格規範中拒絕過舊 Token。
Token 類型
必須確認為 Access Token。部分發行者會加 typ: "at+jwt"。不要接受 ID Token 存取 API。
Scopes／權限
根據 scope 或平台自訂 Claims（如 permissions、roles）。每個 Endpoint 都要落實最小權限原則。
Subject (sub)
穩定的使用者或 Client ID。用於關聯資源與審計。
重放與廢止（非強制但建議）
敏感 Endpoint 可比對短效失效名單 (denylist) 的 jti，或驗證 Session 記錄，防止登出後或疑似被盜時被濫用。
由於 Bearer Token 採「誰持有誰可用」模式，必須像保管家裡鑰匙一樣謹慎。若有人盜走你的鑰匙，在你換鎖之前都可以進門。
常見風險包含：
現實中，開發者曾因誤將 Bearer Token 提交到公開 GitHub 倉庫，導致駭客自動掃描並立即濫用，取得未經授權的存取權限。
要安全使用 Bearer Token，遵循以下最佳實踐至關重要，舉例如下：
一律使用 HTTPS
如果你在公共咖啡廳 Wi-Fi 上以 HTTP 明文傳送 Token，網路上的任何人都能截取並登錄進你的帳戶。
使用短效存活的 Access Token
大多數平台都會讓 Token 在 1 小時內過期。例如 Google OAuth Token 通常只有效 1 小時，之後需重新換發。
謹慎管理 Refresh Token
Refresh Token 能發送請求取得新 Access Token，讓用戶免於重複登入。但必須安全儲存（例如伺服器端加密資料庫），不可放在客戶端。
最小化權限設計 Scope
App 只需要讀取行事曆時，別申請 write:calendar。這樣就算 Token 洩漏，損害也有限。
必要時撤銷 Token
許多 SaaS 應用都提供檢視活躍登入並撤銷機制。GitHub 例如可隨時撤銷 Personal Access Token。
監控使用行為
記錄 Token 使用，可以發現異常。例如同一 Token 幾分鐘內同時從倫敦和紐約啟用，就是明顯警訊。
與其他常見模式相比，理解 Bearer Token 優缺點也很重要：
Cookies 與 Session
傳統網站主要依賴伺服器端 Session，由 Cookie 識別。這對瀏覽器 App 很有效，但 API 或行動 App 運作效率較低。例如在桌面登入 Facebook 主要靠 Cookie，行動版 App 則用 Token。
API Key
API Key 是靜態字串，識別應用，而非用戶。例如天氣 App 用 API Key 拉資料，但伺服器看不到是誰請求預報。Bearer Token 可包含用戶專屬資料，更具彈性。
雙向 TLS (mTLS)
高安全性系統要求客戶端與伺服器都安裝憑證。雖然較安全，但規模化部署困難。多數 SaaS 平台以 Bearer Token 作為安全性與易用性最佳平衡。