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

什麼是驗證權杖？

試想這種情況：您在紐約上午 9 點登入企業應用程式。三十分鐘後，有人從東京存取您的帳戶。您的密碼從未變更。您的多重要素驗證 (MFA) 權杖還放在桌上。但攻擊者剛剛使用遭竊的驗證權杖，直接穿過您的前門。

驗證權杖是在企業系統間驗證您身分的數位識別證。它們是密碼學憑證，因此您的密碼不會隨請求一同傳送。根據 NIST Special Publication 800-63B-4，這些權杖構成現代資安架構中數位身分保證的基礎。

上述情境並非假設。2023 年，一個威脅行為者從上傳到 Okta's customer support system 的支援檔案中擷取工作階段權杖，並利用這些權杖劫持五名客戶的有效工作階段。沒有任何密碼被破解。沒有任何 MFA 提示被回應。系統收到有效權杖後，就完全照其設計執行。

了解權杖如何運作、會在哪裡失效，以及如何保護它們，正是區分能夠守住的驗證基礎架構與把鑰匙交給攻擊者的基礎架構的關鍵。本頁將逐一說明這三者。

為何驗證權杖是安全目標

權杖位於您的身分安全與 存取控制架構的交會點。當您向任何系統進行驗證時，您不會在每次請求時都攜帶實際憑證。相反地，您會收到一個權杖，表示「此人已經證明其身分」。

一旦權杖遭竊，攻擊者就能完全繞過驗證。若能偽造權杖，他們就能冒充合法使用者。若能操弄權杖的驗證方式，他們甚至無須持有授權帳戶就能提升權限。

這方面出錯的代價已有充分記錄。 IBM's 2026 Cost of a Data Breach Report 指出，全球平均資料外洩成本達 499 萬美元，創下歷史新高。 Verizon's 2026 Data Breach Investigations Report (DBIR) 發現，在該報告 19 年歷史中，漏洞利用首次超越遭竊憑證，成為資料外洩的首要入侵途徑。憑證一直占據該位置直到今年，而遭竊權杖就是已經通過前門的憑證。

要理解這些風險，安全團隊必須先辨識組織部署的不同權杖類型，以及每種類型如何帶來獨特的安全考量。

驗證權杖的類型

組織會根據其安全需求與使用案例部署不同類型的權杖。

• JSON Web Tokens (JWTs)： 採用標頭-承載-簽章結構、內含編碼宣告的自包含權杖。JWT 可實現無狀態驗證，讓伺服器無須查詢資料庫即可驗證權杖，因此非常適合分散式微服務架構。
• OAuth 2.0 Tokens: OAuth 架構使用兩種協同運作的權杖類型。存取權杖為 API 呼叫提供短時效憑證，而重新整理權杖則可在無須重新驗證的情況下取得新的存取權杖。這種分離可限制權杖遭竊所造成的損害。
• SAML (Security Assertion Markup Language) Assertions: 在身分提供者與服務提供者之間交換、以 XML 為基礎的權杖，用於企業單一登入。SAML 在傳統企業環境與 B2B 同盟情境中仍占主導地位。
• Session Tokens: 由伺服器產生、將瀏覽器連結至伺服器端工作階段狀態的識別碼。與無狀態 JWT 不同，工作階段權杖需要伺服器儲存，但可提供立即撤銷的能力。
• FIDO2/Hardware Tokens: 透過 WebAuthn API 使用公開金鑰密碼學的實體驗證器。這些權杖透過密碼學來源繫結提供抗網路釣魚能力，確保憑證只能在合法網站上運作。

雖然每種權杖類型的用途不同，但它們共享決定其安全態勢的共同架構元素。而這些元件正是強化防護的起點。

驗證權杖的核心元件

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

1. 權杖結構： JWT 由三個部分組成：標頭（指定 RS256 或 ES256 等簽章演算法）、承載（包含宣告）以及簽章（確保密碼學完整性）。SAML 判斷提示使用符合 OASIS SAML V2.0 規範的 XML 格式陳述式。
2. 權杖中繼資料： 權杖會在其承載中攜帶中繼資料。到期時間戳記（exp 宣告）定義有效期間，簽發時間宣告（iat）建立權杖年齡，JWT ID（jti）提供用於撤銷追蹤的唯一識別碼，而受眾限制（aud 宣告）可防止權杖在不同服務間重複使用。
3. 工作階段熵： Web 應用程式工作階段權杖需要 最低熵，並透過密碼學安全的偽隨機數產生器 (CSPRNG) 產生。
4. 硬體權杖密碼學： FIDO2 權杖結合 WebAuthn 瀏覽器 API 與 Client to Authenticator Protocol (CTAP)。私密金鑰絕不會離開安全元件，而密碼學來源繫結可確保憑證只能在合法網站上運作。

這些元件會組合成工作流程，而工作流程正是權杖安全成敗的關鍵。以下各節將追蹤每個流程，包括權杖如何與 多重要素驗證.

驗證權杖的運作方式

驗證權杖會依據類型與部署情境遵循不同的工作流程。

• JWT 驗證流程： 您將認證資料提交至驗證伺服器。伺服器會驗證認證資料、產生並以密碼學方式簽署包含到期時間、受眾與簽發者宣告的 JWT，然後將其傳回您的用戶端。對於後續請求，您會在 Authorization 標頭中包含 JWT。資源伺服器會先驗證簽章並確認宣告，然後才授予存取權。
• OAuth 2.0 授權碼流程： 您請求存取受保護資源。完成驗證與同意後，伺服器會簽發授權碼，供您的應用程式交換存取權杖與重新整理權杖。您會使用短效的存取權杖進行 API 呼叫，並在需要時以重新整理權杖交換新的存取權杖。
• SAML Web Browser 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 實作中使用的 Primary Refresh Tokens (PRTs) 一旦遭入侵，問題尤其嚴重。若沒有撤銷機制，組織便無法即時終止遭入侵的工作階段，只能依賴權杖自然到期。
• 不安全的金鑰管理： 金鑰管理失敗會造成系統性弱點。 SQL injection 在金鑰擷取機制中的弱點，當應用程式使用易受攻擊的 SQL 查詢透過 kid 參數擷取 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 injection。
• 部署權杖繫結： 設定 Conditional Access 原則以強制執行權杖繫結，透過 Trusted Platform Module (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 用於抗網路釣魚驗證。只要實作不夠謹慎，它們每一種都會成為攻擊向量。

修補清單很短。將 refresh token 儲存在 HttpOnly cookie 中、將 access token 保留於記憶體中、嚴格驗證簽章，並在每次重新整理時輪替。此頁面上的大多數失敗案例，都是因為其中一項未完成，再加上另外兩項比起建置更容易被延後的工作：撤銷基礎架構與金鑰管理。

加入 XDR 與身分威脅偵測與回應 (ITDR)，讓落入錯誤之手的權杖會浮現為偵測事件，而不是六個月後才在稽核中被發現。 CVE-2024-54150 與在 MITRE ATT&CK's October 2024 update 中追蹤的八個國家級威脅組織顯示，權杖利用是當前且持續活躍的攻擊手法。阻止這類攻擊的控制措施早已存在，而部署它們取決於您。