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

Eiji Kitamura

Od wersji Chrome 122 dostępny jest interfejs Disconnect API do obsługi 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 witryn na tym samym koncie w ramach FedCM.

Odłączanie interfejsu API

Gdy użytkownik tworzy konto w witrynie strony trzeciej (RP – witryny korzystającej z usługi dostawcy tożsamości w celu uwierzytelniania) za pomocą federacji tożsamości, dostawca tożsamości (IdP – usługi, która dostarcza informacje o uwierzytelnieniu i koncie innym stronom) zwykle rejestruje połączenie na swoim serwerze. Zapisana połączenie pozwala dostawcy tożsamości śledzić RP, w których użytkownik się zalogował, i optymalizować jego wrażenia. Na przykład, aby zapewnić lepsze wrażenia, 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 udostępniają interfejs API do odłączania konta od dostawcy usług. Jednak proces odłączania wymaga uwierzytelnienia i plików cookie dostawcy tożsamości. W świecie bez plików cookie innych firm, gdy użytkownik odwiedza RP, nie ma interfejsu API przeglądarki, za pomocą którego RP mógłby się rozłączyć z dostawcą tożsamości. Ponieważ z danym RP może być połączonych wiele kont IdP tego samego dostawcy, proces odłączania wymaga podania, które konto ma zostać odłączone.

Interfejs API funkcji rozłączenia 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ść proces federacji tożsamości przy użyciu interfejsu FedCM API (Federated Credential Management). 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 usłudze 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ć rozłączenie, wywołując funkcję IdentityCredential.disconnect(). Tę funkcję można wywołać z ramki RP najwyższego poziomu. RP musi przekazać configURL, clientId, którego używa w ramach dostawcy tożsamości, oraz accountHint, aby można było odłączyć dostawcę tożsamości. 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 FedCM i dostawcy tożsamości.
• Interfejs API jest wywoływany z poziomu elementu iframe bez zasad uprawnień FedCM.
• Adres URL konfiguracji jest nieprawidłowy lub nie ma punktu końcowego odłączenia.
• Nie udało się sprawdzić standardu Content Security Policy (CSP).
• Oczekuje 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. Konta użytkowników, które mają zostać odłączone, są określone w odpowiedzi z punktu końcowego funkcji disconnect.

Konfigurowanie pliku konfiguracyjnego dostawcy tożsamości

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

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

Odłączanie konta w punkcie końcowym odłączenia

Gdy wywołasz IdentityCredential.disconnect(), przeglądarka wysyła żądanie POST z plikami cookie i typem treści application/x-www-form-urlencoded do tego punktu końcowego z użyciem tych informacji:

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 IdP 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 się nie zgadzają.
4. Znajdź konto, które odpowiada account_hint.
5. Odłącz konto użytkownika z listy połączonych kont RP.
6. Prześlij do przeglądarki account_id zidentyfikowanego użytkownika w formacie JSON.

Przykładowy ładunek JSON odpowiedzi 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 domeny testowe lub domeny serwera RP mogą być poddomenami produkcyjnego serwera IdP. 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. Podczas tworzenia aplikacji programiści nie zawsze mogą umieszczać pliki w środowisku produkcyjnym, co uniemożliwia im testowanie 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 na tej samej stronie

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 poprzednikami. Zapobiegało to logowaniu się za pomocą żądań fetch() w tej samej witrynie, które ustawiają stan logowania.

Wyobraź sobie na przykład 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 zmodyfikowaliśmy wymagania dotyczące interfejsu API stanu logowania, aby znajdował się w tym samym miejscu co wszystkie jego przodkowie, i umożliwiliśmy w tym przykładzie ustawienie stanu logowania login.idp.example za pomocą nagłówka HTTP (Set-Login: logged-in).

Podsumowanie

Dzięki interfejsowi Disconnect API FedCM może teraz odłączać stronę zależną od dostawcy tożsamości bez używania plików cookie innych firm. Aby to zrobić, wybierz IdentityCredential.disconnect() na RP. W ramach tej funkcji przeglądarka wysyła żądanie do punktu odłączenia dostawcy tożsamości, aby dostawca mógł zakończyć połączenie na serwerze, a następnie w przeglądarce.

Ogłosiliśmy, że na potrzeby testów pomijamy sprawdzanie /.well-known/web-identity, gdy RP i IdP znajdują się w tej samej witrynie. Teraz można też ustawiać stan logowania za pomocą nagłówka odpowiedzi HTTP z podresursu w ramach tej samej witryny.