驗證權杖：類型、用途與最佳實務

什麼是驗證權杖？

想像一下：您上午 9 點在紐約登入企業應用程式。30 分鐘後，有人從東京存取您的帳戶。您的密碼沒有變更。您的多因素驗證 (MFA) 權杖還在桌上。但攻擊者剛用竊取的驗證權杖，直接闖過了您的第一道防線。

驗證權杖是跨企業系統確認您身分的數位識別證。它們是密碼學憑證，因此您的密碼不必隨請求傳送。根據 NIST 特別出版品 800-63B-4，這些權杖是現代資安架構中數位身分保證的基礎。

上述情境並非假設。2023 年，一名威脅行為者從上傳至 Okta 客戶支援系統 的支援檔案中取出工作階段權杖，並劫持了五名客戶的有效工作階段。沒有密碼遭破解，也沒有人回應 MFA 提示。系統收到有效權杖，便依照設計運作。

了解權杖如何運作、在哪些環節失效，以及如何保護權杖，決定了驗證基礎架構能守住防線，還是把鑰匙交給攻擊者。本頁將逐一說明這三點。

為何驗證權杖會成為攻擊目標

權杖位於身分安全與 存取控制 架構的交會處。當您向任何系統驗證身分時，不必在每次請求中傳送實際憑證。您會取得一枚權杖，表示「此人已證明自己的身分」。

攻擊者竊取權杖，就能完全繞過驗證。偽造權杖，就能冒充合法使用者。操弄權杖的驗證方式，即使沒有授權帳戶，也能提升權限。

這類失誤的代價已有充分記錄。 IBM《2026 年資料外洩成本報告》 指出，全球資料外洩的平均成本達 499 萬美元，創下新高。 Verizon《2026 年資料外洩調查報告》(DBIR) 發現，漏洞利用首次超越遭竊憑證，成為資料外洩最主要的入侵途徑。這是該報告 19 年來的第一次。在今年之前，遭竊憑證一直居首。而遭竊權杖，就是已通過第一道驗證關卡的憑證。

要了解這些風險，安全團隊必須先辨識組織部署的各類權杖，以及各類權杖特有的安全考量。

驗證權杖的類型

組織會依安全需求和使用情境部署不同類型的權杖。

• JSON Web Token (JWT)： 自足式權杖，以標頭、酬載和簽章的結構承載編碼後的聲明。JWT 支援無狀態驗證，伺服器無須查詢資料庫即可驗證權杖，因此適合分散式微服務架構。
• OAuth 2.0 權杖： OAuth 框架使用兩種相互配合的權杖。存取權杖為 API 呼叫提供短效憑證，重新整理權杖則無須重新驗證身分，即可取得新的存取權杖。這種區分可限制權杖遭竊造成的損害。
• SAML (安全聲明標記語言) 聲明： 以 XML 為基礎的權杖，由身分提供者與服務提供者交換，供企業單一登入使用。SAML 在傳統企業環境和 B2B 聯合驗證情境中仍占主導地位。
• 工作階段權杖： 由伺服器產生的識別碼，用於將瀏覽器連結至伺服器端的工作階段狀態。與無狀態的 JWT 不同，工作階段權杖需要伺服器儲存，但可立即撤銷。
• FIDO2／硬體權杖： 透過 WebAuthn API 使用公開金鑰密碼學的實體驗證器。這些權杖透過密碼學來源綁定抵禦網路釣魚，確保憑證只能在合法網站使用。

每種權杖各有用途，但都具備決定其安全態勢的共同架構要素。強化防護，就從這些要素開始。

驗證權杖的核心組成要素

驗證權杖包含決定其安全態勢與功能的特定要素。

1. 權杖結構： JWT 由三個部分組成：標頭 (指定 RS256 或 ES256 等簽章演算法)、酬載 (包含聲明) 和簽章 (確保密碼學完整性)。SAML 聲明使用符合 OASIS SAML V2.0 規範的 XML 格式陳述。
2. 權杖中繼資料： 權杖的酬載包含中繼資料。到期時間戳記 (exp 聲明) 定義有效期間，簽發時間聲明 (iat) 確立權杖已簽發多久，JWT ID (jti) 提供唯一識別碼以追蹤撤銷狀態，對象限制 (aud 聲明) 則防止權杖跨服務重複使用。
3. 工作階段熵值： 網頁應用程式的工作階段權杖需要 最低熵值，並透過密碼學安全的偽隨機數產生器 (CSPRNGs) 產生。
4. 硬體權杖密碼學： FIDO2 權杖結合 WebAuthn 瀏覽器 API 與用戶端對驗證器通訊協定 (CTAP)。私密金鑰永不離開安全元件，而密碼學來源綁定可確保憑證只能在合法網站使用。

