什麼是 WebAuthn？定義、範例與最佳實務

什麼是 WebAuthn？

密碼並不可靠。攻擊者會透過網路釣魚、憑證填充、密碼噴灑和資料外洩取得密碼。Verizon 的 2026 年資料外洩調查報告 (DBIR) 指出，所有資料外洩事件中有 39% 涉及憑證濫用，是其資料集中最普遍的單一攻擊手法。因此，防禦團隊優先採用能從登入流程移除密碼的控制措施。WebAuthn 正是 World Wide Web Consortium (W3C) 為此制定的標準。

WebAuthn 是 Web Authentication 的縮寫，也是一項 W3C 網路標準。它定義了瀏覽器 API，讓網路應用程式建立及使用以公開金鑰為基礎的高強度憑證來驗證使用者。WebAuthn 不交換密碼等共用機密，而是使用非對稱密碼學：驗證器會為每個網站產生一組專屬金鑰，將私密金鑰保存在安全硬體中，並只與伺服器分享公開金鑰。

W3C 規範正式將其定義為「一種 API，讓網路應用程式建立及使用高強度、經證明、限定使用範圍且以公開金鑰為基礎的憑證，以高強度驗證使用者」。實際上，您可以透過指紋掃描、臉部解鎖或實體安全金鑰登入網路應用程式，而伺服器不會收到任何可供攻擊者重複使用的資料。

WebAuthn 是 FIDO2 專案的核心組成部分，該專案與 Fast Identity Online (FIDO) Alliance 共同開發。FIDO2 結合 WebAuthn (瀏覽器 API 層) 與 CTAP (用戶端至驗證器通訊協定)。CTAP 負責透過 USB、近場通訊 (NFC) 或低功耗藍牙 (BLE)，處理驗證器裝置與瀏覽器之間的通訊。兩者共同奠定網路上無密碼及抗網路釣魚驗證的基礎。

兩起事件顯示密碼模式在大規模環境下的代價。2021 年，攻擊者透過一個原本不應繼續使用的舊版虛擬私人網路 (VPN) 設定檔入侵 Colonial Pipeline，該公司執行長曾向美國參議院表示。Colonial 關閉管線以控制攻擊，並向 DarkSide 的關聯組織支付 440 萬美元贖金。DarkSide 是CISA 公告所述的勒索軟體組織。美國司法部隨後扣押了其中 230 萬美元。根據2023 年 10 月提交的 8-K 文件，MGM Resorts 通報，2023 年一起從身分驗證流程社交工程攻擊開始的網路事件，造成估計 1 億美元的負面財務影響。兩起事件都涉及可重複使用的機密。WebAuthn 將其從登入流程中移除。

WebAuthn 與傳統驗證方式的比較

傳統驗證仰賴共用機密。密碼、一次性驗證碼和推播核准都會傳送攻擊者可即時攔截、重放或透過網路釣魚取得的資料。WebAuthn 以公開金鑰密碼學取代共用機密，私密金鑰不會離開驗證器硬體，也沒有可重複使用的資料透過網路傳輸。

這些差異在傳統方法失效之處尤其重要：

• 抗網路釣魚能力。 即時網路釣魚代理可擷取密碼和一次性密碼 (OTP) 驗證資料。WebAuthn 憑證透過密碼學與來源網域綁定，因此在 login.example.com 註冊的憑證無法用於 login-example.com 或任何其他仿冒網域的驗證。瀏覽器會在通訊協定層級強制執行此限制，不仰賴使用者判斷。
• 伺服器端資料暴露。 傳統系統儲存密碼雜湊值或共用機密，使其成為資料庫遭入侵時的高價值目標。WebAuthn 只儲存公開金鑰。即使伺服器完全遭到入侵，攻擊者也無法取得可用來冒充使用者的資料。
• 憑證重複使用。 使用者在不同服務重複使用密碼，使 憑證填充攻擊在大規模環境下奏效。WebAuthn 會為每個信賴方產生一組專屬金鑰，因此某項服務的憑證即使遭到入侵，在其他服務也毫無用處。
• 使用便利性與安全性的取捨。加長密碼及頻繁更換密碼，理論上能提升安全性，卻會降低使用便利性。WebAuthn 不必做此取捨：指紋掃描或臉部解鎖比任何密碼政策都能提供更高的驗證保證，同時減少使用者操作負擔。

