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

Eiji Kitamura

Ab Chrome 122 ist die Unlock API für die Federated Credential Management API (FedCM) verfügbar. Mit der Interconnect API können vertrauende Parteien die Verbindung ihrer Nutzer vom Konto des Identitätsanbieters trennen, ohne Drittanbieter-Cookies zu verwenden. Außerdem gibt es einige Aktualisierungen am Same-Site-Umgang von FedCM.

API trennen

Wenn ein Nutzer über die Identitätsföderation ein Konto bei einer vertrauenden Partei (RP – der Website, die den Identitätsanbieter zur Authentifizierung verwendet) erstellt, zeichnet der Identitätsanbieter (IdP – der Dienst, der Authentifizierungs- und Kontoinformationen für andere Parteien bereitstellt) in der Regel die Verbindung auf seinem Server auf. Die gespeicherte Verbindung ermöglicht es dem IdP, die RPs, bei denen sich der Nutzer angemeldet hat, zu verfolgen und die Nutzung zu optimieren. Um beispielsweise die Nutzerfreundlichkeit zu verbessern, wenn der Nutzer später zum RP zurückkehrt, wird das Nutzerkonto mit dem IdP als zurückgegebenes Konto behandelt. Dies ermöglicht 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. Ein Vorgang zum Trennen der Verbindung ist jedoch authentifiziert und erfordert die IdP-Cookies. Wenn der Nutzer in einer Welt ohne Drittanbieter-Cookies den RP aufruft, gibt es keine Browser-API, mit der das RP die Verbindung zum IdP trennen könnte. Da mit einem bestimmten RP möglicherweise mehrere IdP-Konten desselben IdPs verknüpft sind, muss für den Ablauf der Verbindung zum Trennen des Kontos angegeben werden, zu welchem Konto die Verbindung getrennt wird.

Mit der Verbindungs-API kann der Nutzer das IdP-Konto vom RP im Browser und auf dem IdP-Server trennen, indem er es dem angegebenen Endpunkt signalisiert. Der Nutzer muss die Identitätsföderation mithilfe der Federated Credential Management API (FedCM) durchlaufen haben. Nachdem die Verbindung des Nutzers getrennt wurde, wird er bei der nächsten Anmeldung im RP über den IdP als neuer Nutzer behandelt.

IdP vom RP trennen

Wenn sich ein Nutzer zuvor mit dem IdP über FedCM im RP angemeldet hat, wird die Beziehung vom Browser lokal als Liste der verbundenen Konten gespeichert. Das RP kann durch Aufrufen der Funktion IdentityCredential.disconnect() eine Trennung der Verbindung initiieren. Diese Funktion kann von einem RP-Frame auf oberster Ebene aufgerufen werden. Das RP muss einen configURL, den clientId, den er unter dem IdP verwendet, und ein accountHint übergeben, damit die Verbindung zum IdP getrennt wird. Ein Kontohinweis kann ein beliebiger String sein, solange der Endpunkt der Verknüpfung das Konto identifizieren kann. Das kann z. B. eine E-Mail-Adresse oder Nutzer-ID sein, die nicht unbedingt mit der Konto-ID übereinstimmt, die der Endpunkt der Kontoliste 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 ein Promise zurück. Dieses Promise kann aus folgenden Gründen eine Ausnahme ausgeben:

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

Wenn der Endpunkt zum Trennen der Verbindung des IdP eine Antwort zurückgibt, werden der RP und der IdP vom Browser getrennt und das Promise wird aufgelöst. Die Nutzerkonten, die die Verbindung trennen, sind in der Antwort vom getrennten Endpunkt angegeben.

IdP-Konfigurationsdatei einrichten

Zur Unterstützung der Getrenn-API muss der IdP einen Endpunkt zum Trennen der Verbindung unterstützen und das Attribut disconnect_endpoint sowie seinen Pfad in seiner IdP-Konfigurationsdatei angeben.

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

Verbindung des Kontos am Endpunkt trennen

