FedCM-Updates: Verknüpfung der API und zwei Updates aufheben

Eiji Kitamura

In Chrome 122 die separate API für Federated Credential Management API (FedCM) ist verfügbar. Die Mit der Attach API können vertrauende Parteien ihre Nutzer von der ohne Drittanbieter-Cookies zu verwenden. Außerdem gibt es gibt es einige Neuerungen bei der Verarbeitung von Same-Site-Ansätzen von FedCM.

API trennen

Wenn ein Nutzer ein Konto auf einer vertrauenden Seite (RP, also die Website, die das Identitätsanbieter zur Authentifizierung) über die Identitätsföderation, die Identität Anbieter (IdP, d. h. der Dienst, der Authentifizierungs- und Kontoinformationen bereitstellt) wird die Verbindung normalerweise auf seinem Server aufgezeichnet. Die gespeicherten ermöglicht es dem IdP, RPs nachzuverfolgen, bei denen sich der Nutzer angemeldet hat, User Experience zu optimieren. Zum Beispiel für ein besseres Erlebnis, wenn das später zum RP zurückkehrt, wird das Nutzerkonto mit dem IdP als Rückkehrkonto, mit dem Funktionen wie die automatische erneute Authentifizierung und personalisierte Schaltflächen, die das verwendete Konto anzeigen.

Manchmal bieten IdPs eine API an, um das Konto von einem RP zu trennen. Eine Ablauf zum Trennen der Verbindung ist authentifiziert und erfordert die IdP-Cookies. In einer Welt Ohne Drittanbieter-Cookies gibt es keinen Browser, wenn der Nutzer das RP aufruft. API für die RP, die vom IdP getrennt werden soll. Weil es möglicherweise mehrere IdPs gibt vom selben IdP, der mit einem bestimmten RP verknüpft ist, und wissen, welches Konto gerade getrennt wird.

Die Trennung API ermöglicht es dem Nutzer, das IdP-Konto auch im Browser vom RP zu trennen wie auf dem IdP-Server, indem Sie es dem angegebenen Endpunkt signalisieren. Die Nutzenden benötigen Sie müssen die Identitätsföderation mithilfe der föderierten Berechtigungsnachweise durchlaufen haben. Management API (FedCM). Sobald die Verbindung für den Nutzer getrennt wurde, wird er wie ein neuer Nutzer behandelt. wenn er sich das nächste Mal über den IdP beim RP anmeldet.

IdP vom RP trennen

Wenn sich ein Nutzer zuvor über FedCM mit dem IdP beim RP angemeldet hat, wird vom Browser lokal als Liste der verbundenen Konten. Der RP kann die Verbindung trennen, indem der IdentityCredential.disconnect(). Diese Funktion kann von einer RP-Frame der obersten Ebene. Die RP muss ein configURL übergeben, das verwendete clientId. unter dem IdP und eine accountHint für den zu trennenden IdP. Ein Konto Der Hinweis kann ein beliebiger String sein, solange der Endpunkt zum Trennen der Verbindung das Konto, z. B. eine E-Mail-Adresse oder Nutzer-ID, die nicht unbedingt Sie stimmen mit der Konto-ID überein, die vom Kontolistenendpunkt angegeben wurde:

// 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() gibt Promise zurück. Dieses Versprechen könnte eine ist aus folgenden Gründen eine Ausnahme:

  • Der Nutzer hat sich nicht über FedCM mit dem IdP beim RP angemeldet.
  • Die API wird in einem iFrame ohne FedCM-Berechtigungsrichtlinie aufgerufen.
  • Die configURL ist ungültig oder der Endpunkt für die Verbindung fehlt.
  • Die Prüfung der Content Security Policy (CSP) schlägt fehl.
  • Es gibt eine ausstehende Anfrage zum Trennen einer Verbindung.
  • Der Nutzer hat FedCM in den Browsereinstellungen deaktiviert.

Wenn der IdP-Endpunkt zum Trennen einer Verbindung , werden der RP und der IdP auf der und das Versprechen ist gelöst. Die Nutzerkonten, von denen die Verknüpfung getrennt wird, in der Antwort auf die Verbindungstrennung angegeben Endpunkt.

IdP-Konfigurationsdatei einrichten

Damit die Attach API unterstützt wird, muss der IdP das Aufheben der Verbindung unterstützen Endpunkt und geben Sie das Attribut disconnect_endpoint und seinen Pfad bei seinem IdP an Konfigurationsdatei.

