FedCM:隱私權保護身分識別 API

本頁面說明 FedCM 的優點哪些人應考慮導入 FedCM,以及使用者如何與 FedCM 互動

聯合憑證管理 (FedCM) 是一種以隱私權為中心且方便使用的聯合身分服務方法 (例如「使用身分識別提供者登入」),不依賴第三方 Cookie 或導覽重新導向。

透過 FedCM,使用者可以在網站上以新方式向第三方識別資訊提供者驗證身分

什麼是身分聯盟

身分聯盟會將個人 (使用者或實體) 的驗證或授權作業,委派給受信任的外部身分識別提供者 (IdP)。IdP 接著會允許使用者登入依賴方網站 (RP)。透過聯合識別資訊,RP 會依賴 IdP 為使用者提供帳戶,而不需新的使用者名稱和密碼。

使用聯盟身分識別解決方案時,使用者不必為每個 RP 建立另一組憑證。這項功能可提升使用者體驗、降低網路釣魚的機率,並協助 RP 從信任的身分識別提供者取得經過驗證的使用者資訊。

傳統解決方案和第三方 Cookie

傳統的聯合身分驗證機制依賴 iframe、重新導向或第三方 Cookie,因此會引發隱私權疑慮。這些解決方案可能會遭到濫用,用來追蹤網路上的使用者,而瀏覽器無法區分合法的身分識別服務和不必要的監控行為。

考量到隱私權問題,主要瀏覽器紛紛限制第三方 Cookie。這可能會影響部分功能。透過社群的努力和我們的研究,我們發現有幾項與身分同盟相關的整合,會受到第三方 Cookie 限制影響。

使用 FedCM 進行身分聯盟

FedCM 與通訊協定無關:可做為獨立解決方案實作,也可做為不同通訊協定可利用的額外層。舉例來說,如果實作 FedCM 端點,並交換 FedCM 回應中傳回的授權碼,取得 OAuth 存取權杖,功能正常的 OAuth 伺服器就能透過 FedCM 的瀏覽器中介一鍵登入體驗和直覺式 UI 獲益。

為什麼需要 FedCM?

相較於傳統解決方案,它為網路生態系統提供多項優勢,設計時考量了使用者、RP 和 IdP 開發人員的需求。

支援不使用第三方 Cookie 的身分識別解決方案

FedCM 有助於減少對第三方 Cookie 的依賴,這類 Cookie 通常用於追蹤網路上的使用者。即使無法使用第三方 Cookie (例如在無痕模式下),API 仍可提供個人化登入體驗。

此外,FedCM 也整合了其他 Privacy Sandbox API。舉例來說,Storage Access API 會使用 FedCM 驗證做為信任訊號。如果網站同時依賴 FedCM 進行驗證,並使用 SAA 允許跨來源 iframe 存取必要儲存空間,這項整合功能就非常實用。

提升使用者體驗

FedCM 會導入瀏覽器中介的 UI 對話方塊,簡化單次輕觸登入程序。API 也解決了登入頁面雜亂的問題,有時稱為 NASCAR 問題

NASCAR 問題示例:網站提供七種不同的登入選項,導致 UI 雜亂。
NASCAR 問題示例:網站的 IdP 選項過寬,導致 UI 雜亂。

FedCM 提供更簡單易用的介面,取代數量龐大的社群登入按鈕。

安全性

聯合身分驗證方法可讓使用者使用 IdP 管理的信任帳戶。採用這種做法時,使用者不必為每個網站新增憑證。這可減少網路釣魚攻擊的目標。此外,RP 不必自行實施嚴密的安全措施,而是可以仰賴 IdP 的專業知識,由 IdP 負責安全的身分管理。

FedCM 的目標是讓使用者更方便地進行聯合身分識別流程,鼓勵他們優先使用這項功能,而非安全性較低的識別流程。

為更多使用者提供個人化體驗

FedCM 可減少帳戶註冊流程中的 UX 操作不便。Google Identity Service 的案例研究顯示,使用者偏好透過 FedCM 的「一鍵登入」流程建立帳戶,而非多步驟登入選項。

有了 FedCM,更多 IdP 都能為使用者提供輕觸一下即可登入的體驗。隨著越來越多 IdP 提供一鍵式身分驗證流程,使用者可以在 RP 上選擇更多 IdP。FedCM 會向使用者顯示最相關的帳戶,提供改良的 IdP 選取機制。

註冊率越高,RP 就能為更多使用者提供個人化體驗。

支援多種身分識別提供者

FedCM 的簡化版 UI 旨在向使用者顯示相關 IdP 的個人化清單。有了 FedCM 的 IdP 選取機制,依賴方就不會再因為 IdP 的使用者群規模而受到限制。舉例來說,部分使用者可能只有 small-idp.example 的帳戶,而沒有 bigger-idp.example 的帳戶。

