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

Eiji Kitamura

Ab Chrome 122 ist die Disconnect API für die Federated Credential Management API (FedCM) verfügbar. Mit der Disconnect API können vertrauende Seiten ihre Nutzer vom Konto des Identitätsanbieters trennen, ohne Drittanbieter-Cookies zu verwenden. Außerdem gibt es einige Änderungen an der FedCM-Umgang mit Same-Site-Verarbeitung.

API-Verbindung trennen

Wenn ein Nutzer über die Identitätsfederation ein Konto bei einer vertrauenden Partei (RP, die Website, die den Identitätsanbieter zur Authentifizierung verwendet) erstellt, zeichnet der Identitätsanbieter (IdP, der Dienst, der anderen Parteien Authentifizierungs- und Kontoinformationen zur Verfügung stellt) die Verbindung in der Regel auf seinem Server auf. Über die gespeicherte Verbindung kann der IdP RPs im Blick behalten, bei denen sich der Nutzer angemeldet hat, und die Nutzerfreundlichkeit optimieren. So wird beispielsweise die Nutzererfahrung verbessert, wenn der Nutzer später zum RP zurückkehrt. Das Nutzerkonto beim IdP wird dann als wiederkehrendes Konto behandelt, was Funktionen wie die automatische erneute Authentifizierung und personalisierte Schaltflächen ermöglicht, die das verwendete Konto anzeigen.

Manchmal bieten Identitätsanbieter eine API an, um die Verknüpfung des Kontos mit einem RP aufzuheben. Ein Ablauf zum Aufheben der Verbindung ist jedoch authentifiziert und erfordert die IdP-Cookies. In einer Welt ohne Drittanbieter-Cookies gibt es keine Browser-API, über die die RP die Verbindung zum IdP trennen kann, wenn der Nutzer die RP besucht. Da es mehrere IdP-Konten desselben IdP geben kann, die mit einem bestimmten RP verknüpft sind, muss beim Trennen der Verbindung bekannt sein, welches Konto getrennt werden soll.

Mit der Disconnect API kann der Nutzer die Verbindung des IdP-Kontos zum RP sowohl im Browser als auch auf dem IdP-Server trennen, indem er dies an den angegebenen Endpunkt signalisiert. Der Nutzer muss die Identitätsföderation mithilfe der Federated Credential Management API (FedCM) durchlaufen haben. Sobald die Verbindung des Nutzers getrennt wurde, wird er beim nächsten Versuch, sich über den IdP beim RP anzumelden, als neuer Nutzer behandelt.

Verbindung zwischen dem IdP und dem RP trennen

Wenn sich ein Nutzer zuvor über den Identitätsanbieter über FedCM beim RP angemeldet hat, wird die Beziehung lokal im Browser als Liste der verbundenen Konten gespeichert. Der RP kann eine Verbindungsunterbrechung durch Aufrufen der Funktion IdentityCredential.disconnect() initiieren. Diese Funktion kann von einem RP-Frame auf oberster Ebene aufgerufen werden. Die RP muss eine configURL, die clientId, die unter dem IdP verwendet wird, und eine accountHint für den zu trennenden IdP übergeben. Ein Kontohinweis kann ein beliebiger String sein, solange der Disconnect-Endpunkt das Konto identifizieren kann, z. B. eine E-Mail-Adresse oder Nutzer-ID, die nicht unbedingt mit der Konto-ID übereinstimmen muss, die der Kontolisten-Endpunkt angegeben hat:

// 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 kann aus folgenden Gründen eine Ausnahme auslösen:

• Der Nutzer hat sich nicht über FedCM mit dem IdP beim RP angemeldet.
• Die API wird innerhalb eines iFrames ohne FedCM-Berechtigungsrichtlinie aufgerufen.
• Die configURL ist ungültig oder der Disconnect-Endpunkt fehlt.
• Die CSP-Prüfung (Content Security Policy) ist fehlgeschlagen.
• Es gibt eine ausstehende Anfrage zur Kontotrennung.
• Der Nutzer hat FedCM in den Browsereinstellungen deaktiviert.

