FedCM-Updates: Ursprungstest der Button Mode API, CORS und SameSite

Eiji Kitamura

Ab Chrome 125 startet die Button Mode API einen Ursprungstest auf dem Computer. Mit der Button Mode API können Identitätsanbieter die FedCM API auch dann verwenden, wenn ihre Nutzer nach dem API-Aufruf keine aktiven IdP-Sitzungen haben. Nutzer können sich dann mit ihrem föderierten Konto auf einer Website anmelden, ohne zur IdP-Website weitergeleitet zu werden. Die FedCM-Benutzeroberfläche ist im Schaltflächenmodus auffälliger als die aus dem vorhandenen Widget-Ablauf, da sie durch eine Touch-Geste des Nutzers gesteuert wird und die Anmeldeabsicht des Nutzers besser widerspiegelt.

Button Mode API

Die FedCM-Benutzeroberfläche war als Widget verfügbar, das auf dem Computer in der oberen rechten Ecke angezeigt wird, oder als Ansicht am unteren Rand auf Mobilgeräten, sobald die API aufgerufen wird. Dies kann beispielsweise der Fall sein, wenn der Nutzer zur vertrauenden Partei (RPG) landet. Dies wird als Widget-Modus bezeichnet. Damit das Widget angezeigt werden kann, muss der Nutzer beim IdP angemeldet sein, bevor er zum RP landet. FedCM allein hatte keine verlässliche Möglichkeit, dass sich der Nutzer beim IdP anmelden konnte, bevor er sich mit dem beim IdP verfügbaren Konto beim RP anmelden konnte. FedCM wird demnächst eine Möglichkeit dafür einführen.

Im Widget-Modus wird in der Desktopversion von Chrome oben rechts ein Dialogfeld ohne Nutzeraktivierung angezeigt.

Die neue Button Mode API bietet einen neuen UI-Modus namens button. Im Gegensatz zum Widget-Modus soll der Schaltflächenmodus nicht sofort aufgerufen werden, wenn der Nutzer die RP erreicht. Sie soll stattdessen aufgerufen werden, wenn der Nutzer einen Anmeldevorgang initiiert, z. B. durch Klicken auf die Schaltfläche „Über IdP anmelden“.

Sobald die Schaltfläche gedrückt wird, prüft FedCM, ob der Nutzer beim IdP über einen Abruf zum Kontoendpunkt oder über einen im Browser gespeicherten Anmeldestatus angemeldet ist. Wenn der Nutzer noch nicht angemeldet ist, fordert FedCM den Nutzer auf, sich mit dem vom IdP über ein Pop-up-Fenster bereitgestellten login_url beim IdP anzumelden. Wenn der Browser weiß, dass der Nutzer bereits beim IdP angemeldet ist, oder sobald sich der Nutzer über das Pop-up-Fenster beim IdP anmeldet, öffnet FedCM ein modales Dialogfeld, in dem der Nutzer ein IdP-Konto für die Anmeldung auswählen kann. Durch die Auswahl eines Kontos kann sich der Nutzer mit dem IdP-Konto im RP anmelden.

Im Schaltflächenmodus wird in der Computerversion von Chrome oben in der Mitte ein modales Dialogfeld angezeigt.

Unter https://fedcm-rp-demo.glitch.me/button_flow kannst du Chrome 125 selbst ausprobieren.

Ein Nutzer meldet sich mithilfe der Button Mode API im RP an.

So verwenden Sie die Button Mode API:

• Aktiviert die experimentelle Funktion FedCmButtonMode in chrome://flags.
• Achten Sie darauf, die API für eine vorübergehende Nutzeraktivierung wie z. B. einen Schaltflächenklick aufzurufen.
• Rufen Sie die API mit dem Parameter mode so auf:

  return await navigator.credentials.get({
    identity: {
      providers: [{
        configURL: "https://idp.example/config.json",
        clientId: "123",
        nonce:"456",
      }],
      mode: "button"
    }
  });

Hinweis: Chrome unterstützt vorerst "button" nur in der neuen mode-Property. Andere Eigenschaften wie "widget" werden hinzugefügt, sobald diese Funktion in Chrome veröffentlicht wird.

Der Browser sendet einen neuen Parameter an den Endpunkt der ID-Assertion, der den Anfragetyp darstellt. Dazu wird mode=button eingefügt:

POST /fedcm_assertion_endpoint HTTP/1.1
Host: idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity
account_id=123&client_id=client1234&nonce=Ct60bD&disclosure_text_shown=true&is_auto_selected=false&mode=button

Hinweis :Wenn ein Fehler auftritt, reagiert der FedCM API-Aufruf mit dem Schaltflächenmodus sofort. Im Widget-Modus wird die Antwort absichtlich verzögert. Dies liegt daran, dass der Anmeldestatus des Nutzers beim IdP als private Informationen betrachtet wird und das Senden eines Fehlersignals bald dem RP einen Hinweis auf den IdP-Anmeldestatus des Nutzers gibt. Im Schaltflächenmodus wird der Nutzer jedoch aufgefordert, sich beim IdP anzumelden, ohne dass der IdP-Anmeldestatus des Nutzers im RP offengelegt werden muss.