有了 Multi-IdP 功能,rp.example 就能同時支援 small-idp.examplebigger-idp.example,不會讓使用者介面變得雜亂。這對所有當事人都有好處:

  • 使用者可以選擇偏好的 IdP,無論大小。
  • RP 可透過多樣化的 IdP 支援觸及更多使用者
  • 使用者人數較少的 IdP 可在更多 RP 上使用。

哪些人適合使用 FedCM?

只有在符合下列條件時,我們才建議您使用 FedCM:

  • 您是具有第三方 RP 的識別資訊提供者 (IdP)。
  • 您有自己的身分識別解決方案,且多個網域都依賴該解決方案。
  • 即使使用者選擇在瀏覽網頁時不使用第三方 Cookie,您仍希望支援聯合身分識別流程。

您是 IdP

FedCM 需要識別資訊提供者支援。信賴方無法獨立使用 FedCM。如果您是 RP,可以請 IdP 提供操作說明。

多個 RP

如果 RP 是第三方,或您有超過四個 RP 使用您的身分識別解決方案,建議使用 FedCM API 進行聯合身分識別。

您希望支援無 Cookie 的身分聯盟流程

即使使用者瀏覽時未啟用第三方 Cookie,FedCM 仍支援基本的聯合身分驗證流程。透過 FedCM,使用者仍可在 RP 上註冊、登入及登出聯合帳戶。

此外,FedCM 可做為 Storage Access API 的信任信號,消除 IdP 啟動的儲存空間存取要求所造成的摩擦。

使用者與 FedCM 的互動

FedCM 的設計與驗證通訊協定無關,並提供新流程,讓使用者透過第三方 IdP 向 RP 驗證身分。歡迎透過示範試用 FedCM。

登入依附方

使用者可以從 RP 支援的 IdP 組合中選擇帳戶。如果使用者透過多個 IdP 登入,系統會提示他們使用其中一個 IdP 登入 RP。

系統會依下列順序顯示使用者的帳戶:

  • 系統會優先顯示使用者裝置上存取的帳戶,並依存取時間排序,最近存取的帳戶會顯示在最上方。
  • 接下來會顯示使用者在 RP 上透過 IdP 存取的帳戶。系統會從approved_clients account endpoint 屬性值擷取帳戶存取資訊。
  • 先前未在 RP 上使用過的帳戶會顯示在最後。

如果這些優先順序層級中有多個帳戶,系統會根據 RP 在 get() 呼叫中提供的 IdP 順序,進一步排序這些帳戶

FedCM UI 模式

FedCM 有兩種 UI 模式:「被動」和「主動」

被動模式。被動模式不需要使用者互動,系統就會顯示 FedCM 提示。當使用者進入依附方 (RP) 網站時,如果符合下列條件,系統呼叫 navigator.credentials.get() 時就會顯示 FedCM 登入對話方塊:

  • 使用者已登入至少一個支援的 IdP。如果使用者在所有可用的 IdP 中都處於登出狀態,系統就不會自動顯示 FedCM 登入提示。
  • 使用者的瀏覽器未設定 FedCM 冷卻設定
  • 使用者未在瀏覽器設定中停用 FedCM。 進一步瞭解使用者如何停用 FedCM。
使用者在被動模式下,依序透過不同 IdP 驗證:先登入並登出一個 IdP,然後透過下一個 IdP 驗證。

主動模式。在主動模式下,必須有暫時性使用者啟用 (例如點選「使用…登入」按鈕),才能觸發 FedCM 提示。

使用者在啟用模式下,透過 FedCM 登入 RP。

使用者可以輕觸「以使用者身分繼續」完成登入。如果成功,瀏覽器會儲存使用者已在 RP 上透過 IdP 建立同盟帳戶的事實。

如果使用者在 RP 上沒有 IdP 帳戶,系統會顯示註冊對話方塊,並附上額外的揭露文字,例如 RP 的服務條款和隱私權政策。

遵守電子隱私權法規

無論是做為 IdP 或 RP 使用 FedCM,都涉及在使用者終端設備上儲存資訊,或存取已儲存在其中的資訊,因此這類活動須遵守歐洲經濟區 (EEA) 和英國的電子隱私權法規,一般來說需要取得使用者同意聲明。您有責任判斷使用 FedCM 是否絕對必要,才能提供使用者明確要求的線上服務,因此可免除同意聲明規定。

Vision

我們正積極開發新功能,以解決目前的限制,並提供更優質的使用體驗。

  • 我們正在探索更靜態的使用者體驗公式,確保使用者能順暢、直覺地完成驗證程序,且不會受到干擾。
  • 我們致力於提升使用者隱私權。我們計畫改用以委派為導向的 NextGen FedCM 模型,以減輕 IdP 追蹤問題。使用 NextGen 時,使用者可以在 RP 上登入,不必追蹤 IdP。
  • FedCM 的目標是根據 RP 的選擇,向使用者顯示更多 IdP 選項。為此,我們正在開發 Multi-IdP 和 IdP 註冊 API。
  • 我們正積極整合 FedCM 與其他驗證方法 (例如密碼金鑰),並透過自動填入等其他方式,提供統一的驗證體驗。

詳情請參閱路線圖