整體而言，WebAuthn 消除了造成多數憑證相關資料外洩事件的三種途徑：網路釣魚、伺服器端竊取，以及跨網站重複使用。了解這些差異，就能進一步理解通訊協定的各個組成部分如何確保這些特性。

WebAuthn 的關鍵組成部分

WebAuthn 採用由 W3C 規範定義的三方架構。

驗證器： 這是產生金鑰組並簽署驗證聲明的密碼學實體。驗證器分為兩類：

• 平台驗證器內建於裝置的作業系統，例如 Windows Hello、Touch ID 和 Face ID。註冊過程幾乎沒有阻礙，但裝置遺失時，驗證器也會隨之遺失。
• 漫遊式 (跨平台) 驗證器是 YubiKeys 和 FIDO 安全金鑰等可攜式硬體裝置。它們可跨多部裝置使用，但需要實體配發及庫存管理。

無論選擇哪一類，安全模型都相同：驗證器會為每個信賴方建立一組專屬金鑰，私密金鑰絕不會離開驗證器的安全邊界。

信賴方 (RP)： 這是您的網路應用程式，包含呼叫 WebAuthn API 的用戶端 JavaScript，以及處理憑證儲存與驗證的伺服器端元件。RP 只儲存公開金鑰。RP ID 通常是您的網域名稱，作為來源綁定的密碼學依據。

使用者代理程式 (瀏覽器)： 瀏覽器負責協調驗證器與信賴方之間的所有互動。它會執行來源政策、防止憑證跨網域遭到濫用，並保護使用者隱私：在某個來源註冊的憑證無法用於其他來源。這正是 WebAuthn 能在協定層級阻止網路釣魚的原因。

WebAuthn 也定義了認證框架，讓驗證器在註冊時以密碼學方式證明其真實性。企業因此能確認憑證來自受信任、經 IT 核准的驗證器型號，而非來源不明或消費級裝置。 FIDO Metadata Service 為驗證器型號提供即時撤銷與安全公告機制。

釐清參與者與信任邊界後，就能梳理兩項流程，找出驗證可能失敗的確切環節。

WebAuthn 的運作方式

WebAuthn 定義兩項密碼學流程：註冊（建立憑證）與身分驗證（驗證斷言）。兩者都遵循挑戰回應協定。

1. 註冊（建立憑證）： 伺服器產生密碼學隨機挑戰，連同信賴方資訊、使用者帳戶詳細資料及可接受的密碼學演算法傳送給用戶端。用戶端呼叫 navigator.credentials.create()。驗證器請求使用者明確同意、產生新的非對稱金鑰組，並回傳認證物件，其中包含公開金鑰、已簽署的挑戰、憑證 ID，以及選用的認證憑證鏈。伺服器驗證認證物件與簽章，確認公開金鑰符合要求的演算法，並儲存憑證公開金鑰、憑證 ID 和簽章計數器。重要防護措施：即使參數完全相同，每次呼叫 navigator.credentials.create() 都會產生新憑證。您必須使用 excludeCredentials 參數，防止重複註冊。
2. 身分驗證（驗證斷言）： 伺服器產生新的挑戰，連同允許的憑證 ID 清單傳送給用戶端。用戶端呼叫 navigator.credentials.get()。驗證器依據您的政策確認使用者在場或驗證其身分，再以儲存的私密金鑰簽署挑戰。伺服器擷取儲存的公開金鑰、驗證斷言簽章、確認挑戰相符、檢查使用者在場與使用者驗證旗標、確認來源及 RP ID 相符，並驗證簽章計數器已遞增。

