在 Chrome 122 版中，您可以使用 Federated Credential Management API (FedCM) 的 中斷連線 API。Connections API 可讓仰賴第三方中斷使用者與識別資訊提供者帳戶的連線，而不用依賴第三方 Cookie。此外，FedCM 的相同網站處理方式還有幾項更新。
取消連結 API
當使用者透過識別資訊提供者，在依賴方 (RP，即使用識別資訊提供者進行驗證的網站) 建立帳戶時，識別資訊提供者 (IdP，即提供驗證與帳戶資訊的服務) 通常會記錄他們伺服器上的連線。儲存的連線可讓 IdP 追蹤使用者登入的 RP，並改善其體驗。舉例來說，如要在使用者之後返回 RP 時有更好的體驗，系統會將採用 IdP 的使用者帳戶視為回訪帳戶，進而啟用自動重新驗證等功能和顯示所用帳戶的個人化按鈕等功能。
IdP 有時會提供 API，用來將帳戶與 RP 取消連結。不過，中斷連線流程會通過驗證，且需要 IdP Cookie。在這個不使用第三方 Cookie 的環境中，當使用者造訪 RP 時，沒有瀏覽器 API 可供 RP 與 IdP 中斷連線。由於同一個 IdP 可能會有多個連結至特定 RP 的 IdP 帳戶，因此中斷連線流程需要知道哪個帳戶要中斷連線。
中斷連線 API 可讓使用者透過向指定端點發出訊息，藉此在瀏覽器和 IdP 伺服器上中斷 IdP 帳戶和 IdP 伺服器之間的連結。使用者必須使用 Federated Credential Management API (FedCM) 完成身分聯盟。使用者中斷連線後，系統會在使用者下次嘗試使用 IdP 登入 RP 時，將他們視為新使用者。
中斷 IdP 與 RP 的連線
如果使用者先前已透過 FedCM 使用 IdP 登入 RP，則瀏覽器會在本機將關係記憶為已連結的帳戶清單。RP 可能會叫用 IdentityCredential.disconnect() 函式來啟動中斷連線。這個函式可從頂層 RP 框架呼叫。RP 必須傳遞 configURL、在 IdP 下使用的 clientId，以及 accountHint 才能中斷連線 IdP。帳戶提示可以是任意字串，只要中斷連線的端點能識別帳戶 (例如電子郵件地址或使用者 ID)，該 ID 不一定與帳戶清單端點所提供的帳戶 ID 相符：
// Disconnect an IdP account "account456" from the RP "https://idp.com/". This is invoked on the RP domain.
IdentityCredential.disconnect({
configURL: "https://idp.com/config.json",
clientId: "rp123",
accountHint: "account456"
});
IdentityCredential.disconnect() 會傳回 Promise。這項承諾可能會擲回例外狀況，原因如下：
- 使用者尚未透過 FedCM 使用 IdP 登入 RP。
- 系統在沒有 FedCM 權限政策的 iframe 中叫用 API。
- configURL 無效或缺少中斷連線端點。
- 內容安全政策 (CSP) 檢查失敗。
- 有一個待處理的取消連結要求。
- 使用者在瀏覽器設定中停用 FedCM。
當 IdP 的中斷連線端點傳回回應時，RP 和 IdP 會在瀏覽器上中斷連線，並成功解決承諾。中斷連線的使用者帳戶是在中斷連線端點的回應中指定。
設定 IdP 設定檔
為了支援 Connection API，IdP 必須支援中斷連線端點，並在 IdP 設定檔中提供 disconnect_endpoint 屬性及其路徑。
{
"accounts_endpoint": "/accounts",
"id_assertion_endpoint": "/assertion",
...
"disconnect_endpoint: "/disconnect"
}
在中斷連線端點上中斷帳戶連線
叫用 IdentityCredential.disconnect() 後，瀏覽器會將含有 Cookie 和內容類型 application/x-www-form-urlencoded 的跨來源 POST 要求傳送至這個中斷連線的端點，並提供以下資訊：
| 屬性 | 說明 |
|---|---|
account_hint |
IdP 帳戶的提示。 |
client_id |
RP 的用戶端 ID。 |
POST /disconnect HTTP/1.1
Host: idp.example
Origin: rp.example
Content-Type: application/x-www-form-urlencoded
Cookie: 0x123
Sec-Fetch-Dest: webidentity
account_hint=account456&client_id=rp123
收到要求後，IdP 伺服器應會執行以下作業：
- 使用 CORS (跨源資源共享) 回應要求。
- 確認要求包含
Sec-Fetch-Dest: webidentityHTTP 標頭。 - 比對
Origin標頭與 RP 來源，由client_id決定。 如果不相符，則拒絕。 - 找出與
account_hint相符的帳戶。 - 取消使用者帳戶與 RP 已連結帳戶的清單。
- 以 JSON 格式回應附有識別使用者
account_id的瀏覽器。
回應 JSON 酬載的範例如下所示：
{
"account_id": "account456"
}
如果 IdP 希望瀏覽器改為取消連結所有與 RP 相關聯的帳戶，請傳送與任何帳戶 ID 不相符的字串，例如 "*"。
如果 RP 和 IdP 相同，系統會略過 /.well-known/web-identity 檢查
在開發 FedCM 系統時，測試或測試環境 RP 伺服器網域可能是實際工作環境 IdP 伺服器的子網域。舉例來說，實際工作環境 IdP 伺服器位於 idp.example，而暫存 RP 伺服器和暫存 IdP 伺服器都位於 staging.idp.example。不過，由於已知檔案必須放在 IdP 伺服器 eTLD+1 的根目錄中，因此必須位於 idp.example/.well-known/web-identity，且是實際執行伺服器。由於開發人員在開發期間不一定能將檔案置於實際工作環境，因此無法測試 FedCM。
自 Chrome 122 版起，如果 RP 網域和 IdP 網域相同，Chrome 就會略過檢查已知檔案。如此一來，開發人員就能在這類情境中進行測試。
子資源現在可以設定相同網站登入狀態
以往，只有在要求是所有祖系的「相同來源」時，Chrome 才允許設定登入狀態 (例如使用 Set-Login: logged-in 標頭)。這可避免透過相同網站
fetch() 要求設定登入狀態的登入。
舉例來說，假設某個網站允許使用者在 idp.example 上輸入使用者名稱和密碼，但憑證會透過 fetch() 發布至 login.idp.example。無法使用 Login Status API 將登入狀態記錄到瀏覽器，因為這兩個網域為跨來源且相同網站。
經過這項變更，我們放寬了登入狀態 API 的要求，使其成為所有祖系的相同網站，並使上述範例能夠使用 HTTP 標頭 (Set-Login:
logged-in) 設定 login.idp.example 的登入狀態。
摘要
FedCM 現在可以透過 Connection API 來中斷 RP 與 IdP 的連線，而不必使用第三方 Cookie。方法是在 RP 上呼叫 IdentityCredential.disconnect()。這個函式會透過這個函式傳送要求至 IdP 的中斷連線端點，讓 IdP 在伺服器上終止連線，然後再透過瀏覽器終止連線。
我們已宣布，當 RP 和 IdP 相同時，系統會略過 /.well-known/web-identity 檢查，以便進行測試。此外，您現在也可以從相同網站 IdP 子資源的 HTTP 回應標頭設定登入狀態。