了解 bearer token 是什麼、它在 OAuth 2.0 和 JWT 中如何運作、與 access token 的分別，以及最佳實踐。
幾乎每一個現代 app 登入或 API 請求背後，都潛藏著一位安靜的功臣：bearer token（持有者權杖）。你可能未必察覺，但每當你連接服務、登入，或從雲端擷取數據時，它都在幕後默默運作。
本指南會逐步解釋 bearer token 的作用、重要性，以及如何安全處理它們。
Bearer token 是一段資料，通常是一串文字，用來證明持有者有權限存取某個資源。重點在於，誰「持有」這個 token，誰就可以使用它，無需再提供其他證明。
想像一下登機證。只要你拿著它，就可以通過安檢上飛機。如果登機證有效，沒有人會再要求你出示身份證。同樣地，bearer token 讓你的應用程式「登上 API」，不用每次都重新核實身份。
例如，你在手機登入 Spotify 後，不用每次播歌都再輸入密碼。相反，app 會儲存一個 bearer token，告訴 Spotify 伺服器「這個請求來自已授權用戶」。
bearer token 的流程可分為幾個步驟：
用戶登入
假設你用用戶名和密碼登入銀行 app。
身份認證服務發出 token
通過驗證後，認證伺服器會回傳一個 bearer token。例如：
Client 用 token 發送請求
每次你點「查詢餘額」或「轉帳」，app 就會在 HTTP 請求中帶上 token：
API 驗證 token
伺服器會檢查 token 是否有效、沒過期，並且包含正確權限（如 read:balance 或 write:transfer）。
授權成功
若一切通過檢查，伺服器會回應你需要的資料。
這種模式在 GitHub API 等服務非常普遍，開發者可以用 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 用 JWT（JSON Web Token） 來實現。這些 token 是編碼過的字串，裡面包含用戶資料和其權限。
來解碼一下JWT的範例：
解釋如下：
sub：主體，即用戶的唯一 ID。name：用戶名稱。iat：發出時間戳。exp：過期時間（token 失效時間）。scope：權限範圍，例如可以讀寫訊息。假設 Jane 的 token 只有 read:messages，那麼應用程式只能幫她讀取訊息，不能代表她發送新訊息。
bearer token 跟 access token 很容易混淆，因為它們常常一起出現。事實上，兩者相關但不完全等同。
Access token 是一種憑證，代表用戶有權訪問某項資源。它會包含：
你可以當作由校長簽名的「許可證」。它告訴老師（API），你有權參加校外考察（進入資源）。
例如登入雲端儲存服務時，系統會發放一個帶有 scope 為 read:files 的 access token，通知 API：「這個用戶只可讀取檔案，不能刪除。」
bearer token 其實是 access token 的一種。bearer 指的是 token 的「使用方法」：誰拿著它，就可以直接「持」這個 token 存取資源，毋須額外身份驗證。
換句話講：
還有如 holder-of-key token（持有密鑰token）等其他型式，要求客戶端除了 token 還要證明自己持有加密鑰匙。bearer token 省略了這步，所以雖然簡單，若被盜取便容易被濫用。
<token> header 內帶上它。換言之，OAuth 教學提及 access token 時，基本上都是指 bearer token，除非另有註明。
為了令圖像更清楚，來看看 bearer token 跟其他常見 token 的分別：
bearer token 跟 access token 不是對立，而是彼此有重疊：
驗證 bearer token 是阻擋未授權存取的最後一道防線。若 token 屬 JWT，可於本地快速度驗證，API 毋須每次都聯絡認證中心。
當你連接 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 commit 到公開 GitHub repo，攻擊者會掃描這些 token，即時冒用取得非法權限。
落實最佳實踐才能安全使用 bearer token。逐項例舉如下：
一定要用 HTTPS
試想在公共咖啡店 wifi 用 HTTP 傳輸 token。區網內任何人在監聽流量，都能複製你的 token 再冒用登入。
access token 要短效期
大多數平台發出的 token 一小時內會過期。譬如 Google OAuth token 通常只維持一小時，就要 refresh。
Refresh token 要小心儲存
refresh token 可不用重新登入就獲取新 access token。但必須妥善存放（如放在 server 端加密資料庫），不要保存在 client 端 storage。
Scope 要最小化
如果你的 app 只要讀日曆，不要要求 write:calendar。若 token 遺失，損失可降至最低。
必要時撤銷 token
SaaS app 通常讓用戶可查看並撤銷活躍 session。例如 GitHub 可隨時撤銷 personal access token。
監控 token 用量
紀錄 token 使用情況有助發現可疑行為。例如同一 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 在安全與易用間取得了平衡。