Hinweis: Nutzer können den FedCM-Widget-Modus in den Chrome-Einstellungen deaktivieren. Dies hat keine Auswirkungen auf die Button Mode API, da die Anmeldeanfrage durch eine Nutzergeste initiiert wird und der Browser die Nutzer beim Abschließen des Anmeldevorgangs unterstützen sollte.

Andere Kontooption verwenden

Das RP kann Nutzern ermöglichen, in der Kontoauswahl "andere Konten zu verwenden", z. B. wenn IdPs mehrere Konten unterstützen oder das vorhandene Konto ersetzen.

So aktivieren Sie die Option zur Verwendung eines anderen Kontos:

• Aktivieren Sie die experimentelle Funktion FedCmUseOtherAccount in chrome://flags oder registrieren Sie den Ursprungstest der Button Mode API.
• Der IdP gibt in der IdP-Konfigurationsdatei Folgendes an:

{
  "accounts_endpoint" : ...,
  "modes: {
    "button": {
      "supports_use_other_account": true,
    }
  }
}

Am Ursprungstest teilnehmen

Sie können die Button Mode API lokal testen. Aktivieren Sie dazu in Chrome 125 oder höher ein Chrome-Flag chrome://flags#fedcm-button-mode.

IdPs können den Schaltflächenmodus auch aktivieren, indem sie einen Ursprungstest registrieren:

• Registrieren Sie einen Drittanbieter-Ursprungstest für den RP.

Mit Ursprungstests können Sie neue Funktionen ausprobieren und der Community für Webstandards Feedback zur Nutzerfreundlichkeit, Umsetzbarkeit und Effektivität geben. Weitere Informationen findest du im Leitfaden zu Ursprungstests für Webentwickler.

Der Ursprungstest der Button Mode API ist von Chrome 125 bis Chrome 127 verfügbar.

1. Rufe die Registrierungsseite für den Ursprungstest auf.
2. Klicken Sie auf die Schaltfläche Registrieren und füllen Sie das Formular aus, um ein Token anzufordern.
3. Geben Sie den Ursprung des IdP als Web Origin (Webursprung) ein.
4. Klicken Sie das Kästchen „Drittanbieter-Abgleich“ an, um das Token mit JavaScript bei anderen Ursprüngen zu injizieren.
5. Klicke auf Senden.
6. Betten Sie das ausgestellte Token auf der Website eines Drittanbieters ein.

Wenn Sie das Token auf der Website eines Drittanbieters einbetten möchten, fügen Sie den folgenden Code in die JavaScript-Bibliothek oder das SDK des IdP ein, die bzw. das vom Ursprung des IdP bereitgestellt wird.

const tokenElement = document.createElement('meta');
tokenElement.httpEquiv = 'origin-trial';
tokenElement.content = 'TOKEN_GOES_HERE';
document.head.appendChild(tokenElement);

Ersetzen Sie TOKEN_GOES_HERE durch Ihr eigenes Token.

Hinweis :Wenn die FedCM API vom RP und nicht über ein vom IdP geladenes Skript aufgerufen wird, muss der RP den Ursprung selbst registrieren und seinen Erstanbieter-Ursprungstest ausführen.

CORS und SameSite=None sind in Chrome 125 erforderlich

CORS

Ab Chrome 125 erzwingt Chrome CORS auf dem Endpunkt für die ID-Assertion.

CORS (Cross-Origin-Resource-Sharing) ist ein System, das aus übertragenden HTTP-Headern besteht. Dieses System bestimmt, ob Browser den Frontend-JavaScript-Code am Zugriff auf Antworten für ursprungsübergreifende Anfragen hindern. Der Endpunkt für ID-Assertions auf dem IdP-Server muss mit zusätzlichen Headern auf die Anfrage antworten. Hier ein Beispiel für einen Antwortheader auf eine Anfrage von https://fedcm-rp-demo.glitch.me:

Access-Control-Allow-Origin: https://fedcm-rp-demo.glitch.me
Access-Control-Allow-Credentials: true

Hinweis: Da Access-Control-Allow-Credentials auf „true“ gesetzt ist, muss Access-Control-Allow-Origin explizit eine Domain zurückgeben. Dabei kann kein durch * angegebenen Platzhalter verwendet werden.

SameSite=None

Der SameSite-Parameter des Cookies gibt an, ob das Cookie auf einen Erstanbieter- oder Website-Kontext beschränkt ist. Wenn Sie None als Cookie angeben, kann das Cookie an eine Drittanbieterdomain gesendet werden.

In FedCM sendet Chrome Cookies an den Endpunkt des Kontos, den Endpunkt für die ID-Assertion und den Endpunkt zum Trennen der Verbindung. Ab Chrome 125 sendet Chrome diese Anfragen mit Anmeldedaten nur mit Cookies, die explizit als SameSite=None gekennzeichnet sind.