驗證簽章計數器是防範驗證器遭複製的措施。如果計數器未如預期遞增，就代表有憑證遭複製的證據。

若要符合 AAL2 規範，您必須強制執行使用者驗證（UV），而非只確認使用者在場（UP）。根據 可同步驗證器指引，驗證方必須表明優先採用 UV，並檢查回應，確認 UV 旗標已設定。

組織如何部署 WebAuthn

了解 WebAuthn 在實際環境中的應用，就能回答多數評估者真正關心的問題：它是否已在大規模環境中獲得驗證？

• Google 帳戶是最明確的參考指標。Google 於 2023 年 5 月開始推出通行金鑰，並於 2023 年 10 月 將其設為預設選項，供個人帳戶使用。推出不到一年，超過 4 億個帳戶使用通行金鑰 逾 10 億次。Google 並指出，通行金鑰的每日身分驗證使用次數，已超過簡訊一次性密碼與驗證器應用程式的總和。
• GitHub 指出 WebAuthn 是當時最強大的 2FA 選項。GitHub 在 2023 年強制所有貢獻者使用 2FA 時表示，實體安全金鑰以及 Windows Hello 和 Face ID 等平台驗證器，是最不容易受到網路釣魚攻擊的方法。
• 商業平台也陸續跟進： Amazon、PayPal、Shopify、DocuSign，以及將平均註冊與登入時間縮短 50% 的 Kayak，都已推出以 WebAuthn 為基礎的登入功能。這些部署證明，WebAuthn 能支援大規模消費者使用、處理復原流程，並整合至標準身分識別提供者架構。

了解這兩項流程及實際部署案例後，下一步就是決定哪一類驗證器適合您的環境。

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

WebAuthn 驗證器類型

驗證器的選擇，決定 WebAuthn 部署的安全保證等級、使用者體驗及營運負擔。每種類型都有不同取捨，企業規劃時必須納入考量。

1. 平台驗證器 內建於裝置的作業系統與硬體中。Windows Hello 使用受可信賴平台模組 (TPM) 保護的 PIN 碼、臉部辨識或指紋辨識。Apple 裝置使用由 Secure Enclave 支援的 Touch ID 或 Face ID。Android 裝置透過 Google Play Services 使用指紋或臉部解鎖。平台驗證器 1的註冊門檻最低，因為使用者已具備所需硬體，而且生物辨識驗證無須額外步驟，就能滿足 AAL2 合規所要求的使用者驗證 (UV)。限制在於憑證與裝置綁定。如果使用者遺失筆電或手機，除非使用同步通行金鑰，否則這些憑證也會隨之遺失。
2. 漫遊式（跨平台）驗證器是可攜式硬體權杖，例如 YubiKeys、Feitian BioPass 金鑰或其他 FIDO2 安全金鑰，透過 USB、NFC 或 BLE 連線。這類驗證器可跨裝置與作業系統使用，因此是特權存取、共用工作站環境及高保證等級使用情境的標準選擇。取捨在於配發作業：您需要採購、寄送、盤點及管理實體裝置，使用者也必須隨身攜帶。
3. 同步通行金鑰是較新的一種類型，WebAuthn 憑證會透過平台密碼管理工具（iCloud Keychain、Google Password Manager 或 1Password 等第三方管理工具）同步。同步的 通行金鑰 降低裝置遺失後的復原難度，因為憑證會保留在連結同一帳戶的任何裝置上。對多數企業使用者而言，這消除了採用 WebAuthn 的最大阻礙。取捨在於，驗證安全性如今部分取決於儲存同步憑證的平台帳戶是否安全。對安全保證要求較高的環境而言，綁定裝置的憑證搭配由 IT 管理的備用金鑰，仍是更安全的選擇。

多數企業部署會混合使用：日常使用平台驗證器，註冊可攜式安全金鑰作為備援，並在風險條件允許時使用同步通行金鑰。如何搭配，取決於安全保證要求、使用者組成，以及團隊能負擔多少營運管理工作。