這些要素組成各種流程，而流程決定了權杖安全的成敗。以下各節將逐一追蹤流程，包括權杖如何與 多因素驗證.

驗證權杖如何運作

驗證權杖會依類型和部署情境遵循不同的運作流程.

• JWT 驗證流程: 您將憑證提交給驗證伺服器. 伺服器驗證憑證, 產生 JWT 並以密碼學方式簽署, 其中包含到期時間, 適用對象和簽發者聲明, 然後將其傳回您的用戶端. 後續提出請求時, 您在 Authorization 標頭中附上 JWT. 資源伺服器驗證簽章並確認聲明後才授予存取權.
• OAuth 2.0 授權碼流程: 您請求存取受保護的資源. 完成驗證並取得同意後, 伺服器會核發授權碼, 供您的應用程式交換存取權杖和更新權杖. 您使用短效存取權杖呼叫 API, 並在需要時以更新權杖交換新的存取權杖.
• SAML 網頁瀏覽器 SSO: 您嘗試存取服務提供者的應用程式, 該應用程式會將您重新導向至身分提供者. 完成驗證後, IdP 產生已簽署的 SAML 斷言並將其傳送給服務提供者, 建立您的已驗證工作階段, 讓您能透過單一登入存取多個應用程式.
• 權杖更新與輪替: 短效存取權杖經常到期, 因此需要更新機制. 每次使用更新權杖時, 權杖輪替機制都會產生新的更新權杖, 防止重放攻擊. 如果有人重複使用更新權杖, 系統會偵測到可能的入侵, 並可撤銷整個權杖群組.
• 硬體權杖驗證: 您在裝置的安全元件中產生金鑰組, 以註冊 FIDO2 驗證器. 驗證時, 服務會傳送密碼學挑戰, 由您的驗證器使用私密金鑰簽署. 服務則使用已註冊的公開金鑰驗證簽章.

正確實作後, 這些流程的複雜性便有了價值. 以下說明其效益如何展現.

Reduce Identity Risk Across Your Organization

Detect and respond to attacks in real-time with holistic solutions for Active Directory and Entra ID.

Get a Demo

驗證權杖的使用情境

驗證權杖可滿足企業環境中的特定安全與營運需求.

1. 企業單一登入: SAML 斷言讓員工只需驗證一次, 就能存取數十個應用程式, 無須重複登入. Okta, Azure AD 和 Ping Federation 等身分提供者會核發服務提供者信任的權杖, 減少反覆輸入密碼的負擔, 並集中管理存取權.
2. API 與微服務安全: OAuth 2.0 存取權杖可保護分散式架構中的服務間通訊. 每個微服務都會獨立驗證傳入的權杖, 無須共用工作階段儲存區, 即可實現無狀態擴充.
3. 第三方授權: OAuth 2.0 支援「使用 Google 登入」等情境, 讓使用者無須分享密碼, 即可授權應用程式存取其資料. 授權伺服器會核發限定範圍的權杖, 限制應用程式可存取的內容.
4. 行動應用程式工作階段: JWT 為行動應用程式提供持續有效的驗證. 儲存在 iOS Keychain 或 Android KeyStore 中的權杖在應用程式重新啟動後仍可使用, 透過平台專屬的安全儲存機制維持安全性, 同時提供流暢的使用者體驗.
5. 機器對機器驗證: 自動化系統和 IoT 裝置使用用戶端憑證授權取得 API 存取權杖. 這些權杖可在無須人工介入的情況下, 驗證排程工作, 監控系統和裝置通訊.

這些情境都遵循相同模式. 權杖取代重複傳送憑證, 改以接收系統能自行驗證的聲明.

驗證權杖的主要優勢

以權杖為基礎的驗證在四個方面優於傳統工作階段管理:

1. 無狀態擴充能力: 以權杖為基礎的系統無須在伺服器端儲存工作階段, 讓微服務架構中的個別服務無須共用狀態, 即可獨立驗證憑證.
2. 跨網域單一登入: SAML 2.0 斷言和 OpenID Connect 支援單一登入. 使用者只需驗證一次, 就能存取多個應用程式, 無須重複登入, 並可集中管理驗證機制.
3. API 安全與 零信任: 使用 OAuth 2.0 用戶端憑證和已簽署 JWT 進行服務間驗證, 可防止惡意服務冒充受信任的服務, 這對零信任架構.
4. 縮小攻擊面: 遵循標準的實作方式可防範特定攻擊. HttpOnly Cookie 可防止 JavaScript 存取. SameSite 屬性可阻止跨網站請求偽造 (CSRF) 攻擊. FIDO2 權杖透過密碼學來源綁定抵禦網路釣魚.

