什麼是 bearer token？

幾乎每一個現代 app 登入或 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。例如：

3. Client 用 token 發送請求

   每次你點「查詢餘額」或「轉帳」，app 就會在 HTTP 請求中帶上 token：

4. API 驗證 token

   伺服器會檢查 token 是否有效、沒過期，並且包含正確權限（如 read:balance 或 write:transfer）。

5. 授權成功

   若一切通過檢查，伺服器會回應你需要的資料。

這種模式在 GitHub API 等服務非常普遍，開發者可以用 bearer token 認證，而不用反覆輸入帳戶資料。

bearer token 為什麼受到歡迎？#

bearer token 之所以流行，因為它解決了網頁安全上的常見問題。不同於以伺服器存儲的 session，bearer token 不需要為每個登入用戶儲存資料。相反，token 本身就包含足夠的資訊，讓伺服器可以驗證請求。

例如，在一個有很多微服務的架構中，讓所有服務共用 session 會很複雜又沒效率。用 bearer token，各服務能獨立驗證請求，整套系統更輕盈、更易擴展。

舉個例子：Slack 的 API 很依賴 bearer token。當你開發 Slack bot 時，會獲得一組 token，讓你的 bot 可以調用 Slack 的 endpoint，毋須為每個 user 維持 session。

bearer token 內部結構#

很多 bearer token 用 JWT（JSON Web Token） 來實現。這些 token 是編碼過的字串，裡面包含用戶資料和其權限。

來解碼一下JWT的範例：

解釋如下：

• sub：主體，即用戶的唯一 ID。
• name：用戶名稱。
• iat：發出時間戳。
• exp：過期時間（token 失效時間）。
• scope：權限範圍，例如可以讀寫訊息。

假設 Jane 的 token 只有 read:messages，那麼應用程式只能幫她讀取訊息，不能代表她發送新訊息。

bearer token 與 access token：有什麼分別？#

bearer token 跟 access token 很容易混淆，因為它們常常一起出現。事實上，兩者相關但不完全等同。

Access token：「許可證」#

Access token 是一種憑證，代表用戶有權訪問某項資源。它會包含：

• 用戶身份（ID）
• 用戶能做什麼（scope/permission）
• token 何時過期

你可以當作由校長簽名的「許可證」。它告訴老師（API），你有權參加校外考察（進入資源）。

例如登入雲端儲存服務時，系統會發放一個帶有 scope 為 read:files 的 access token，通知 API：「這個用戶只可讀取檔案，不能刪除。」

Bearer token：「使用方式」#

bearer token 其實是 access token 的一種。bearer 指的是 token 的「使用方法」：誰拿著它，就可以直接「持」這個 token 存取資源，毋須額外身份驗證。

換句話講：

• 所有 bearer token 都是 access token。
• 但不是所有 access token 都一定是 bearer token。

還有如 holder-of-key token（持有密鑰token）等其他型式，要求客戶端除了 token 還要證明自己持有加密鑰匙。bearer token 省略了這步，所以雖然簡單，若被盜取便容易被濫用。

實務例子#

• Access token（泛指）：可能是簽過名的資料，有時要求 client 證明持有私鑰。
• Bearer token（特指）：今日多數 OAuth 2.0 實作都是 bearer 格式。例如 Google OAuth 回傳一個 access token，你要在 Authorization: Bearer <token> header 內帶上它。

換言之，OAuth 教學提及 access token 時，基本上都是指 bearer token，除非另有註明。

其他 token 形式比較#

為了令圖像更清楚，來看看 bearer token 跟其他常見 token 的分別：

• Refresh token：舊的 access token 過期時用來換新 token。一般不是 bearer token，因為它們必須安全地和授權伺服器交換，不會直接送給 API。
• ID token：用於身份驗證，不是授權。它載有用戶資訊（如 email、姓名、user ID）。有些系統 ID token 也可作為 bearer token，但用途與 access token 有別。
• API key：簡單的憑證，辨認呼叫者應用程式，很多時都像 bearer token 一樣，只要握有 key 就能叫 API。

bearer token 跟 access token 不是對立，而是彼此有重疊：

• 多數 access token 是 bearer token。
• bearer token 其實描述使用方式（誰能拿著就用誰）。
• 實際上，「access token」與「bearer token」在日常多數情況是互通用，但技術上各有重點。