驗證器的選擇直接影響可獲得的安全特性，下一節將說明這些特性。

WebAuthn 的安全效益

WebAuthn 在抵禦網路釣魚、降低伺服器端曝險、符合法規要求，以及防範跨網站攻擊方面，帶來具體的安全優勢：

• 在通訊協定層級抵禦網路釣魚. WebAuthn 以密碼學方式將憑證綁定至來源網站。這份 FIDO Alliance 對 NIST 的評論 警告，攻擊者已找到突破不具網路釣魚防護能力的 AAL2 驗證器的方法。WebAuthn 彌補了這項缺口。
• 伺服器上沒有共用祕密.FIDO2 的公開金鑰密碼學模型，無須在身分識別提供者與驗證器之間共用祕密。這正是 NIST SP 800-63B-4 所稱的驗證方遭入侵抵抗能力。即使整個資料庫遭到外洩，攻擊者也無法取得可重放的資料。
• 符合法規要求. WebAuthn 符合 NIST SP 800-63B-4 AAL2 的網路釣魚抵禦要求。美國政府管理及預算局 (OMB) 備忘錄 M-22-09 直接將 W3C Web Authentication 標準列為聯邦機構抵禦網路釣魚的方法。受監管組織因此有明確且可稽核的合規途徑。
• 消除人為因素攻擊. 根據 2026 Verizon DBIR   ，人為因素涉及 62% 的資料外洩事件。WebAuthn 消除兩種關鍵的人為攻擊途徑：弱密碼選擇，以及容易受網路釣魚影響的弱點。沒有密碼，使用者就無法選擇不安全的密碼。
• 防範跨網站憑證填充攻擊. 每組憑證都以密碼學方式限定用於特定網域，使 憑證填充攻擊在不同服務間的成效大幅降低。

這些安全特性並非紙上談兵。大規模部署 WebAuthn 的組織，已在正式環境中驗證其成效，應用案例也涵蓋幾乎所有產業。

常見的 WebAuthn 應用案例

WebAuthn 的採用主要集中在憑證攻擊會造成重大業務影響的情境。以下是正式環境中最常見的部署模式。

• 特權存取與管理主控台. VPN 入口網站、雲端管理主控台及基礎架構管理面板，是憑證竊取最有價值的目標。在這些存取點強制使用 WebAuthn 作為第二驗證因素，或將其設為主要的無密碼驗證方式，就能消除網路釣魚工具套件與外洩憑證最常利用的攻擊途徑。這通常是企業導入的第一階段。
• 金融服務與醫療保健的客戶登入. 在憑證遭入侵會引發資料外洩通報、監管處罰及直接財務損失的受監管產業，業者正採用通行金鑰進行客戶驗證。銀行應用程式、病患入口網站及保險平台使用 WebAuthn，同時滿足合規要求（PCI DSS、HIPAA 存取控制），並達成減少帳戶接管詐欺的營運目標。
• 共用工作站與自助服務終端環境. 醫院、製造現場及零售業使用共用終端機。以密碼登入不僅緩慢，也容易遭到旁人偷窺。可攜式驗證器（支援 NFC 的安全金鑰或感應識別證驗證方式）讓使用者在數秒內完成驗證，無須在共用裝置上輸入憑證。
• 員工單一登入 (SSO). 透過 Okta、Azure AD 或 Ping Identity 等平台，在身分識別提供者 (IdP)層級部署 WebAuthn，只需註冊一次，即可保護聯合身分驗證環境中的所有下游應用程式。這是擴大涵蓋範圍最有效率的途徑，因為只須在 IdP 部署一次 WebAuthn，每個使用 Security Assertion Markup Language (SAML) 或 OpenID Connect (OIDC) 的信賴方就都能獲得抵禦網路釣魚的驗證能力。

這些應用案例都印證同一項原則：驗證流程越能排除可重複使用的祕密，留下的憑證攻擊途徑就越少。不過，大規模部署 WebAuthn 也會帶來團隊必須預先規劃的營運複雜性。