{
  "accounts_endpoint": "/accounts",
  "id_assertion_endpoint": "/assertion",
  ...
  "disconnect_endpoint: "/disconnect"
}

Konto am Endpunkt trennen

Durch den Aufruf von IdentityCredential.disconnect() sendet der Browser eine ursprungsübergreifende POST-Anfrage mit Cookies und dem Inhaltstyp von application/x-www-form-urlencoded an diesen Endpunkt der Verbindung mit dem folgende Informationen:

Attribut Beschreibung
account_hint Ein Hinweis für das IdP-Konto.
client_id Die Client-ID des RP. 
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

Nach Erhalt der Anfrage sollte der IdP-Server Folgendes tun:

  1. Sie antworten mit CORS (Cross-Origin Resource) auf die Anfrage. Freigabe).
  2. Prüfen Sie, ob die Anfrage einen Sec-Fetch-Dest: webidentity-HTTP-Header enthält.
  3. Gleichen Sie den Origin-Header mit dem RP-Ursprung ab, der durch client_id bestimmt wird. Du kannst sie ablehnen, wenn sie nicht übereinstimmen.
  4. Suchen Sie das Konto, das mit account_hint übereinstimmt.
  5. Trennen Sie das Nutzerkonto von der Liste der verbundenen Konten des RP.
  6. Dem Browser mit der account_id des identifizierten Nutzers in einer JSON-Datei antworten Format.

Eine Beispielantwort für eine JSON-Nutzlast sieht so aus:

{
  "account_id": "account456"
}

Wenn der IdP stattdessen die Verbindung aller Konten trennen möchte, die mit der RP einen String übergeben, der mit keiner Konto-ID übereinstimmt, z. B. "*".

Die Überprüfung von /.well-known/web-identity wird jetzt übersprungen, wenn RP und IdP zur selben Website gehören.

Beim Entwickeln eines FedCM-Systems kann das Testen oder Staging von RP-Serverdomains der Subdomains des IdP-Produktionsservers. Beispiel: Produktions-IdP-Server sich unter idp.example und sowohl auf dem Staging-RP-Server als auch unter dem Staging-IdP-Server befindet finden Sie unter staging.idp.example. Da die bekannte Datei jedoch im Stammverzeichnis der eTLD+1 des IdP-Servers, idp.example/.well-known/web-identity und es ist der Produktionsserver. Seit können Entwickler Dateien nicht unbedingt in der Produktionsphase platzieren, in der Entwicklungsphase ist, hindert sie daran, FedCM zu testen.

Wenn ab Chrome 122 die RP-Domain und die IdP-Domain identisch sind, überspringt das Überprüfen der bekannten Datei. So können Entwickelnde für ein solches Szenario.

Untergeordnete Ressourcen können jetzt Anmeldestatus für dieselbe Website festlegen

Bisher war in Chrome nur die Einstellung Anmeldung Status (für Beispiel mit dem Set-Login: logged-in-Header), wenn die Anfrage der Same-Origin mit allen Ancestors. Dies verhinderte Anmeldungen über die gleiche Website fetch() erfordert, dass der Anmeldestatus festgelegt wird.

Stellen Sie sich z. B. eine Website vor, auf der Nutzer ihren Nutzernamen und Passwort für idp.example, aber die Anmeldedaten werden an login.idp.example gesendet mit fetch(). Aufzeichnen des Anmeldestatus beim Browser mithilfe des Anmeldestatus Die API war nicht möglich, da die beiden Domains ursprungsübergreifend und auf derselben Website basieren.

Mit dieser Änderung haben wir die Anforderung an die Login Status API gelockert. die SameSite mit allen Ancestors und macht das obige Beispiel möglich, Der Anmeldestatus von login.idp.example mithilfe eines HTTP-Headers (Set-Login: logged-in).

Zusammenfassung

Über die Unsubscribe API kann FedCM jetzt die Verbindung zwischen RP und IdP trennen ohne Drittanbieter-Cookies zu verwenden. Rufen Sie dazu unter IdentityCredential.disconnect() in der RP. Mit dieser Funktion kann der Browser sendet eine Anfrage an den Endpunkt der Verbindung zum IdP, damit der IdP den Vorgang beenden kann. auf dem Server und dann im Browser.

Wir haben angekündigt, dass die /.well-known/web-identity-Prüfung beim RP übersprungen wird und der IdP ist zu Testzwecken am selben Standort. Außerdem ist es möglich, über einen HTTP-Antwortheader von derselben IdP-Unterressource erhalten, möglich.