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

什麼是 WebAuthn？

密碼會失效。它們會遭到網路釣魚、憑證填充、密碼噴灑與外洩。Verizon 的 2026 Data Breach Investigations Report (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（Client to Authenticator Protocol）配對，後者負責透過 USB、近場通訊 (NFC) 或 Bluetooth Low Energy (BLE) 處理您的驗證器裝置與瀏覽器之間的通訊。兩者共同構成網頁上無密碼且可抵禦網路釣魚驗證的基礎。

兩起事件顯示了密碼模型在大規模情境下的代價。2021 年，攻擊者透過一個原本不應使用的舊版虛擬私人網路 (VPN) 設定檔入侵 Colonial Pipeline，正如該公司執行長向 美國參議院表示。Colonial 為了遏止攻擊而關閉管線，並向 DarkSide 關聯方支付了 440 萬美元贖金，該勒索軟體行動已收錄於 CISA 公告。之後，Department of Justice 查扣了其中 230 萬美元。2023 年，MGM Resorts 在一份 2023 年 10 月 8-K 中指出，一起始於針對身分識別流程的社交工程網路事件，估計造成 1 億美元的負面財務影響。這兩起事件都與可重複使用的秘密有關。WebAuthn 會將其從登入流程中移除。

WebAuthn 與傳統驗證的比較

傳統驗證依賴共享秘密。密碼、一次性代碼與推播核准都會傳輸攻擊者可即時攔截、重放或透過網路釣魚取得的資料。WebAuthn 透過以公開金鑰 密碼學 取代共享秘密來改變此模型，其中私密金鑰永遠不會離開您的驗證器硬體，且不會有任何可重複使用的內容穿越網路。

這些差異在傳統方法失效的環節最為重要：

• 可抵禦網路釣魚。 以密碼和 OTP 為基礎的驗證可被即時網路釣魚代理擷取。WebAuthn 憑證會以密碼學方式綁定至來源網域，因此在 login.example.com 註冊的憑證，無法對 login-example.com 或任何其他仿冒網域進行驗證。瀏覽器會在通訊協定層級強制執行此機制，且不依賴使用者判斷。
• 伺服器端暴露。 傳統系統會儲存密碼雜湊或共享秘密，這些內容在資料庫外洩事件中會成為高價值目標。WebAuthn 只儲存公開金鑰。即使伺服器遭到完全入侵，攻擊者也無法取得任何可用來冒充使用者的內容。
• 憑證重複使用。 使用者會在不同服務間重複使用密碼，這使得 credential stuffing 能夠大規模奏效。WebAuthn 會為每個依賴方產生唯一的金鑰對，因此某一服務中遭到入侵的憑證，在另一服務中完全沒有價值。
• 使用者摩擦與安全性的權衡。較長的密碼與頻繁輪替在理論上可提升安全性，但會降低可用性。WebAuthn 消除了這種權衡：指紋掃描或臉部解鎖提供的驗證保證，比任何密碼政策都更強，同時對使用者造成更少摩擦。

整體效果是，WebAuthn 消除了造成大多數以憑證為基礎之資料外洩的三個向量：網路釣魚、伺服器端竊取，以及跨網站重複使用。理解這些差異，有助於為了解通訊協定元件如何強制實現這些特性奠定基礎。

WebAuthn 的關鍵元件

WebAuthn 採用由 W3C 規格 定義的三方架構運作。

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

• 平台驗證器 內建於您裝置的作業系統中：Windows Hello、Touch ID、Face ID。它們幾乎可在無摩擦情況下完成註冊，但若裝置遺失，也會一併遺失。
• 漫遊（跨平台）驗證器 是可攜式硬體裝置，例如 YubiKeys 和 FIDO 安全金鑰。它們可跨多個裝置運作，但需要實體發放與庫存管理。

無論您選擇哪種類型，安全模型都相同：驗證器會為每個依賴方建立唯一的金鑰對，而私密金鑰永遠不會離開驗證器的安全邊界。

依賴方 (RP)：這就是您的網頁應用程式：呼叫 WebAuthn API 的用戶端 JavaScript，加上處理憑證儲存與驗證的伺服器端元件。RP 只儲存公開金鑰。RP ID（通常是您的網域名稱）可作為來源綁定的密碼學錨點。

使用者代理（瀏覽器）： 瀏覽器會協調驗證器與依賴方之間的所有互動。它會強制執行來源政策、防止憑證在不同網域間遭到濫用，並保護使用者隱私：在某一來源註冊的憑證無法被另一個來源使用，這正是從通訊協定層級阻止網路釣魚的機制。

WebAuthn 也定義了一個證明框架，讓驗證器可在註冊期間以密碼學方式證明其真實性。接著，您的企業便可驗證憑證是否來自受信任且經 IT 核准的驗證器型號，而非未知或消費級裝置。The FIDO Metadata Service 提供驗證器型號的即時撤銷與公告機制。

一旦您了解參與者與信任邊界，就能對應這兩個儀式，並精確看出驗證可能在哪些地方失敗。

WebAuthn 的運作方式

WebAuthn 定義了兩種密碼學儀式：註冊（建立憑證）與驗證（驗證聲明）。兩者都遵循挑戰回應通訊協定。

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

簽章計數器驗證是您防禦遭複製驗證器的機制。如果計數器未如預期遞增，便表示有憑證遭到複製的證據。

若要符合 AAL2，您必須強制執行 User Verification (UV)，而不只是 User Presence (UP)。根據 syncable authenticators guidance，驗證方必須指出偏好 UV，並檢查回應以確認 UV 旗標已設定。

組織如何部署 WebAuthn

了解 WebAuthn 在正式環境中的運作位置，就能回答多數評估者真正會問的問題：這是否已在大規模環境中獲得驗證？

• Google Accounts 是最明確的基準。Google 於 2023 年 5 月開始推出 passkeys，並於 made them the default 在 2023 年 10 月將其設為個人帳戶的預設選項。自推出後一年內，passkeys 已在超過 4 億個帳戶中被使用 over one billion times，且 Google 表示，passkeys 在日常基礎上的驗證使用頻率，已高於 SMS OTP 與驗證器應用程式的總和。
• GitHub 將 WebAuthn 視為 可用的最強 2FA 選項，並在其 mandated 2FA in 2023 要求所有貢獻者於 2023 年採用 2FA 時指出，實體安全金鑰與 Windows Hello、Face ID 等平台驗證器，是最不易受到網路釣魚影響的方法。
• 商業平台也已跟進： Amazon、PayPal、Shopify、DocuSign 與 Kayak，這些平台cut average sign-up and sign-in time by 50%，都已推出以 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 使用由 Trusted Platform Module (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. 同步 passkeys 是較新的類別，其中 WebAuthn 憑證會透過平台密碼管理器（iCloud Keychain、Google Password Manager，或像 1Password 這類第三方管理器）進行同步。同步的 passkeys 可降低裝置遺失後的復原問題，因為憑證可在連線至同一帳戶的任何裝置上存續。對大多數企業使用者而言，這消除了 WebAuthn 採用上的最大摩擦點。權衡之處在於，您的驗證安全性現在部分取決於託管同步憑證之平台帳戶的安全性。對於高保證環境而言，具裝置綁定的憑證搭配由 IT 管理的備份金鑰，仍是更強的選擇。

大多數企業部署會採用組合方式：以平台驗證器作為日常使用、以漫遊金鑰作為已註冊的備援，並在風險概況允許時使用同步 passkeys。選擇正確的組合取決於您的保證需求、使用者族群，以及您能承受多少營運負擔。

驗證器的決策會直接影響您獲得的安全屬性，這正是下一節要說明的內容。

WebAuthn 的安全優勢

WebAuthn 在抗網路釣魚、伺服器端暴露、法規遵循，以及跨網站攻擊防護方面，提供了具體的安全優勢：

• 通訊協定層級的抗網路釣魚能力。 WebAuthn 會以密碼學方式將憑證綁定至來源。該 FIDO Alliance NIST comment 警告，攻擊者已經追上不具抗網路釣魚能力的 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 消除了兩個關鍵的人為攻擊面：弱密碼 選擇以及易受網路釣魚影響。當沒有密碼時，使用者就無法選擇糟糕的密碼。
• 防止跨網站憑證填充。每個憑證都以密碼學方式限定於特定網域，使 credential stuffing 在跨服務攻擊時的效果大幅降低。

這些安全屬性並非理論。已大規模部署 WebAuthn 的組織，早已在正式環境中驗證了這些優勢，而且其使用案例幾乎涵蓋所有產業垂直領域。

常見的 WebAuthn 使用案例

WebAuthn 的採用集中於憑證型攻擊會帶來最高業務衝擊的情境。這些是在正式環境中最常見的部署模式。

• 特權存取與管理主控台。VPN 入口網站、雲端管理主控台，以及基礎架構管理面板，都是 credential theft 的高價值目標。將 WebAuthn 部署為這些存取點的必要第二因素，或作為主要的無密碼方法，可移除網路釣魚工具包與憑證傾印最積極利用的攻擊面。這通常是任何企業推行中的第一階段。
• 金融服務與醫療保健的客戶端登入。 在受監管產業中，憑證遭入侵會觸發外洩通報、監管罰則，以及直接財務損失，因此正採用 passkeys 進行客戶驗證。銀行應用程式、病患入口網站，以及保險平台使用 WebAuthn，以同時滿足合規要求（PCI DSS、HIPAA 存取控制）與降低帳戶接管詐欺的營運目標。
• 共用工作站與資訊站環境。 醫院、製造現場，以及零售營運會使用共用終端機，而基於密碼的登入速度慢，且容易遭到肩窺。漫遊驗證器（支援 NFC 的安全金鑰或感應證章解決方案）可在數秒內完成使用者驗證，且無需在共用裝置上輸入任何憑證。
• 員工單一登入（SSO）。 在 identity provider (IdP) 層級透過 Okta、Azure AD 或 Ping Identity 等平台部署 WebAuthn，可透過單次註冊保護聯合式環境中的每個下游應用程式。這是達成廣泛涵蓋範圍最有效率的途徑，因為您只需在 IdP 部署一次 WebAuthn，而每個 Security Assertion Markup Language (SAML) 或 OpenID Connect (OIDC) 依賴方都會繼承這種抗網路釣魚驗證能力。

這些使用案例都強化了同一項原則：您越接近從驗證流程中消除可重複使用的秘密，保留下來的憑證型攻擊路徑就越少。話雖如此，大規模部署 WebAuthn 會帶來團隊需要事先規劃的營運複雜性。

WebAuthn 的挑戰與限制

WebAuthn 的安全模型是健全的，但企業部署會浮現團隊一再低估的營運複雜性：

• 憑證生命週期管理。 企業 WebAuthn 部署中的主要失敗模式是營運層面，而非密碼學層面。您需要針對驗證器發放、裝置遺失時的憑證撤銷、更新政策，以及驗證失敗時的使用者支援，建立文件化流程。該 FIDO lifecycle guidance 詳細涵蓋了註冊、復原與撤銷階段。
• 驗證器類型選擇。 您面臨平台驗證器（零配送成本，但會隨裝置遺失）、漫遊驗證器（可攜但需要實體配送），以及混合式方法之間的策略性決策。每種方式都具有不同的保證等級、復原需求與營運負擔。
• 舊版應用程式整合。 您環境中的並非每個應用程式都原生支援 WebAuthn。您需要處理與 SAML、OAuth 和 OpenID Connect 等同盟通訊協定的整合。對於具有複雜身分同盟拓撲的組織而言，這是一項重大挑戰。
• FIDO 伺服器架構決策。 您必須在將 FIDO 伺服器整合至現有身分提供者、部署獨立的 FIDO 伺服器，或使用 FIDO-server-as-a-service 模式之間做出選擇。每種選擇都會影響認證儲存架構、災難復原程序與部署範圍。這份 FIDO 伺服器部署指南詳細說明了其中的權衡取捨。
• 同步認證的權衡取捨。 透過主要平台密碼管理器進行 Passkey 同步，可大幅降低使用者摩擦，但也會將部分驗證安全性轉移到平台帳戶本身的安全性上。在保證需求最高的情況下，具備 IT 管理備援金鑰的裝置綁定認證仍是更強的選擇。

除了營運複雜性之外，特定的實作決策還會造成更持久的暴露面：

• 將所有 MFA 都視為具備抗網路釣魚能力。 這是影響最大的錯誤。部署 TOTP、SMS OTP 或 推播通知 MFA，並宣稱符合抗網路釣魚要求，會讓您暴露於風險之中。即時網路釣魚代理可在這些方法中擷取並重放兩個因素。只有具備驗證者名稱繫結或通道繫結的 WebAuthn，才能實現真正的抗網路釣魚能力。
• 允許未經驗證的認證註冊。 CVE-2021-3632 在 Keycloak 中證明了這一點：當使用者帳戶尚無任何裝置時，任何人都可以註冊新的安全裝置。註冊必須在已完成驗證的工作階段內進行，或透過經驗證的帶外程序進行。
• 不良的註冊流程設計。笨拙的註冊流程會造成使用者抗拒，並推高支援工單量。您的註冊入口網站應引導使用者在已驗證的工作階段內完成註冊，清楚說明可接受的驗證器，並解釋為何特定裝置遭到拒絕。
• 缺少備援與復原機制。在未記錄裝置遺失、硬體故障或生物辨識問題之備援程序的情況下部署 WebAuthn，會造成帳戶鎖定情境。您需要預先註冊的備援驗證器、IT 管理員緊急存取碼，以及現場身分驗證流程。
• 將 WebAuthn 與您的安全性堆疊隔離部署。 WebAuthn 並非獨立的修正措施。根據 NIST SP 1800-35，它應與持續驗證評估、裝置健康狀態驗證、情境感知存取原則，以及您的端點安全基礎架構整合。在 零信任架構中，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 passkey 錯誤作為不同訊號分類，以便區分使用者摩擦與安全異常。

遵循這些做法可讓您的 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 的無密碼、可抵禦網路釣魚的 Web 驗證標準，採用公開金鑰密碼學。它會以密碼學方式將憑證綁定至特定網域，使憑證重放在架構上成為不可能。 

成功的企業部署需要分階段推行、以證明為基礎的驗證器政策、多裝置復原策略，以及與您更廣泛安全堆疊的整合。