發布日期：2026 年 5 月 21 日
在 2026 年 Google I/O 大會上，我們談到登入不再是件麻煩事。這個入口點應安全無虞且簡化，讓使用者感到安心。這篇文章將回顧如何修正帳戶流程、減少阻力，以及從一開始就保護使用者。
快速存取
現代化的重要性
高摩擦流程 (例如雜亂的註冊表單、惱人的「忘記密碼」迴圈，或一連串的登入按鈕) 會破壞氣氛。這類廣告是「情境切換殺手」，會趕走使用者。傳統密碼和動態密碼也容易遭到網路釣魚攻擊。
每增加一秒的摩擦，使用者就可能流失。採用現代化驗證機制，可保護系統和使用者。只要在身分識別流程中，讓每個接觸點都順暢無阻，轉換率自然就會提高。舉例來說，pixiv 導入密碼金鑰後，登入成功率高達 99% (比使用密碼時提升 29%)。改用安全性較高的憑證，可加快速度並提升安全性。
簡化帳戶建立流程
使用者與應用程式的第一次互動會決定整體氛圍。簡化帳戶建立流程是提升採用率和安全性的第一步。
以身分同盟做為主要帳戶建立方法
您可以透過身分同盟，讓使用者略過繁瑣的帳戶建立表單，改用 Google 等信任的供應商註冊。這項功能可提供簡潔有力的註冊體驗，讓使用者不必經歷一般註冊程序，就能直接進入應用程式。
同盟功能可讓使用者不必手動輸入名稱或電子郵件地址，由於提供者已驗證這些使用者，您可以略過多餘的獨立驗證步驟，吸引更多人加入。
此外，採用聯合身分識別解決方案後，您就能沿用專屬 IdP (身分識別提供者) 的安全等級。由於身分識別提供者專門處理身分和安全性事宜，因此採用其基礎架構可避免從頭建構驗證機制所帶來的風險。
採用 Federated Credential Management (FedCM) API
如果您是 IdP，建議採用 FedCM API。這項功能會透過瀏覽器 UI 處理互動，防止追蹤行為來保護隱私，同時讓使用者輕觸一下即可登入，並只顯示相關帳戶，簡化 UI。
「先聯合再升級」模式
先連結再升級的做法，結合了連結的快速性與密碼金鑰的長期安全性。如果您在聯合註冊後立即提示使用者建立密碼金鑰，使用者下次登入時，就能享有防網路釣魚的保護。
針對自動填入功能最佳化表單
如有必要使用手動表單，請使用說明性 name 和 id 屬性，以及正確的 autocomplete 值，讓瀏覽器為使用者填寫欄位。這樣做可以減輕認知負擔，並降低註冊程序中發生錯別字的機率。如要進一步瞭解如何最佳化表單，請參閱註冊表單最佳做法。
<label for="email">Email</label>
<input type="email" id="email" name="email" autocomplete="email">
<label for="password">New Password</label>
<input type="password" id="password" name="password" autocomplete="new-password">
順暢無礙的屬性驗證
如果使用者必須離開應用程式才能查看電子郵件中的驗證碼，轉換率就會降低。使用者會因為切換情境而分心，再也不會回來。
符合電子郵件驗證通訊協定 (EVP)
電子郵件驗證通訊協定 (EVP) 是新興功能，可讓應用程式直接透過瀏覽器取得已驗證的電子郵件地址。
如要啟用這項功能，請附加具有 autocomplete="email-verification-token" 屬性和 challenge 的隱藏輸入欄位。瀏覽器會從輸入內容剖析電子郵件網域，並要求電子郵件發行者驗證使用者是否擁有該電子郵件的控制權。驗證成功後，瀏覽器會顯示已驗證的電子郵件聲明，後端可立即驗證。對使用者而言，這個流程是無縫接軌的；他們只會在電子郵件驗證後看到通知。
EVP 可免除登入、註冊和重設密碼時，會導致使用者流失的阻礙 (例如魔法連結或電子郵件 OTP)。
<input id="email" type="email" autocomplete="email">
<input type="hidden" name="token" challenge="1234" autocomplete="email-verification-token">
請注意，是否支援 EVP 由各電子郵件服務供應商決定。請洽詢特定供應商，瞭解他們是否打算支援 EVP。如果您擁有自訂網域，可以將網域連結至支援的電子郵件服務供應商，以便支援 EVP。
這項功能仍處於實驗階段，歡迎在 GitHub 存放區中提供意見。
Digital Credentials API
對於法定姓名或年齡等私密詳細資料，數位憑證 API 提供透過瀏覽器中介服務，使用選擇性揭露向使用者錢包要求驗證資料的方法。也就是說，您不必實際取得使用者的完整出生日期或法定姓名，就能驗證使用者是否超過特定年齡，進而保護他們的隱私。
請參閱「Digital Credentials API: Secure and private identity on the web」。
導入密碼金鑰，提供流暢的登入體驗
密碼金鑰不僅能取代密碼，這項技術是防範網路釣魚的重大進展，可提供無縫驗證體驗。
立即進入 UI 模式
Chrome 149 以上版本提供「立即 UI 模式」。 這樣一來，網站就能在使用者前往您的網站時，立即檢查憑證。如果密碼管理工具中有密碼金鑰或密碼，瀏覽器會立即在登入對話方塊中列出可用帳戶，藉此調解流程。
使用者不必選取登入方式，主動提供所選帳戶的憑證，即可打造流暢的「One Tap」體驗，讓使用者感覺就像魔法一樣。
const credential = await navigator.credentials.get({
password: true,
uiMode: 'immediate',
publicKey: publicKeyObject,
});
請參閱「登入的立即 UI 模式」。
自動填入密碼金鑰表單：在改用密碼金鑰時，使用自動填入表單功能
如果使用者造訪的網站正在從密碼轉移至密碼金鑰，密碼金鑰表單自動填入功能會在輸入欄位成為焦點時，於自動填入建議中顯示密碼金鑰。也就是說，如果使用者已有密碼金鑰，只要在登入表單中將焦點放在使用者名稱欄位，如果沒有，他們仍可使用已儲存的密碼。
如要啟用這項功能，請使用 autocomplete="username webauthn" 註解使用者名稱欄位，並在呼叫 navigator.credentials.get() 時將 mediation 值設為 'conditional'。
在過渡到無密碼時代的過程中，這項功能是至關重要的橋樑，因為它能讓使用者在熟悉的介面中認識密碼金鑰。
請參閱密碼金鑰驗證檢查清單。
策略性採用密碼金鑰
採用通常是時間問題。在適當時機提示使用者，可大幅提高他們註冊密碼金鑰的可能性。
自動建立密碼金鑰
沒有人想為了設定新的登入方式，而深入研究安全性設定。對於現有密碼使用者，您應該如何及何時提示使用者升級為密碼金鑰？
這時自動建立密碼金鑰功能就能派上用場。有了條件式建立功能，瀏覽器就能在使用者透過密碼管理工具登入時，自動將密碼使用者升級為密碼金鑰。
只要將 mediation: 'conditional' 傳遞至 navigator.credentials.create() API，並在使用者最近成功登入時觸發 API (使用儲存在密碼管理工具中的密碼)，瀏覽器就會原生產生新的密碼金鑰，不必強制使用者完成額外的設定畫面。
零阻力註冊表示使用者不必刻意決定要提升安全性，這項功能會自動啟用，保護使用者安全，無需額外操作。舉例來說，adidas 採用這項零提示策略後，密碼金鑰建立次數提升了 8%。
await navigator.credentials.create({
mediation: 'conditional',
publicKey: { ... },
});
請參閱密碼金鑰註冊檢查清單。
密碼金鑰管理和復原機制
使用者必須能夠在裝置、網站和服務之間輕鬆存取憑證。以及管理這些裝置，並確保使用者在裝置遺失或遭竊時可以復原帳戶。
跨平台一致性
如果您有多個共用登入系統的資源 (例如 Android 應用程式和網站，或多個網站)，可以改善使用者體驗。透過憑證整合共用，密碼管理工具可以在所有資源中，向使用者建議正確的憑證。
無縫憑證共用 包含兩項技術：密碼的 Digital Asset Links，以及密碼金鑰的相關來源要求。
使用 Digital Asset Links 可確保在網頁上建立的密碼也能在 Android 應用程式中使用，反之亦然。此外，如果不同網域共用相同的驗證後端，密碼管理工具也能建議使用已儲存的憑證。
使用相關來源要求，透過使用者的憑證管理工具，在不同網域和應用程式中提供密碼金鑰。
這只是其中一種方法，可讓使用者享有更流暢的登入體驗。
提供密碼金鑰管理頁面，方便使用者管理密碼金鑰
如要提供完善的密碼金鑰體驗，建議您建立專屬的密碼金鑰管理頁面，支援清楚的供應商名稱、使用時間和控制項。這有助於使用者放心管理設定。公開相關資訊來建立信任。
請參閱密碼金鑰管理檢查清單。
可靠的帳戶救援程序
裝置可能會遺失或升級。密碼金鑰本身就具有韌性，因為這類金鑰採用硬體層級的保護措施，而且通常會同步到雲端，因此使用者可以在新裝置上還原密碼金鑰。不過，擁有經過驗證的電子郵件地址等備援方式，可確保使用者不會失去數位生活存取權。
您不必讓使用者等待服務中心電話，而是可以透過您已信任的信號 (例如身分同盟或電子郵件驗證)，證明使用者是擁有者。
將這些信號納入復原策略，即可立即還原存取權。一旦恢復正常，請立即註冊新的密碼金鑰，確保帳戶再次受到網路釣魚攻擊的威脅。
使用 DBSC 保護工作階段
為保護使用者免於帳戶遭盜用，確保工作階段 Cookie 安全是另一層重要的防禦措施。裝置綁定工作階段憑證 (DBSC) 可將工作階段繫結至硬體。這樣一來，即使 Cookie 遭竊，也只有同一部裝置可以要求重新發行 Cookie，有效為工作階段增添一層安全防護，有助於防範工作階段遭劫持。
DBSC 是實驗功能，目前適用於 Windows。如要進一步瞭解這項更新，請參閱Windows 上的裝置綁定工作階段憑證公告。我們也正努力將 DBSC 支援範圍擴大至 macOS。
密碼金鑰代理程式技能
我們已在現代網路指南專案中，納入涵蓋本文所述許多層面的密碼金鑰技能。我們很快就會發布一篇有關密碼金鑰技能的網誌文章。
準備好打造未來的驗證機制了嗎？
歡迎參閱我們的深入指南，立即開始進行現代化：