WebAuthn 的挑戰與限制

WebAuthn 的安全模型十分可靠，但企業部署會帶來團隊一再低估的營運複雜性：

• 憑證生命週期管理. 企業部署 WebAuthn 時，主要的失敗原因在於營運，而非密碼學。您需要為驗證器發放、裝置遺失後的憑證撤銷、更新政策，以及驗證失敗時的使用者支援，制定書面流程。這份 FIDO 生命週期指南詳細說明了註冊、復原及撤銷階段。
• 驗證器類型選擇. 您面臨一項策略性抉擇：平台驗證器（無須配發成本，但會隨裝置遺失）、漫遊驗證器（可攜帶，但需要實體配發），或混合方式。每種方式的驗證強度、復原需求與維運負擔都不同。
• 舊版應用程式整合。 您環境中的應用程式並非全都原生支援 WebAuthn。您需要處理與 SAML、OAuth 和 OpenID Connect 等聯合身分識別協定的整合。對身分識別聯合架構複雜的組織而言，這是一項重大挑戰。
• FIDO 伺服器架構決策。 您必須選擇將 FIDO 伺服器整合至現有的身分識別提供者、部署獨立的 FIDO 伺服器，或採用 FIDO 伺服器即服務模式。每種選擇都會影響憑證儲存架構、災難復原程序與部署範圍。這份 FIDO 伺服器部署指南詳細說明各項取捨。
• 同步憑證的取捨。 透過主流平台的密碼管理工具同步通行金鑰，可大幅減少使用者的操作阻礙，但也讓驗證安全性部分取決於平台帳戶的安全性。對驗證強度要求最高的情境，採用綁定裝置的憑證，並搭配由 IT 管理的備用金鑰，仍是更穩妥的選擇。

除了維運複雜度，特定的實作決策也會帶來更持久的風險：

• 將所有 MFA 都視為具備抗網路釣魚能力。 這是影響最嚴重的錯誤。部署 TOTP、SMS OTP 或 推播通知 MFA，卻宣稱符合抗網路釣魚要求，會讓您暴露於風險中。即時網路釣魚代理可擷取並重放這些方式中的兩項驗證因素。只有採用驗證者名稱繫結或通道繫結的 WebAuthn，才能真正抵禦網路釣魚。
• 允許未經驗證就註冊憑證。 CVE-2021-3632揭示了 Keycloak 中的這項問題：當使用者帳戶尚未註冊裝置時，任何人都能註冊新的安全裝置。註冊必須在已通過驗證的工作階段中進行，或透過經過驗證的頻外流程完成。
• 註冊流程設計不佳。繁瑣的註冊流程會引起使用者抗拒，並增加支援工單量。您的註冊入口網站應引導使用者在已通過驗證的工作階段中完成註冊，清楚說明可接受的驗證器，並解釋特定裝置遭拒的原因。
• 缺少備援與復原機制。部署 WebAuthn 時，若未針對裝置遺失、硬體故障或生物辨識問題制定備援程序，就可能導致使用者無法登入。您需要預先註冊備用驗證器、備妥由 IT 管理員提供的緊急存取碼，並建立當面身分驗證流程。
• 將 WebAuthn 與現有安全架構分開部署。 WebAuthn 無法單獨解決問題。根據 NIST SP 1800-35，WebAuthn 應整合持續驗證評估、裝置健康狀態驗證、情境感知存取政策，以及端點安全基礎架構。在 零信任架構中，WebAuthn 能成為存取決策最有力的判斷訊號之一。

妥善規劃就能克服這些挑戰。以下實務涵蓋關鍵決策，讓部署不只停留在概念驗證階段，而能正式上線。

實作 WebAuthn 的最佳實務

以下實務涵蓋關鍵決策，讓 WebAuthn 部署不只停留在概念驗證階段，而能正式上線。