然而, 這些優勢也伴隨取捨. 帶來擴充能力與彈性的架構決策, 同時也引入安全團隊必須因應的挑戰.

驗證權杖的挑戰與限制

以權杖為基礎的驗證帶來特定的營運與安全挑戰, 需要審慎規劃架構.

1. 權杖撤銷的複雜性: 無狀態特性雖然帶來擴充優勢, 卻使立即終止存取變得困難. 無狀態權杖在到期前仍然有效, 因此必須選擇縮短有效期並承擔更高的更新負擔, 建立會抵銷無狀態優勢的權杖黑名單基礎架構, 或接受撤銷生效前的時間差.
2. 權杖有效期限管理的取捨: 短效存取權杖能降低遭竊後的潛在損害，但必須不斷交換重新整理權杖。較長的有效期限可改善使用者體驗，但權杖一旦遭竊，暴露風險的時間也更長。
3. 跨平台安全儲存權杖: 任何在網頁中執行的指令碼都能讀取 localStorage 和 sessionStorage，因此只要有一個跨網站指令碼攻擊 (XSS)漏洞，兩者都會變成有效權杖的清單。廣泛採用的混合式做法將重新整理權杖存放在 HttpOnly Cookie 中、將存取權杖保留在記憶體中，並在重新整理端點執行 CSRF 檢查。記憶體中的存取權杖仍可能因主機遭入侵後的記憶體傾印而外洩，這正是 端點安全防護的用途。行動應用程式需要依平台選擇儲存方式：iOS Keychain 直接儲存權杖，Android 則使用 Android Keystore 中保存的金鑰加密權杖。伺服器之間的通訊應使用 HashiCorp Vault 或 AWS Secrets Manager 等密鑰管理系統。
4. 金鑰輪替與密碼學管理: 正式環境中的金鑰輪替增加了協調的複雜度。組織必須在輪替期間維持多把有效的簽章金鑰、協調分散式服務的輪替，並正確驗證金鑰識別碼 (kid)。

這些實作挑戰會形成特定漏洞，攻擊者正積極在企業環境中加以利用。

常見的驗證權杖實作錯誤

大多數驗證權杖外洩事件源於實作錯誤，而非密碼學缺陷。了解這些常見錯誤，有助於安全團隊排定強化措施的優先順序。

• 不安全的用戶端儲存方式: 將驗證權杖儲存在瀏覽器的 localStorage 或 sessionStorage，是最常見的實作錯誤之一。任何在網頁環境中執行的 JavaScript 程式碼，都能直接存取並竊取驗證權杖，使權杖立即面臨 XSS 攻擊風險。
• 簽章驗證失敗: 未正確驗證 JWT 簽章，會產生可被利用的驗證繞過漏洞。演算法混淆攻擊會將演算法標頭從 RS256 (非對稱) 竄改為 HS256 (對稱)，再將公開金鑰當作 HMAC 密鑰來簽署權杖。有漏洞的系統會接受這些修改後的權杖，導致權限提升。此漏洞記錄於CVE-2024-54150，CVSS 評分為 9.1，嚴重程度為 CRITICAL。部分實作會接受指定 "alg: none" 的權杖，實際上將未簽署的權杖視為有效。
• 權杖有效期限過長: 權杖有效期限設定得過長，會帶來持續性的安全風險。長效權杖讓攻擊者有更長的可乘之機。一旦權杖透過 XSS 或中間人攻擊遭竊，過長的有效期限就會讓未經授權的存取持續數天甚至數週，而非僅有數分鐘。
• 缺乏權杖撤銷機制: 缺乏權杖撤銷功能，是架構上的重大缺口。Azure AD 等 SSO 實作所使用的主要重新整理權杖 (PRT) 一旦遭竊，問題尤其棘手。沒有撤銷機制，組織就無法即時終止遭入侵的工作階段，只能等待權杖自然過期。
• 不安全的金鑰管理: 金鑰管理失當會造成系統性漏洞。SQL 注入漏洞若存在於金鑰擷取機制中，當應用程式透過 kid 參數以有漏洞的 SQL 查詢擷取 JWT 金鑰時，就可能洩露簽章金鑰。將敏感資訊存入 JWT 酬載會造成不必要的資料暴露，因為 JWT 宣告僅經過 base64 編碼 (並未加密)，任何取得權杖的人都能輕易讀取。

這些失誤都有具體的事件與時間。2022 年 4 月，一名攻擊者利用從 Heroku 和 Travis CI 竊取的 OAuth 權杖下載數十個組織的私人儲存庫，包括 npm。本頁開頭所述的 Okta 工作階段權杖竊取事件，手法相同：錯誤的人出示有效權杖，系統卻不加查驗就予以接受。