Wenn der Disconnect-Endpunkt des IdP eine Antwort zurückgibt, werden die RP und der IdP im Browser getrennt und das Promise wird aufgelöst. Welche Nutzerkonten getrennt werden, wird in der Antwort vom Endpunkt, über den die Verbindung getrennt wird angegeben.

IdP-Konfigurationsdatei einrichten

Damit die Disconnect API unterstützt werden kann, muss der Identitätsanbieter einen Disconnect-Endpunkt unterstützen und die disconnect_endpoint-Eigenschaft und ihren Pfad in der IdP-Konfigurationsdatei angeben.

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

Konto über den Endpunkt zum Trennen trennen

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

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. Antworten Sie mit CORS (Cross-Origin Resource Sharing) auf die Anfrage.
2. Prüfe, ob die Anfrage einen Sec-Fetch-Dest: webidentity-HTTP-Header enthält.
3. Vergleiche den Origin-Header mit dem vom client_id bestimmten RP-Ursprung. 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. Sie antworten dem Browser mit der account_id des identifizierten Nutzers im JSON-Format.

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

{
  "account_id": "account456"
}

Wenn der IdP möchte, dass der Browser stattdessen alle mit dem RP verknüpften Konten trennt, übergeben Sie einen String, der mit keiner Konto-ID übereinstimmt, z. B. "*".

Die Prüfung von /.well-known/web-identity wird jetzt übersprungen, wenn sich RP und IdP auf derselben Website befinden.

Beim Entwickeln eines FedCM-Systems können das Testen oder Staging von RP-Serverdomains die Subdomains des Produktions-IdP-Servers sein. Beispielsweise befindet sich der Produktions-IdP-Server unter idp.example und sowohl der Staging-RP-Server als auch der Staging-IdP-Server unter staging.idp.example. Da die bekannte Datei jedoch im Stammverzeichnis der eTLD+1 des IdP-Servers abgelegt werden muss, muss sie sich unter idp.example/.well-known/web-identity befinden und den Produktionsserver sein. Da Entwickler Dateien während der Entwicklung nicht in der Produktionsumgebung ablegen können, können sie FedCM nicht testen.

Ab Chrome 122 wird die Prüfung der .well-known-Datei übersprungen, wenn die RP-Domain und die IdP-Domain identisch sind. Auf diese Weise können Entwickler in einem solchen Szenario Tests durchführen.

Für Unterressourcen kann jetzt der Anmeldestatus für dieselbe Website festgelegt werden

Bisher war es in Chrome nur möglich, den Anmeldestatus festzulegen (z. B. mit dem Header Set-Login: logged-in), wenn die Anfrage bei allen Ancestors denselben Ursprung hat. Dadurch wurden Anmeldungen über die websiteübergreifendenfetch()-Anfragen verhindert, die den Anmeldestatus festlegen.

Stellen Sie sich beispielsweise eine Website vor, auf der Nutzer ihren Nutzernamen und ihr Passwort auf idp.example eingeben können, die Anmeldedaten werden jedoch mit fetch() an login.idp.example gesendet. Die Anmeldung des Anmeldestatus im Browser mithilfe der Login Status API war nicht möglich, da die beiden Domains ursprungsübergreifend und zur selben Website gehören.

Durch diese Änderung haben wir die Anforderung gelockert, dass die Login Status API mit allen übergeordneten Elementen auf derselben Website sein muss. Im obigen Beispiel kann der Anmeldestatus von login.idp.example jetzt über einen HTTP-Header (Set-Login: logged-in) festgelegt werden.

Zusammenfassung

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

Wir haben angekündigt, dass die /.well-known/web-identity-Prüfung zu Testzwecken übersprungen wird, wenn sich RP und IdP auf derselben Website befinden. Außerdem ist es jetzt möglich, den Anmeldestatus über einen HTTP-Antwortheader aus der IdP-Unterressource derselben Website festzulegen.