Od wersji Chrome 122 dostępny jest Unlink API dla Federated Credential Management API (FedCM). Interfejs łączenie interfejsu API umożliwia podmiotom uzależnionym 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łudze zasad FedCM w tej samej witrynie.
Odłącz API
Gdy użytkownik tworzy konto na stronie uzależnionej (RP), czyli w witrynie, która korzysta z dostawcy tożsamości do uwierzytelniania, za pomocą federacji tożsamości, dostawca tożsamości (usługa zapewniająca uwierzytelnianie i informacje o koncie innym podmiotom) zazwyczaj rejestruje połączenie na swoim serwerze. Zapisane połączenie pozwala dostawcy tożsamości śledzić grupy RP, w których zalogował się użytkownik, i optymalizować jego działanie. Na przykład, aby zapewnić sobie lepsze wrażenia po powrocie do grupy objętej ograniczeniami, konto użytkownika u dostawcy tożsamości jest traktowane jak konto powracające, co umożliwia takie funkcje jak automatyczne ponowne uwierzytelnianie i spersonalizowane przyciski pokazujące używane konto.
Czasami dostawcy tożsamości oferują interfejs API, który pozwala odłączyć konto od grupy objętej ograniczeniami. Proces rozłączania jest jednak uwierzytelniany i wymaga 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, w którym platforma RP mogłaby odłączyć się od dostawcy tożsamości. Z konkretnym dostawcą tożsamości może być powiązanych wiele kont dostawcy tożsamości, więc proces rozłączania wymaga informacji o tym, które konto zostało odłączone.
Interfejs Rozłącz API umożliwia użytkownikowi odłączanie konta dostawcy tożsamości od witryny objętej ograniczeniami w przeglądarce oraz na serwerze dostawcy tożsamości przez sygnalizowanie tego konta do określonego punktu końcowego. Użytkownik musi przejść przez federację tożsamości za pomocą interfejsu Federated Credential Management API (FedCM). Gdy użytkownik zostanie rozłączony, przy następnej próbie zalogowania się w grupie objętej ograniczeniami przy użyciu dostawcy tożsamości zostanie potraktowany jako nowy użytkownik.
Odłącz dostawcę tożsamości od RP
Jeśli użytkownik wcześniej zalogował się w grupie objętej ograniczeniami przy użyciu dostawcy tożsamości w FedCM, przeglądarka zapisze relację z nią lokalnie na liście połączonych kont. Grupa z ograniczonym dostępem może zainicjować rozłączenie przez wywołanie funkcji IdentityCredential.disconnect(). Tę funkcję można wywołać z klatki RP najwyższego poziomu. Aby dostawca tożsamości został odłączony, strona z grupą obwodową musi zweryfikować configURL, clientId używany u dostawcy tożsamości oraz accountHint. Wskazówka dotycząca konta może być dowolnym ciągiem znaków, o ile punkt końcowy odłączania może zidentyfikować konto. Może to być na przykład adres e-mail lub identyfikator użytkownika, który niekoniecznie musi odpowiadać identyfikatorowi konta dostarczonemu 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 stanowić wyjątek z tych powodów:
- Użytkownik nie zalogował się w grupie objętej ograniczeniami przy użyciu dostawcy tożsamości w FedCM.
- Interfejs API jest wywoływany z elementu iframe bez zasady uprawnień FedCM.
- Element configURL jest nieprawidłowy lub nie ma punktu końcowego odłączenia.
- Test Content Security Policy (CSP) kończy się niepowodzeniem.
- Masz oczekujące żądanie rozłączenia.
- Użytkownik wyłączył FedCM w ustawieniach przeglądarki.
Gdy punkt końcowy odłączenia dostawcy tożsamości zwraca odpowiedź, RP i dostawca tożsamości w przeglądarce rozłączą się, a obietnica zostanie zrealizowana. Rozłączanie kont użytkowników jest określone w odpowiedzi z punktu końcowego rozłączenia.
Skonfiguruj plik konfiguracyjny dostawcy tożsamości
Aby obsługiwać interfejs Rozłącz API, dostawca tożsamości musi obsługiwać punkt końcowy i podać właściwość disconnect_endpoint i jej ścieżkę w pliku konfiguracyjnym dostawcy tożsamości.
{
"accounts_endpoint": "/accounts",
"id_assertion_endpoint": "/assertion",
...
"disconnect_endpoint: "/disconnect"
}
Odłącz konto w punkcie końcowym odłączania
Wywołując IdentityCredential.disconnect(), przeglądarka wysyła do tego rozłączonego punktu końcowego żądanie POST z innych domen, zawierające pliki cookie i typ treści application/x-www-form-urlencoded, wraz z tymi informacjami:
| Właściwość | Opis |
|---|---|
account_hint |
Wskazówka dotycząca konta dostawcy tożsamości. |
client_id |
Identyfikator klienta strony objętej ograniczeniami. |
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:
- Odpowiedz na żądanie za pomocą funkcji CORS (Udostępnianie zasobów w różnych źródłach).
- Sprawdź, czy żądanie zawiera nagłówek HTTP
Sec-Fetch-Dest: webidentity. - Dopasuj nagłówek
Origindo punktu początkowego RP określonego przezclient_id. Odrzuć, jeśli nie pasują. - Znajdź konto pasujące do zapytania
account_hint. - Odłącz konto użytkownika na liście połączonych kont objętych ograniczeniami.
- Odpowiedz przeglądarce, podając
account_idwskazanego 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 rozłączyła wszystkie konta powiązane z grupą objętą ograniczeniami, podaj ciąg znaków, który nie pasuje do żadnego identyfikatora konta, na przykład "*".
Sprawdzanie ustawienia /.well-known/web-identity jest teraz pomijane, gdy RP i dostawca tożsamości znajdują się w tej samej witrynie
Podczas programowania systemu FedCM subdomenami serwera produkcyjnego dostawcy tożsamości mogą być domeny testowe lub przejściowe serwera RP. Na przykład serwer produkcyjnego dostawcy tożsamości znajduje się pod adresem idp.example, a serwer przejściowego dostawcy tożsamości i serwer testowego dostawcy tożsamości znajdują się pod adresem staging.idp.example. Dobrze znany plik musi znajdować się w katalogu głównym eTLD+1 serwera dostawcy tożsamości, dlatego musi mieć adres idp.example/.well-known/web-identity i serwer produkcyjny. Ponieważ deweloper nie musi mieć możliwości umieszczenia plików w środowisku produkcyjnym, uniemożliwia to im testowanie FedCM.
Od wersji Chrome 122, jeśli domena RP i domena dostawcy tożsamości są takie same, Chrome pomija sprawdzanie dobrze znanego pliku. Dzięki temu deweloperzy będą mogli testować w takiej sytuacji.
Zasoby podrzędne mogą teraz ustawiać stan logowania w tej samej witrynie
Wcześniej Chrome zezwalał na ustawianie stanu logowania (np. za pomocą nagłówka Set-Login: logged-in) tylko wtedy, gdy żądanie ma ten sam rodzaj źródła ze wszystkimi elementami nadrzędnymi. Zapobiegało to logowaniu przez same-site
fetch() prosi o ustawienie stanu logowania.
Weźmy na przykład witrynę, w której użytkownicy mogą wpisywać swoją nazwę użytkownika i hasło w idp.example, ale gdy te dane są publikowane w login.idp.example za pomocą fetch(). Nie udało się zarejestrować w przeglądarce stanu logowania za pomocą interfejsu Login Status API, ponieważ te 2 domeny są w tej samej witrynie i z innych domen.
Dzięki tej zmianie nie wymagamy, aby interfejs Login Status API miał tę samą witrynę ze wszystkimi elementami nadrzędnymi. W powyższym przykładzie umożliwiamy ustawianie stanu logowania użytkownika login.idp.example za pomocą nagłówka HTTP (Set-Login:
logged-in).
Podsumowanie
Dzięki użyciu interfejsu Rozłącz API FedCM może odłączyć RP od dostawcy tożsamości bez używania plików cookie innych firm. Aby to zrobić, zadzwoń pod numer IdentityCredential.disconnect() w grupie objętej ograniczeniami. Dzięki tej funkcji przeglądarka wysyła żądanie do punktu końcowego odłączenia dostawcy tożsamości, aby dostawca tożsamości mógł zakończyć połączenie na serwerze, a następnie w przeglądarce.
Zapowiedzieliś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. Możesz też ustawić stan logowania za pomocą nagłówka odpowiedzi HTTP z zasobu podrzędnego dostawcy tożsamości w tej samej witrynie.