這些失誤全都可以預防，相關控管措施也已有明確文件可循。以既有標準建立縱深防禦，就能封堵攻擊者仰賴的缺口。

驗證權杖最佳實務

保護驗證權杖，必須依據權威安全標準實施縱深防禦策略，例如 NIST SP 800-63B-4, OWASP，以及 IETF 規範。

• 部署 HttpOnly 和 Secure Cookie: 將重新整理權杖儲存在 HttpOnly Cookie 中，並將存取權杖保留在記憶體中。設定 HttpOnly 旗標，防止 JavaScript 存取 Cookie 內容。設定 Secure 旗標，確保只透過 HTTPS 連線傳輸。實作 SameSite 屬性以防範 CSRF。
• 實施短效存取權杖與權杖輪替: 根據風險承受度設定存取權杖的有效期限。每次使用重新整理權杖時，輪替機制都會產生新的重新整理權杖，以防止重放攻擊。使用 jti 宣告追蹤所有已核發的重新整理權杖，並在輪替成功後立即使先前的權杖失效。
• 嚴格執行簽章驗證: 明確拒絕標頭中指定 "alg: none" 的權杖。驗證簽章演算法是否符合預期類型，防止 RSA/HMAC 混淆攻擊。使用參數化查詢擷取金鑰，防止 SQL 注入。
• 部署權杖繫結: 設定條件式存取原則，透過整合可信任平台模組 (TPM) 或 Secure Enclave 強制執行權杖繫結，確保權杖無法在原核發裝置以外使用。
• 建立權杖撤銷機制: 使用 jti 宣告建立以資料庫為基礎的權杖家族追蹤機制。建立撤銷工作階段的管理介面，並部署「登出所有裝置」功能，讓使用者在懷疑帳戶遭入侵時撤銷所有工作階段。

即使落實這些最佳實務，手法高明的攻擊者仍會設法竊取權杖。當預防措施未能奏效，關鍵在於您能多快發現濫用行為，以及多快採取行動。

SentinelOne 如何偵測身分識別攻擊

Singularity™ Platform為您的端點、雲端工作負載與身分基礎架構提供自主偵測與回應。在 2024 年 MITRE ATT&CK Evaluations: Enterprise 中，SentinelOne 的偵測率達 100%，警示數量比所有受評廠商的中位數少 88%。這決定了分析師能否有效處理警示佇列，而不是只能放棄。 Purple AI™加速調查流程。分析師以自然語言提問，即可取得包含脈絡資訊的警示摘要，威脅獵捕速度最多提升 80%。

Singularity Identity保護 Active Directory 與 Entra ID，抵禦 身分威脅。其偵測功能直接針對攻擊這些環境的憑證攻擊，包括利用遭竊或偽造的 Kerberos 票證進行橫向移動與權限提升。 Storyline™技術隨攻擊進展重建攻擊過程，並關聯驗證事件與端點行為。您看到的是完整攻擊鏈，而非單一警示。觸發偵測時，自主回應會遏止威脅、隔離主機，並在 勒索軟體完成加密前，以 1-Click Rollback 復原損害。

向 SentinelOne 申請示範，了解身分威脅偵測如何在您的環境中運作。

Take the Tour

Get real-time identity protection and end-to-end visibility across hybrid environments to detect exposures, stop credential abuse, and reduce identity risk.

重點摘要

開頭提到的東京攻擊情境？當遭竊的權杖繞過驗證，卻完全不需使用密碼或觸發 MFA 提示時，就會發生這種情況。設定錯誤的權杖會造成實際風險，但權杖仍不可或缺。每種類型各有用途：JWT 用於無狀態微服務、OAuth 2.0 用於 API 授權、SAML 用於企業 SSO，FIDO2 則用於抗網路釣魚驗證。只要實作不慎，任何一種都可能成為攻擊途徑。

修正清單很短：將重新整理權杖儲存在 HttpOnly Cookie 中、將存取權杖保留在記憶體中、嚴格驗證簽章，並在每次重新整理時輪替權杖。本頁提到的多數失誤，都是因為漏做了其中一項。此外還有兩項容易延後建置：撤銷機制與金鑰管理。

導入 XDR與身分威脅偵測及回應 (ITDR)，讓落入他人手中的權杖觸發偵測，而不是六個月後才出現在稽核結果中。 CVE-2024-54150以及 MITRE ATT&CK 2024 年 10 月更新中追蹤的八個國家級攻擊組織，顯示權杖利用攻擊仍在發生。阻止這類攻擊的控制措施已經存在，現在就由您部署。