Wenn IdentityCredential.disconnect() aufgerufen wird, sendet der Browser eine ursprungsübergreifende POST-Anfrage mit Cookies und dem Inhaltstyp application/x-www-form-urlencoded an diesen Endpunkt zum Trennen der Verbindung mit den folgenden Informationen:

Property Beschreibung
account_hint 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 dem Empfang der Anfrage sollte der IdP-Server folgende Schritte ausführen:

  1. Antworten Sie auf die Anfrage mit CORS (Cross-Origin Resource Sharing).
  2. Prüfen Sie, ob die Anfrage einen Sec-Fetch-Dest: webidentity-HTTP-Header enthält.
  3. Gleicht den Origin-Header mit dem RP-Ursprung ab, der durch client_id bestimmt wird. Lehnen Sie sie ab, wenn sie nicht übereinstimmen.
  4. Suchen Sie das Konto, das mit account_hint übereinstimmt.
  5. Heben Sie die Verbindung des Nutzerkontos aus der Liste der verbundenen Konten von RP auf.
  6. dem Browser mit dem account_id des identifizierten Nutzers in einem JSON-Format antworten.

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 der RP und der IdP auf derselben Website befinden

Bei der Entwicklung eines FedCM-Systems können das Testen oder Staging von RP-Serverdomains die Subdomains des IdP-Servers in der Produktion sein. Der IdP-Produktionsserver befindet sich beispielsweise unter idp.example und sowohl der Staging-RP-Server als auch der IdP-Staging-Server befindet sich unter staging.idp.example. Da die bekannte Datei jedoch im Stammverzeichnis der eTLD+1 des IdP-Servers platziert werden muss, muss sie sich im idp.example/.well-known/web-identity befinden und der Produktionsserver sein. Da es Entwickler*innen nicht unbedingt möglich ist, während der Entwicklung Dateien in der Produktionsumgebung zu platzieren, wird verhindert, dass sie FedCM testen.

Wenn die RP-Domain und die IdP-Domain identisch sind, überspringt Chrome ab Chrome 122 die Prüfung der bekannten Datei. Auf diese Weise können Entwickler in einem solchen Szenario testen.

Untergeordnete Ressourcen können jetzt den Anmeldestatus auf derselben Website festlegen

Bisher war in Chrome das Festlegen des Anmeldestatus (z. B. Verwendung des Headers Set-Login: logged-in) nur dann zulässig, wenn die Anfrage bei allen Ancestors demselben Ursprung ist. Dies verhinderte Anmeldungen über Same-Site- fetch()-Anfragen, bei denen der Anmeldestatus festgelegt wurde.

Stellen Sie sich beispielsweise eine Website vor, auf der Nutzer ihren Nutzernamen und ihr Passwort auf idp.example eingeben können, die Anmeldedaten aber mit fetch() an login.idp.example gepostet werden. Der Anmeldestatus mit der Login Status API konnte nicht im Browser aufgezeichnet werden, da die beiden Domains ursprungsübergreifend und von derselben Website stammen.

Mit dieser Änderung haben wir die Anforderung gelockert, dass die Login Status API dieselbe Website wie bei allen Ancestors sein muss. Im obigen Beispiel kann der Anmeldestatus von login.idp.example mithilfe eines HTTP-Headers (Set-Login: logged-in) festgelegt werden.

Zusammenfassung

Mithilfe der Verbindungs-API kann FedCM nun den RP vom IdP trennen, ohne auf Drittanbieter-Cookies zurückgreifen zu müssen. Rufe dazu IdentityCredential.disconnect() im RP auf. Mit dieser Funktion sendet der Browser eine Anfrage an den IdP-Endpunkt zum Trennen der Verbindung, damit der IdP die Verbindung auf dem Server und dann auf dem Browser beenden kann.

Wir haben angekündigt, dass die /.well-known/web-identity-Prüfung zu Testzwecken übersprungen wird, wenn der RP und der IdP am selben Standort sind. Es ist jetzt auch möglich, einen Anmeldestatus über einen HTTP-Antwortheader von derselben Website-IdP-Unterressource festzulegen.