繁體中文（台灣）
  • bearer token
  • jwt

什麼是 Bearer Token？

了解什麼是 Bearer Token、它們在 OAuth 2.0 和 JWT 中的運作方式、與 Access Token 的區別，以及最佳實踐。

Guamian
Guamian
Product & Design

不要在使用者認證上浪費數週時間
使用 Logto 更快地發布安全應用程式。幾分鐘內整合使用者認證，專注於您的核心產品。
立即開始
Product screenshot

幾乎每個現代應用程式登入或 API 請求背後，都有個默默工作的主角：Bearer Token。你可能沒注意到它，但每次連接服務、登入，或從雲端擷取資料時，它都存在。

本指南將帶你了解 Bearer Token 的作用、其重要性，以及如何安全處理。

什麼是 Bearer Token？

Bearer Token 是一段資料，通常是一串字元，用來證明持有者有權存取某個資源。重點在於，無論誰持有此 Token，都能使用它，而無需額外的身分驗證。

就像一張登機證。一旦你拿到了，就能通過安檢並登機。如果登機證有效，沒有人會再要求你出示身分證。同理，Bearer Token 讓你的應用程式可以直接 "登機 API"，每次請求時不必重複驗證身分。

例如，你在手機登入 Spotify 後，每次播放歌曲時都不用再輸入密碼。這是因為 App 儲存了一組 Bearer Token，告訴 Spotify 伺服器「這個請求來自授權用戶」。

Bearer Token 實際運作流程

Bearer Token 的流程可分為幾個步驟：

  1. 用戶登入

    假設你用帳號密碼登入銀行 App。

  2. 身分提供者發行 Token

    驗證通過後，驗證伺服器會回傳一組 Bearer Token。例如：

  1. 客戶端使用 Token

    每次你點擊「查詢餘額」或「轉帳」時，App 都會在 HTTP 請求中附上 Token：

  1. API 驗證 Token

    伺服器會檢查 Token 是否仍有效、有無過期，並是否包含正確的權限（例如 read:balance 或 write:transfer）。

  2. 授權成功

    如果所有檢查通過，伺服器就會回傳請求的資訊。

這種模式廣泛用於如 GitHub API 的服務中，開發者以 Bearer Token 驗證，不必每次都輸入帳密。

為什麼 Bearer Token 變得流行

Bearer Token 之所以廣受歡迎，是因為它解決了一些 Web 安全的通病。與伺服器端 Session 不同，它不需為每個登入用戶儲存資料，Token 本身就包含了足夠的資訊，讓伺服器可驗證請求。

例如，在微服務架構中，數十個服務彼此通訊，若還要維護集中式 Session Storage，會很複雜、低效。有了 Bearer Token，每個服務都能自行驗證請求，系統更輕量、易擴展。

具體例子：Slack API 就高度依賴 Bearer Token。打造 Slack 機器人時，你會獲得一組 Token，使 Bot 能執行 API 呼叫，而不用為每個使用者保存 Session。

Bearer Token 裡包含什麼？

許多 Bearer Token 是以 JWT (JSON Web Tokens) 來實作。JWT 是經過編碼的字串，其中包括使用者及其權限等資訊。

解碼一個範例 JWT：

說明如下：

  • sub：主體 (使用者唯一 ID)
  • name：用戶名稱
  • iat：發行時間戳
  • exp：過期時間（即 Token 失效時間）
  • scope：權限範圍，本例允許讀取和寫入訊息

實際上，如果 Jane 的 Token 僅有 read:messages 權限，App 就能讀取她的訊息，但無法幫她發送新訊息。

Bearer Token 與 Access Token：有何不同？

Bearer Token 與 Access Token 常被混淆，兩者關係密切但不完全相同。

Access Token：類似「許可單」

Access Token 是代表用戶獲准使用資源的憑證。它包含：

  • 用戶身分（ID）
  • 可作哪些操作（scopes/permissions）
  • Token 到期時間

可將它想像成「校長簽的許可單」，教師（API）只要看到它，就知道你可以參加校外教學（存取資源）。

例如，登入雲端硬碟後，系統會發出一個帶有 read:files 權限的 Access Token。這個 Token 告訴 API：這位使用者只能讀取檔案，不能刪除。

Bearer Token：「傳遞格式」

Bearer Token 是 Access Token 的一種。「Bearer」指的是 Token 的使用方式：誰拿著它，誰就能憑此通行，不需額外身分驗證。

換句話說：

  • 所有 Bearer Token 都是 Access Token。
  • 但不是所有 Access Token 都必須是 Bearer Token。

還有其他型態，例如持有密鑰(Holder-of-key) Token，需要用戶提供 Token 以外的密鑰證明。Bearer Token 省略此步驟，因此用法簡單，但如果被盜用則風險較高。

