adidas 如何運用條件式建立和 Signal API，加速採用密碼金鑰並提升可靠性

Christopher Kokott
Christopher Kokott
LinkedIn
Yu Tsuno
Yu Tsuno
LinkedIn

黑色 adidas 標誌，標誌上方有三條斜線，下方則為小寫的 adidas 字樣。

機構和開發人員在將使用者從密碼轉移至密碼金鑰時，會面臨重大障礙。密碼金鑰可大幅提升安全性，但手動建立密碼金鑰的過程可能相當繁瑣。在交易量高的電子商務環境中，每猶豫一秒都很重要，因為任何延遲都可能中斷購買流程，導致購物車遭到棄置。此外，在伺服器和使用者裝置之間保持憑證狀態同步，對於避免登入錯誤和使用者感到不悅至關重要。

adidas 也面臨了這些挑戰。他們的主要目標是減少登入程序的操作障礙，並簡化網頁、應用程式平台和裝置的使用體驗。雖然安全仍是首要之務，但產品團隊專注於使用密碼金鑰，盡可能讓註冊和登入流程順暢無礙。

為解決這些挑戰，adidas 導入了條件式建立功能，自動將密碼使用者升級為密碼金鑰，並使用 Signal API 確保憑證一致。此外，他們還部署了相關來源要求，以便在需要時支援跨網域使用。

成果

adidas 採用自動建立密碼金鑰和維護憑證健全狀態的策略後，在採用率和登入可靠性方面，立即獲得可衡量的成效：

  • 高採用率：adidas 推出密碼金鑰登入程序後，整體密碼金鑰建立率達到 47%。這包括自動建立條件，以及使用者在註冊或登入流程中收到提示時，主動選擇加入。行動裝置的採用率特別高，轉換率達 52% (電腦為 34%)。
  • 使用條件式建立功能加速升級：除了明確提示外，adidas 還在背景中順暢升級現有密碼使用者，無需手動操作，結果密碼金鑰建立次數增加 8% 。
  • 近乎完美的登入可靠性：登入程序啟動後，密碼金鑰的成功率超過 99%。相較於 adidas 過去 70% 的密碼成功率，這項升級大幅提升了安全性，因為人為錯誤 (例如打錯字或忘記憑證) 往往會降低成功率。
  • 減少阻礙和錯誤：adidas 部署 Signal API，自動同步處理裝置和伺服器憑證，成功將PASSKEY_NOT_FOUND錯誤率降至登入嘗試次數的 0.3% 以下。這項功能可有效解決使用者因無主密碼金鑰而感到困擾的問題。

    47 %

    密碼金鑰建立率

    8 %

    使用條件式建立功能，提升密碼金鑰建立率

    >99 %

    啟動密碼金鑰登入程序後的成功率

    <0.3 %

    孤立密碼金鑰錯誤率

adidas 如何解決問題

adidas 解決這些挑戰的方法如下：

1. 使用條件式建立功能加快採用速度

為協助使用者順暢採用密碼金鑰，adidas 實作了條件式建立。這項功能可讓網站在使用者以密碼管理工具中儲存的密碼登入時，自動建立密碼金鑰。為確保最高成功率，系統會在登入成功後立即呼叫 API，讓系統將密碼使用視為近期行為。

const cred = await navigator.credentials.create({
  publicKey: options,
  mediation: 'conditional' // Enables automatic passkey creation
});

adidas 將這項功能與自訂邏輯整合，首先會驗證使用者環境。具體來說，系統會檢查瀏覽器是否支援「條件式建立」功能。如果使用者在過去六個月內已略過建立密碼金鑰三次，系統也會尊重使用者偏好設定，不再顯示提示。

如果環境相容，系統會在使用者身分驗證成功後，立即嘗試在背景建立密碼金鑰。這個特定時間點可確保符合必要條件。重要事項：這項實作作業會以「開放失敗」原則處理 WebAuthn 例外狀況，一律優先考量使用者存取權。如果瀏覽器回報 InvalidStateError，表示可能已有密碼金鑰，系統會停止在背景建立密碼金鑰，並立即讓使用者登入。反之，如果發生 NotAllowedError，表示自動建立的特定條件未達成，系統會偵測到這個狀態，並引導使用者前往「密碼金鑰收集器」畫面，逐步完成手動設定程序。adidas 區分了這些技術限制和使用者行為，確保推動密碼金鑰升級能提升登入體驗，而不是中斷登入程序。

adidas 網站上顯示「下次使用密碼金鑰登入」提示，鼓勵使用者建立密碼金鑰，以便透過生物特徵辨識或密碼登入，享有更快速安全的登入體驗。
「密碼金鑰收集器」畫面。

2. 使用 Signal API 確保可靠性

使用者在不同裝置上管理憑證時，可能會發生不一致的情況。舉例來說，密碼金鑰可能會從伺服器刪除，但仍保留在使用者裝置上。為避免這些「幽靈」憑證導致登入失敗，adidas 導入了 Signal API。伺服器可透過這個 API 將憑證狀態信號傳送給密碼金鑰提供者。

