各行各業的領導者都瞭解，在為所有使用者提供優質體驗的同時，保護隱私權至關重要。Seznam 致力於提供不打折的使用者體驗和隱私權保障，並已成功整合 Federated Credential Management (FedCM)。
目標設定檔：可從 FedCM 受惠的公司
各領域的機構都已將 FedCM 整合至解決方案。由於 FedCM 的設計適用於聯合身分管理，因此識別資訊提供者 (IdP) 是主要受益者，可使用這項功能提供更優質的登入體驗。電子商務服務供應商和付款服務供應商 (其中許多也擔任身分識別提供者)，也發現透過實作 FedCM，有機會提升使用者體驗。
Seznam
Seznam 是歐洲科技公司和身分識別供應商，觸及 90% 的捷克人口。 做為社交、知識和內容中心。Seznam 採用 FedCM，讓在合作夥伴平台上營運的網路商店客戶，可以使用 Seznam 帳戶登入。
採用 FedCM 後，Seznam 合作夥伴網路的使用者登入率顯著提升，使用者體驗也獲得改善，而且無論第三方 Cookie 是否可用，身分識別流程都保持一致。
動機
Seznam 選擇導入 FedCM 是因為他們發現了幾項優點：
- FedCM 的設計以使用者為中心，讓使用者控管提供給 IdP 的資訊。這與 Seznam 為使用者提供安全私密環境的願景一致。
- FedCM 是內建的瀏覽器功能，與 Seznam 現有的登入體驗相容，後者採用 OAuth 2.0 標準。
- FedCM 的設計宗旨是以隱私權為重的身分聯盟方法。舉例來說，只有在使用者選擇登入時，系統才會將使用者造訪 RP 的事實分享給 IdP。這與 Seznam 對永續經營的看法一致。
實作詳情
Seznam 在現有的 OAuth 解決方案上實作 FedCM，在這個架構中，FedCM 流程用於將 OAuth 授權碼從 IdP 安全地傳輸至 RP。
導入難易度
Seznam 強調，FedCM 的導入作業相當簡單，與他們現有的做法一致。他們花了一個月研究及導入 API，並動用兩名開發人員。他們在不到兩個月的時間內，就將 FedCM 投入生產環境。這個過程是反覆進行的，我們花費大量時間仔細研究 API。
挑戰
Seznam 是早期採用者，他們發現了幾項挑戰，並提供寶貴意見，協助我們改善 API。
支援多個身分識別提供者
Seznam 對 FedCM 支援多個識別資訊提供者這點很感興趣。這項功能的目的是讓使用者在合作夥伴的 RP 上選擇 Seznam 或 Google 帳戶。不過，當 Seznam 首次著手導入 FedCM 時，這項功能仍處於早期導入階段，開發人員必須註冊原始碼試用，並使用權杖為使用者啟用這項功能。因此，Seznam 選擇等待這項功能在 Chrome Beta 版中推出。
這項功能適用於 Chrome 136 以上版本，開發人員可以設定支援多個身分識別提供者。舉例來說，如要同時支援 Seznam 和 Google 識別資訊提供者，IdP 可以在單一 get() 呼叫中加入這兩個提供者，RP 也可以獨立執行這項操作：
// Executed on the RP's side:
const credential = await navigator.credentials.get({
identity: {
providers: [
{
// IdP1: Seznam's config file URL
configURL: 'https://szn.cz/.well-known/web-identity',
clientId: '123',
},
{
// Also allow Google Sign-in
configURL: 'https://accounts.google.com/gsi/fedcm.json',
clientId: '456',
},
],
},
});
Seznam 表示這項功能將納入解決方案。此外，FedCM 團隊也實作了多個 SDK 的支援功能，支援多個 get() 呼叫。
私人 DNS
在測試階段，Seznam 遇到與網路設定相關的挑戰。 他們的測試 IdP 伺服器位於私人網路中，只能透過私人 DNS 存取。在服務公開發布前，內部測試和開發環境通常會採用這種設定。
不過，這種設定會導致一個問題：由於 well-known 檔案必須從 eTLD+1 提供，而私有開發網域並未在 Public Suffix List 中註冊，因此瀏覽器不會傳送要求，擷取開發網域上代管的 well-known 檔案：
login.idp.example：例如正式版網域。idp.example/.well-known/web-identity：出示文件中的知名檔案範例。login.dev.idp.example：例如開發網域。login.dev.idp.example/.well-known/web-identity：開發環境中的知名檔案範例。
如果 FedCM 實作項目代管於私人網域，瀏覽器對 well-known 檔案的要求會導致這項錯誤：
The fetch of the well-known file resulted in a network error: ERR_NAME_NOT_RESOLVED
啟用 Chrome #fedcm-without-well-known-enforcement 旗標即可解決這項錯誤。啟用這項標記後，瀏覽器會略過擷取 well-known 檔案，以利進行測試。瞭解如何在 Chrome 中啟用測試標記。
自訂資訊揭露聲明
Seznam 也表示，他們希望在 FedCM UI 的初始設計中加入額外資訊。標準 FedCM 對話方塊會向使用者顯示固定訊息，說明系統會與 RP 分享特定資料，通常是使用者的個人資料相片、姓名和電子郵件地址。
FedCM 團隊已納入意見回饋，並擴充 API，讓您自訂向使用者顯示的揭露事項。舉例來說，透過「繼續操作」功能，IdP 可以將使用者重新導向至自訂頁面，要求提供其他資訊或權限。Chrome 132 以上版本支援自訂參數和欄位功能，可進一步自訂。
信賴憑證者來源驗證
IdP 伺服器必須驗證傳入 FedCM 要求中的 Origin HTTP 標頭，確保要求符合 RP 向 IdP 預先註冊的來源。這可確保 FedCM ID 聲明要求來自授權 RP，而非使用 client_id 的攻擊者。
Seznam 有一個特殊情況：合作夥伴 RP 向 Seznam 註冊時，不會要求 RP 的來源資料。這表示無法驗證 RP 的來源。
Seznam 的 FedCM 整合功能是以現有的 OAuth 解決方案為基礎建構而成。他們採取替代做法，同時驗證 RP 的 client_id 和 client_secret，確保解決方案維持安全，不必檢查來源。
識別資訊提供者面向使用者的網域
Seznam 的使用者驗證基礎架構主要在 szn.cz 網域運作，FedCM 的必要 IdP 端點也託管於此。不過，他們的主要企業身分和網域是 seznam.cz，使用者普遍認得並信任該網域下的服務。
FedCM 對話方塊會顯示 IdP 端點的實際來源網域，在本例中為 szn.cz。
熟悉 seznam.cz 品牌的使用者可能會感到困惑，並在登入過程中看到較不熟悉的 szn.cz 網域時猶豫不決。
從 Chrome 141 版起，FedCM 不允許顯示與 IdP 實作代管網域不同的網域。這項限制是刻意設計的選擇，旨在確保使用者資訊透明度。不過，FedCM 團隊瞭解這項限制可能造成的挑戰，目前正在討論可能的調整措施。
影響
Seznam 現在可透過 FedCM API，為合作夥伴的使用者提供單次輕觸授權流程。他們強調，與其他驗證方法相比，FedCM 的使用者體驗具有優勢。
Seznam 發現改用 FedCM 登入的網站，使用者參與度顯著提升，但他們並未進行全面分析，以排除其他因素，找出確切的直接影響。整合 FedCM 前，實作方式允許使用同意的雜湊電子郵件進行訪客結帳，以識別使用者。這類分析的挑戰在於估算使用者轉換是否可歸因於 FedCM，或是使用者是否會使用訪客結帳完成購買。Seznam 的假設指出，FedCM 提供的易用性可能促成了轉換率提升。
結論
Seznam 成功導入 FedCM，在現有的 OAuth 解決方案之外，提供替代授權流程。Seznam 開發人員在導入 API 時，遇到了一些與身分識別提供者支援、私有 DNS 設定、揭露文字自訂、信賴方來源驗證，以及面向使用者的網域顯示相關的挑戰，但自從導入後，API 已日趨成熟。FedCM 團隊已納入 Seznam 和其他早期採用者的意見，開發出更完善的工具來解決這些挑戰。下一步，Seznam 打算實作 FedCM 對多個識別資訊提供者的支援。