實務範例

  • 一般 Access Token：可能是簽名過的資料，有時還要求用戶證明持有對應私鑰。
  • Bearer Token（具體）：大多數現今 OAuth 2.0 實作，會以 Bearer 格式頒發 Access Token。例如 Google OAuth 回傳的 Access Token，需在 Authorization: Bearer <token> 標頭傳送。

因此，OAuth 教學裡的「access token」通常就是 Bearer Token，除非另有說明。

其他 Token 類型對比

再比較 Bearer Token 與其他常見 Token：

  • Refresh Token：主要用來在舊的 Access Token 過期後換取新 Token。Refresh Token 通常不是 Bearer Token，因為它們只會安全地與授權伺服器交換，不會直接發送給 API。
  • ID Token：用於認證（驗證身分），而非授權。攜帶如 Email、名稱或 User ID 等資訊。依不同系統，ID Token 也可以是 Bearer Token，但用途上和 Access Token 不同。
  • API Key：更簡單的憑證，用來識別應用本身。API Key 在很多情境下就像 Bearer Token，因為誰有這組 Key 誰就能訪問 API。

Bearer Token 和 Access Token 並非對立概念，而是範圍相關：

  • 大多數 Access Token 都是 Bearer Token。
  • Bearer Token 指的是Token 的使用方式（憑 Token 存取資源）。
  • 實務上「Access Token」和「Bearer Token」常被互用，但技術上意義略有不同。

如何驗證 JWT Access Token（Bearer Token）

Bearer Token 之驗證，是保護 API 免於未授權存取的關鍵。如果用的是 JWT，驗證可在本地快速完成，API 不必每次都向發行者查詢。

核心流程

  1. 解析 Token。
  2. 用發行者的公鑰驗證簽章。
  3. 檢查 standard claims，如發行者、受眾、到期、未啟用前使用等。
  4. 強制執行 App 的規則（scopes、角色、Token 類型等）。
  5. 針對高風險行為，選擇性查詢廢止清單或 Session 狀態。

驗證清單（JWT）

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 採「誰持有誰可用」模式，必須像保管家裡鑰匙一樣謹慎。若有人盜走你的鑰匙，在你換鎖之前都可以進門。

常見風險包含：

  • Token 竊盜：駭客若取得瀏覽器 localStorage 儲存的 Token，即可冒用用戶。例如 2018 年，有瀏覽器擴充功能被發現竊取 localStorage 的 Token 並販售。
  • 重放攻擊：攔截 Token 的攻擊者，可不斷重用至過期。沒有 HTTPS 加密時，這種攻擊意外地簡單。
  • 長壽命 Token：Token 若有效期為數週甚至數月，攻擊者可用的時間窗口拉長。

現實中，開發者曾因誤將 Bearer Token 提交到公開 GitHub 倉庫，導致駭客自動掃描並立即濫用，取得未經授權的存取權限。

Bearer Token 實務安全建議

要安全使用 Bearer Token，遵循以下最佳實踐至關重要，舉例如下：

  1. 一律使用 HTTPS

    如果你在公共咖啡廳 Wi-Fi 上以 HTTP 明文傳送 Token，網路上的任何人都能截取並登錄進你的帳戶。

  2. 使用短效存活的 Access Token

    大多數平台都會讓 Token 在 1 小時內過期。例如 Google OAuth Token 通常只有效 1 小時，之後需重新換發。

  3. 謹慎管理 Refresh Token

    Refresh Token 能發送請求取得新 Access Token，讓用戶免於重複登入。但必須安全儲存（例如伺服器端加密資料庫），不可放在客戶端。

  4. 最小化權限設計 Scope

    App 只需要讀取行事曆時，別申請 write:calendar。這樣就算 Token 洩漏，損害也有限。

  5. 必要時撤銷 Token

    許多 SaaS 應用都提供檢視活躍登入並撤銷機制。GitHub 例如可隨時撤銷 Personal Access Token。

  6. 監控使用行為

    記錄 Token 使用，可以發現異常。例如同一 Token 幾分鐘內同時從倫敦和紐約啟用，就是明顯警訊。

Bearer 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 作為安全性與易用性最佳平衡。

重要總結

  • Bearer Token 雖然簡單，但非常有用：誰持有就能存取資源。
  • 在 OAuth 2.0、OIDC 流程中及 API、行動 App 中被廣泛使用。
  • 安全取決於管理方式：重視短存活期、Scope、HTTPS 加密及必要時撤銷。
  • 雖非唯一選擇，但大多數 SaaS 及 API 場景下，Bearer Token 兼顧安全與便利性。
免費試用 Logto Cloud