adidas 使用所有三種可用的 Signal API 方法，維持這項一致性。adidas 不會猜測要移除哪些憑證，而是將特定使用者生命週期事件對應至適當的 API 呼叫：

  • 註冊失敗：如果在用戶端建立密碼金鑰，但無法在後端註冊，adidas 會使用 signalUnknownCredential 立即移除孤立的憑證。
  • 無效的登入：如果使用者嘗試以已撤銷或過時的密碼金鑰登入，signalUnknownCredential 會通知提供者隱藏該密碼金鑰。
  • 使用者管理：當使用者在帳戶設定中明確移除密碼金鑰時，signalAllAcceptedCredentials 會同步處理允許清單。確保系統不會再提供已刪除的密碼金鑰。
  • 帳戶更新：使用者變更電子郵件地址或使用者名稱時，signalCurrentUserDetails 會更新裝置上的中繼資料，與伺服器相符。
// Detect authentication failure due to lack of the credential

if (result.status === 404) {
  if (PublicKeyCredential.signalUnknownCredential) {
    await PublicKeyCredential.signalUnknownCredential({
      rpId: "adidas.com",
      credentialId: "..." // base64url encoded credential ID
    });
  }
}
adidas 帳戶設定中的確認模式，可讓使用者移除特定密碼金鑰，並顯示警告訊息，指出該密碼金鑰將無法再用於登入。
移除密碼金鑰的確認模式。
Google 密碼管理工具發出「已刪除密碼金鑰」通知，指出密碼金鑰已無法使用，說明 Signal API 如何讓使用者的裝置與伺服器保持同步。
已刪除密碼金鑰的 Signal API 通知。

為進一步支援多市場架構，adidas 導入了相關原始要求。雖然大多數使用者會留在當地市場 (例如 adidas.nl)，但這項設定可讓在不同區域之間瀏覽的使用者，透過指定單一憑證方 ID (adidas.com)，在允許的網域中重複使用密碼金鑰。

如要啟用這項功能，adidas 會在主要 Relying Party ID (RP ID) 網域中代管 webauthn 設定檔。這個檔案包含明確的來源許可清單，允許這些來源使用 adidas.com 註冊及驗證密碼金鑰。定義這些關係後，瀏覽器就能驗證在一個區域網站上建立的密碼金鑰是否適用於另一個網站，為全球使用者提供流暢體驗。

// https://www.adidas.com/.well-known/webauthn

{
  "origins": [
    "https://www.adidas.fi",
    "https://www.adidas.nl",
    // ... abridged (the full file lists 50+ regional domains)
  ]
}

值得一提的是，adidas 也透過數位資產連結，在 Android 行動應用程式中提供流暢的密碼金鑰支援。由於應用程式使用 idp.adidas.com 代管的 WebView 進行驗證，因此需要 Digital Asset Links，才能在 Android 應用程式和 Relying Party ID (adidas.com) 之間建立信任關係。完成驗證後，應用程式就能存取網頁上使用的相同密碼金鑰，在不同平台提供流暢一致的登入體驗。

為此，adidas 會在各自的網域上代管 Digital Asset Links (assetlinks.json) 檔案。這個檔案會公開聲明與 Android 應用程式的加密關聯。同樣地，為了支援 iOS 生態系統，adidas 使用了相關聯網域。代管 apple-app-site-association 檔案可建立安全連線，讓 iOS 應用程式在 WebView 中安全使用密碼金鑰。

// https://www.adidas.fi/.well-known/assetlinks.json

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls",
      "delegate_permission/common.get_login_creds"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "com.adidas.app",
      "sha256_cert_fingerprints": [
        "B2:55:43:78:89:F6:F6:FD:BB:16:5C:43:EE:66:14:18:D4:E8:33:6D:3A:1F:68:86:C3:A8:7C:89:2B:51:45:96",
        "..."
      ]
    }
  },
  // ... abridged
]
技術順序圖，顯示用戶端裝置與目標伺服器之間，透過相關來源要求 (ROR) 和數位資產連結 (DAL) 建立的信任關係。
相關來源要求的序列圖
Android 裝置上顯示系統層級的密碼金鑰提示，要求使用者使用已儲存的密碼金鑰登入 adidas 識別資訊提供者。
條件式登入
adidas 行動應用程式登入畫面，設有專屬的「繼續使用密碼金鑰」按鈕，提供簡化的驗證體驗。
先提供 ID

adidas 的下一步是什麼？

adidas.fi 和 adidas.nl 網站已採用自動升級和同步處理憑證的強大基礎架構，因此 adidas 將在 2026 年 4 月底前，在所有其他全球市場部署這項無縫設定。此外，adidas 也正在測試即時中介服務來源試用版，探索更順暢的登入體驗。我們也計畫讓使用者直接以密碼金鑰建立帳戶。這樣一來，使用者就不必先以其他方式註冊，團隊也正在研究「智慧觸發」功能，以便在登入的第二個步驟直接叫用系統密碼金鑰對話方塊。如果系統高度確信使用者目前裝置上有可用的密碼金鑰，就不必再點選額外按鈕。

對您的影響

如果使用者體驗保持流暢，就能順利改用無密碼驗證。導入條件式建立功能後，您就能輕鬆讓使用者改用密碼以外的登入方式，且不會打斷他們的使用習慣。使用「相關來源要求」，您可以在網域之間共用這些密碼金鑰，讓使用者透過單一密碼金鑰，順暢存取整個生態系統。最後，搭配使用 Signal API 可確保統一的無密碼體驗維持穩定可靠，不會發生錯誤。

瞭解詳情