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 witryn na tym samym koncie.
Odłączanie interfejsu API
Gdy użytkownik tworzy konto w usługach strony korzystającej (RP – witryny korzystającej z usługi dostawcy tożsamości do uwierzytelniania) za pomocą federacji tożsamości, dostawca tożsamości (IdP – usługi, która zapewnia uwierzytelnianie i informacje o 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ć 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 przypomnieniami o używanym koncie.
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 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, wysyłając sygnał do określonego punktu końcowego. Użytkownik musi przejść przez proces federacji tożsamości za pomocą interfejsu FedCM (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 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 dostawcy tożsamości przez FedCM.
- 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 konfiguracyjnego 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 rozłączeniem, podając te informacje:
| 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 IdP powinien:
- Odpowiedz na żądanie za pomocą CORS (współdzielenie zasobów pomiędzy serwerami z różnych domen).
- Sprawdź, czy żądanie zawiera nagłówek HTTP
Sec-Fetch-Dest: webidentity. - Dopasuj nagłówek
Origindo źródła RP określonego przezclient_id. Odrzuć, jeśli się nie zgadzają. - Znajdź konto, które odpowiada
account_hint. - Odłącz konto użytkownika z listy połączonych kont RP.
- Prześlij do przeglądarki
account_idzidentyfikowanego 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 serwera RP na potrzeby testów lub wdrożenia mogą być subdomenami serwera IdP w środowisku produkcyjnym. 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 udało się 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 wymienionym powyżej przykładzie ustawienie stanu logowania login.idp.example za pomocą nagłówka HTTP (Set-Login:
logged-in).
Podsumowanie
Dzięki interfejsowi Disconnect API usługa FedCM może teraz odłączać RP od IdP bez korzystania z plików cookie innych firm. Aby to zrobić, wybierz IdentityCredential.disconnect() na 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, że w celu przeprowadzenia 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 IdP w tej samej witrynie.