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 bei der SameSite-Verarbeitung in FedCM.
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 Trennen der Verbindung wird 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öderierung mit 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 des IdP vom 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 der obersten Ebene aufgerufen werden. Der RP muss eine configURL, die clientId, die er beim IdP verwendet, und eine accountHint übergeben, damit die Verbindung zum IdP getrennt wird. 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 eine Promise zurück. Dieses Versprechen kann aus folgenden Gründen eine Ausnahme auslösen:
- Der Nutzer hat sich nicht über den IdP über FedCM 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 IdPs eine Antwort zurückgibt, werden die RP und der IdP im Browser getrennt und das Promise wird aufgelöst. Die Nutzerkonten, deren Verbindung getrennt werden soll, werden in der Antwort vom Disconnect-Endpunkt 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 das Aufrufen von IdentityCredential.disconnect() sendet der Browser eine POST-Anfrage mit Cookies und dem Inhaltstyp application/x-www-form-urlencoded an diesen Disconnect-Endpunkt mit den folgenden 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:
- Antworten Sie mit CORS (Cross-Origin Resource Sharing) auf die Anfrage.
- Prüfen Sie, ob die Anfrage einen
Sec-Fetch-Dest: webidentity-HTTP-Header enthält. - Vergleiche den
Origin-Header mit dem vomclient_idbestimmten RP-Ursprung. Lehnen Sie sie ab, wenn sie nicht übereinstimmen. - Suchen Sie nach dem Konto, das der
account_hintentspricht. - Trennen Sie die Verknüpfung des Nutzerkontos mit der Liste der verknüpften Konten des RP.
- Antworte dem Browser mit der
account_iddes identifizierten Nutzers im JSON-Format.
Eine Beispiel-JSON-Nutzlast für eine Antwort sieht so aus:
{
"account_id": "account456"
}
Wenn der IdP möchte, dass der Browser stattdessen alle mit dem RP verknüpften Konten trennt, geben Sie einen String an, 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.
Bei der Entwicklung eines FedCM-Systems können Test- oder Staging-RP-Serverdomains die Unterdomains des Produktions-IdP-Servers sein. Angenommen, der Produktions-IdP-Server befindet sich unter idp.example und sowohl der RP-Server als auch der IdP-Server für das Staging befinden sich unter staging.idp.example. Da die Well-Known-Datei jedoch im Stammverzeichnis des eTLD+1 des Identitätsanbieterservers abgelegt werden muss, muss sie sich unter idp.example/.well-known/web-identity befinden und es muss sich um den Produktionsserver handeln. Da es für Entwickler nicht unbedingt möglich ist, während der Entwicklung Dateien in der Produktionsumgebung zu platzieren, können sie FedCM nicht testen.
Ab Chrome 122 wird die Prüfung der bekannten Datei übersprungen, wenn die RP-Domain und die IdP-Domain identisch sind. So können Entwickler in einem solchen Szenario testen.
Für untergeordnete Ressourcen kann jetzt der Anmeldestatus für dieselbe Website festgelegt werden
Bisher war es in Chrome nur möglich, den Anmeldestatus (z. B. mithilfe der Set-Login: logged-in-Header-Zeile) festzulegen, wenn die Anfrage derselben Quelle wie alle übergeordneten Elemente entstammt. Dadurch wurden Anmeldungen über die websiteübergreifenden
fetch()-Anfragen verhindert, die den Anmeldestatus festlegen.
Angenommen, auf einer Website können Nutzer ihren Nutzernamen und ihr Passwort unter idp.example eingeben, die Anmeldedaten werden aber mit fetch() unter login.idp.example gepostet. Es war nicht möglich, den Anmeldestatus mit der Login Status API im Browser zu erfassen, da die beiden Domains unterschiedliche Ursprünge haben und sich auf derselben Website befinden.
Durch diese Änderung haben wir die Anforderung gelockert, dass die Login Status API für alle übergeordneten Elemente 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 zwischen RP und IdP trennen, ohne Drittanbieter-Cookies zu verwenden. Rufen Sie dazu IdentityCredential.disconnect() auf dem RP auf. Bei dieser Funktion sendet der Browser eine Anfrage an den Disconnect-Endpunkt des Identitätsanbieters, damit der Identitätsanbieter 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.