針對 AAL2 強制執行使用者驗證。 在註冊與驗證流程中，將 userVerification: "required" 設定為指定值，並在伺服器端驗證 UV 旗標。對於須符合合規要求的部署，不要依賴 "preferred"。

運用認證聲明強制執行驗證器政策。在註冊期間檢查認證聲明，只允許符合安全要求的驗證器（例如取得 FIDO L1+ 認證）。使用以 AAGUID（驗證器型號識別碼）為基礎的允許清單，並整合 FIDO Metadata Service，即時檢查驗證器狀態。

分階段部署。 FIDO 分階段推行建議採取以下步驟：

1. 針對高風險應用程式（VPN、特殊權限存取、管理主控台）導入 WebAuthn 作為第二項驗證因素
2. 在建立維運支援能力的同時，於整個平台推行第二項驗證因素
3. 針對已熟悉驗證流程的使用者，導入可探索憑證與無密碼驗證流程
4. 針對已註冊的使用者全面採用無密碼驗證，並停用舊版驗證方式

採用這種方式，您可以在將 WebAuthn 設為預設方式前，先驗證政策、支援及復原流程。

實施多驗證器復原策略。每位使用者至少註冊兩個驗證器：一個主要驗證器（例如供日常使用的平台驗證器），以及一個備用驗證器（例如妥善保管的安全金鑰）。在使用者帳戶設定中，清楚顯示已註冊的復原憑證。

驗證簽章計數器。 確認簽章計數器在每次驗證時都會遞增。計數器若未遞增，表示驗證器可能遭到複製。

區分預期與非預期錯誤。明確追蹤 WebAuthn 錯誤。將 NotAllowedError, AbortError 和 Credential Manager 通行金鑰錯誤分別歸類為不同訊號，以區分使用者操作障礙與安全異常。

遵循這些做法，就能讓 WebAuthn 部署達到正式環境的就緒狀態。但即使 WebAuthn 部署設定正確，也無法構成完整的身分防護。完全繞過 WebAuthn 的攻擊，需要在登入流程之外運作的防護措施：工作階段劫持、驗證後的橫向移動，以及服務台社交工程攻擊。

SentinelOne 如何強化身分安全

WebAuthn 可減少憑證重放，但無法阻止正式環境中的所有身分攻擊。您仍須應對工作階段權杖遭竊、裝置遭入侵、服務台社交工程攻擊，以及驗證後的橫向移動。

Singularity™ Platform 透過關聯身分與端點資訊，彌補這項防護缺口：

• Singularity Identity 偵測可疑的身分活動，並在攻擊者鎖定目錄服務和 SSO 工作流程時採取應對措施。它涵蓋 WebAuthn 未觸及的身分基礎架構。
• Singularity Endpoint 在裝置上執行行為式與靜態 AI 模型，阻止竊取憑證的惡意軟體，以及完全繞過登入控制的手動攻擊活動。它無須人工介入，就能即時標記惡意模式。當攻擊者鎖定工作階段而非密碼時，這一點尤其重要。
• Purple AI™ 綜合分析您的安全資料，引導調查並建議後續行動。一份 2025 年 IDC Snapshot 指出，客戶識別威脅的速度提升了 63%。當您需要判斷 WebAuthn 登入失敗是使用者操作障礙，還是正在進行的網路釣魚攻擊時，速度至關重要。

三者共同防守登入前後的身分攻擊路徑。

若將 WebAuthn 視為更廣泛的 網路釣魚防禦計畫與事件應變工作流程中的一項強力訊號，您就能降低帳戶遭接管的風險，並縮短釐清事件經過所需的時間。

預約產品展示，了解 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.

重點摘要

WebAuthn 是 W3C 制定的網頁驗證標準，運用公開金鑰密碼學，實現無密碼且能抵禦網路釣魚的驗證方式。它以密碼學方式將憑證綁定至特定網域，從架構上杜絕憑證重放。 

企業要成功部署，必須分階段推行、依據驗證器證明制定政策、規劃多裝置復原策略，並與更廣泛的安全技術架構整合。