Aktualizacje FedCM: odłączenie interfejsu API i 2 aktualizacje

Eiji Kitamura

Od wersji Chrome 122 dostępny jest interfejs Disconnect API dla interfejsu Federated Credential Management API (FedCM). Interfejs Disconnect API umożliwia stronom trzecim odłączanie użytkowników od konta dostawcy tożsamości bez korzystania z plików cookie innych firm. Wprowadziliśmy też kilka zmian w obsługiwaniu przez FedCM tej samej witryny.

Odłączanie interfejsu API

Gdy użytkownik utworzy konto w jednostce uzależnionej (czyli witrynie korzystającej z dostawcy tożsamości do uwierzytelniania) przy użyciu federacji tożsamości, dostawca tożsamości (czyli usługa udostępniająca innym podmiotom uwierzytelnianie i informacje o koncie) zwykle rejestruje połączenie na swoim serwerze. Zapisana połączenie umożliwia dostawcy tożsamości śledzenie RP, w których użytkownik się zalogował, oraz optymalizowanie jego wrażeń. Na przykład, aby zapewnić większą wygodę, gdy użytkownik wróci do RP, konto użytkownika w dostawcy tożsamości jest traktowane jako powracające, co umożliwia korzystanie z funkcji takich jak automatyczna ponowna uwierzytelnianie i przyciski z personalizowanymi przyciskami pokazującymi używane konto.

Czasami dostawcy tożsamości oferują interfejs API do odłączania konta od RP. Proces odłączania wymaga jednak uwierzytelnienia i wykorzystuje pliki cookie dostawcy tożsamości. W świecie bez plików cookie innych firm, gdy użytkownik odwiedza stronę z RPA, nie ma interfejsu API w przeglądarce, który mógłby odłączyć się od dostawcy tożsamości. Ponieważ z danym RP może być połączonych wiele kont IdP tego samego dostawcy, proces odłączania wymaga znajomości konta, które ma zostać odłączone.

Interfejs API do odłączania umożliwia użytkownikowi odłączenie konta dostawcy tożsamości od RP w przeglądarce i na serwerze dostawcy tożsamości, sygnalizując to na określonym punkcie końcowym. Użytkownik musi przejść przez federację tożsamości za pomocą interfejsu API do zarządzania danymi logowania sfederowanego (FedCM). Gdy użytkownik zostanie odłączony, przy następnej próbie zalogowania się w usłudze RP za pomocą dostawcy tożsamości będzie on traktowany jako nowy użytkownik.

Odłącz dostawcę tożsamości od RP

Jeśli użytkownik zalogował się wcześniej w RP za pomocą dostawcy tożsamości przez FedCM, przeglądarka zapamięta tę relację lokalnie jako listę połączonych kont. RP może zainicjować odłączenie przez wywołanie funkcji IdentityCredential.disconnect(). Tę funkcję można wywołać z ramki RP najwyższego poziomu. RP musi przekazywać configURL, clientId, którego używa w ramach dostawcy tożsamości, oraz accountHint, aby dostawca tożsamości został odłączona. Wskazówka dotycząca konta może być dowolnym ciągiem znaków, o ile punkt końcowy funkcji rozłączania może zidentyfikować konto, na przykład adres e-mail lub identyfikator użytkownika, który nie musi być identyczny z identyfikatorem konta podanym przez punkt końcowy listy kont:

// 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() zwraca wartość Promise. Ta obietnica może spowodować wyjątek z tych powodów:

  • Użytkownik nie zalogował się w usłudze RP, korzystając z dostawcy tożsamości przez FedCM.
  • Interfejs API jest wywoływany z elementu iframe bez zasady uprawnień FedCM.
  • Adres configURL jest nieprawidłowy lub nie ma punktu końcowego odłączania.
  • Test zgodności ze standardem Content Security Policy (CSP) kończy się niepowodzeniem.
  • Istnieje oczekująca prośba o rozłączenie.
  • Użytkownik wyłączył FedCM w ustawieniach przeglądarki.

Gdy punkt końcowy usługi IdP do rozłączania zwraca odpowiedź, RP i IdP są rozłączane w przeglądarce, a obietnica jest realizowana. Odłączanie kont użytkowników jest określone w odpowiedzi z punktu końcowego rozłączania.

Konfigurowanie pliku konfiguracji dostawcy tożsamości

Aby interfejs API odłączania był obsługiwany, dostawca tożsamości musi obsługiwać punkt końcowy odłączania oraz podać właściwość disconnect_endpoint i jej ścieżkę w pliku konfiguracji dostawcy tożsamości.

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