如何驗證 JWT access token (Bearer token)#

驗證 bearer token 是阻擋未授權存取的最後一道防線。若 token 屬 JWT，可於本地快速度驗證，API 毋須每次都聯絡認證中心。

核心步驟#

1. 解析 token。
2. 用發行者的公開金鑰驗證簽名。
3. 檢查標準資訊（claims）：issuer、audience、expiry、not-before。
4. 執行你的 app 規則，如 scope、roles、token 類型。
5. 有需要時查詢撤銷列表或 session 狀態（高風險操作建議）。

JWT 驗證檢查清單#

當你連接 API gateway 或 middleware 時，可用這份 runbook：

• 簽名

  用 header 內的演算法（例如 RS256）驗證簽名。去 issuer 的 JWKS 端點拉取金鑰，比對 kid，並快取之。

• Issuer (iss)

  token 的 iss 必須和你信任的 issuer URL 完全匹配（包括通訊協定）。

• Audience (aud)

  確認 token 是發給你 API 用的。要和你的 API 識別（例如 https://api.example.com 或邏輯 audience 字串）對比。

• Expiration (exp) 和 Not-Before (nbf)

  過期的 token 即時拒絕。提醒要尊重 nbf，不可在起始前使用。要考慮時鐘誤差，通常設定 30-60 秒。

• Issued-At (iat)

  用來 debug，或在嚴格系統拒絕非常舊的 token。

• Token 類型

  一定要確認是access token，有些供應商 typ 為 "at+jwt" 之類。不接收 ID token 來存取 API。

• Scope / 權限

  查閱 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，實行起來其實很容易。
• long-lived token — 若 token 有效期很長，攻擊者的得手機會也會大增。

現實中，有開發者不小心將 bearer token commit 到公開 GitHub repo，攻擊者會掃描這些 token，即時冒用取得非法權限。

安全使用 bearer token 的最佳實踐#

落實最佳實踐才能安全使用 bearer token。逐項例舉如下：

1. 一定要用 HTTPS

   試想在公共咖啡店 wifi 用 HTTP 傳輸 token。區網內任何人在監聽流量，都能複製你的 token 再冒用登入。

2. access token 要短效期

   大多數平台發出的 token 一小時內會過期。譬如 Google OAuth token 通常只維持一小時，就要 refresh。

3. Refresh token 要小心儲存

   refresh token 可不用重新登入就獲取新 access token。但必須妥善存放（如放在 server 端加密資料庫），不要保存在 client 端 storage。

4. Scope 要最小化

   如果你的 app 只要讀日曆，不要要求 write:calendar。若 token 遺失，損失可降至最低。

5. 必要時撤銷 token

   SaaS app 通常讓用戶可查看並撤銷活躍 session。例如 GitHub 可隨時撤銷 personal access token。

6. 監控 token 用量

   紀錄 token 使用情況有助發現可疑行為。例如同一 token 幾分鐘內同時於倫敦及紐約現身，就是危險警號。

bearer token 與其他認證方法的比較#

將 bearer token 與其他常用方法比較很有啟發性：

• Cookies & Sessions

  傳統網站會用以 cookie 識別，由 server 儲存 session 的方式。這方法適合 browser app，但對 API 或手機 app 效率較低。例如 Facebook 桌面主要用 cookie，手機 API 就用 token。

• API Key

  API key 是一組靜態字串，認證應用程式而不是 user。如天氣 app 取數據用的是 API key，server 並不知道是哪個 user。bearer token 可帶 user 資訊，更具彈性。

• Mutual TLS (mTLS)

  某些高安全系統會雙向部署憑證。雖然極安全，但難以大規模部署。對多數 SaaS 平台來說，bearer token 在安全與易用間取得了平衡。

重點總結#

• bearer token 簡單卻強大：誰握有 token，誰就能存取資源。
• 在 OAuth 2.0 與 OIDC 流程中極為常見，尤其是 API 及手機 app。
• 安全性取決於如何管理它：短效期、scope、HTTPS、支持撤銷都很重要。
• 雖未必永遠最佳方案，但多數 SaaS / API 場景下，bearer token 可兼顧安全與方便。