Odłączanie konta w rozłączonym punkcie końcowym

Wywołując funkcję IdentityCredential.disconnect(), przeglądarka wysyła żądanie POST z innych domen z plikami cookie i typem treści application/x-www-form-urlencoded do tego punktu końcowego rozłączania z następującymi informacjami:

Właściwość Opis
account_hint Wskazówka dotycząca konta dostawcy tożsamości.
client_id Identyfikator klienta 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

Po otrzymaniu żądania serwer dostawcy tożsamości powinien:

  1. Odpowiedz na żądanie za pomocą CORS (współdzielenie zasobów pomiędzy serwerami z różnych domen).
  2. Sprawdź, czy żądanie zawiera nagłówek HTTP Sec-Fetch-Dest: webidentity.
  3. Dopasuj nagłówek Origin do źródła RP określonego przez client_id. Odrzuć, jeśli nie są zgodne.
  4. Znajdź konto, które odpowiada account_hint.
  5. Odłącz konto użytkownika od listy połączonych kont objętych ograniczeniami.
  6. W odpowiedzi prześlij przeglądarce plik account_id zidentyfikowanego użytkownika w formacie JSON.

Przykładowa odpowiedź w postaci ładunku JSON wygląda tak:

{
  "account_id": "account456"
}

Jeśli dostawca tożsamości chce, aby przeglądarka odłączyła wszystkie konta powiązane z reprezentantem, prześlij ciąg znaków, który nie pasuje do żadnego identyfikatora konta, na przykład "*".

Sprawdzanie /.well-known/web-identity jest teraz pomijane, gdy RP i IdP znajdują się w tej samej witrynie.

Podczas tworzenia systemu FedCM testowanie lub testowanie domen serwera RP może być subdomenami produkcyjnego serwera dostawcy tożsamości. Na przykład serwer produkcyjny dostawcy tożsamości ma adres idp.example, a serwer produkcyjny dostawcy usług i serwer produkcyjny dostawcy tożsamości mają adres staging.idp.example. Plik well-known musi jednak znajdować się w katalogu głównym eTLD+1 serwera dostawcy tożsamości, czyli w kataloguidp.example/.well-known/web-identity na serwerze produkcyjnym. Deweloperzy nie mogą umieszczać plików w środowisku produkcyjnym w trakcie opracowywania, dlatego nie mogą testować FedCM.

Od wersji 122 Chrome nie sprawdza pliku well-known, jeśli domena RP i domena dostawcy tożsamości są takie same. Dzięki temu deweloperzy będą mogli przetestować takie scenariusze.

Zasoby podrzędne mogą teraz ustawiać stan logowania w tej samej witrynie

Wcześniej Chrome zezwalało na ustawianie tylko stanu logowania (np. za pomocą nagłówka Set-Login: logged-in), gdy żądanie jest z tego samego źródła ze wszystkimi przodkami. W rezultacie zablokowano logowanie się przez żądanie ustawienia stanu logowania z tej samej witryny fetch().

Wyobraź sobie np. witrynę, która pozwala użytkownikom wpisać nazwę użytkownika i hasło na stronie idp.example, ale dane logowania są wysyłane na stronę login.idp.example z adresem fetch(). Nie można było zapisać stanu logowania w przeglądarce za pomocą interfejsu API stanu logowania, ponieważ te 2 domeny należą do różnych źródeł i znajdują się w tej samej witrynie.

Dzięki tej zmianie nie trzeba już, aby interfejs API stanu logowania był w tej samej witrynie ze wszystkimi poprzednikami. Dzięki temu w przykładzie powyżej można ustawić stan logowania login.idp.example za pomocą nagłówka HTTP (Set-Login: logged-in).

Podsumowanie

Za pomocą interfejsu Odłącz API usługa FedCM może teraz odłączyć RP od dostawcy tożsamości bez korzystania z plików cookie innych firm. Aby to zrobić, wywołaj IdentityCredential.disconnect() w RP. W ramach tej funkcji przeglądarka wysyła żądanie do punktu końcowego dostawcy tożsamości, aby ten mógł zakończyć połączenie na serwerze, a następnie w przeglądarce.

Ogłosiliśmy na potrzeby testów, że sprawdzanie /.well-known/web-identity jest pomijane, gdy RP i dostawca tożsamości znajdują się w tej samej witrynie. Obecnie możliwe jest też ustawianie stanu logowania za pomocą nagłówka odpowiedzi HTTP z zasobu podrzędnego dostawcy tożsamości tej samej witryny.