Interfejs API do federacji tożsamości zapewniający ochronę prywatności.
Co to jest FedCM?
FedCM (Federated Credential Management) to podejście do usług tożsamości federacyjnej (takich jak „Zaloguj się przez…”), które chroni prywatność i nie polega na plikach cookie osób trzecich ani przekierowaniach nawigacyjnych.
Stan wdrożenia
- Stan platformy Chrome
- Usługa FedCM została udostępniona w Chrome 108.
- Oferta FedCM jest otwarta do dyskusji publicznej.
- Inne przeglądarki nie obsługują jeszcze FedCM.
- Mozilla wdraża prototyp dla przeglądarki Firefox i Apple wyraża ogólne poparcie i jest zainteresowany współpracą nad ofertą FedCM.
W przyszłości planujemy wprowadzić kilka nowych funkcji na podstawie opinii otrzymanych od dostawców tożsamości (IdP), stron korzystających z usług (RP) i producentów przeglądarek. Mamy nadzieję, że dostawcy tożsamości zaczną używać FedCM, ale pamiętaj, że ten interfejs API jest nadal aktywnie rozwijany.
Aby zminimalizować problemy związane z wdrażaniem zmian niezgodnych ze starszymi wersjami, mamy 2 zalecenia dla dostawców tożsamości:
- Zasubskrybuj nasz newsletter, w którym będziemy wysyłać informacje o zmianach w interfejsie API.
- Zachęcamy dostawców tożsamości do rozpowszechniania interfejsu FedCM API za pomocą pakietów SDK JavaScriptu, dopóki interfejs API będzie udoskonalany, oraz do zniechęcania dostawców treści do samodzielnego hostowania pakietów SDK. Dzięki temu dostawcy usług uwierzytelniania będą mogli wprowadzać zmiany w interfejsie API, nie prosząc wszystkich stron, które na nim polegają, o ponowne wdrożenie.
Dlaczego potrzebujemy FedCM?
W ostatniej dekadzie federacja tożsamości odegrała kluczową rolę w podnoszeniu poziomu zabezpieczeń uwierzytelniania w internecie pod względem wiarygodności, łatwości użycia (np. logowania jednokrotnego bez hasła) i zabezpieczeń (np. zwiększonej odporności na phishing i ataki polegające na wypełnianiu formularzy logowania) w porównaniu z nazwami użytkowników i hasłami na poszczególnych stronach.
W przypadku federacji tożsamości podmiot korzystający (RP) polega na dostawcy tożsamości (IdP), aby zapewnić użytkownikowi konto bez konieczności podawania nowej nazwy użytkownika i hasła.
Niestety mechanizmy, na których opiera się federacja tożsamości (iframe, przekierowania i pliki cookie), są aktywnie wykorzystywane do śledzenia użytkowników w internecie. Ponieważ agent użytkownika nie jest w stanie rozróżnić federacji tożsamości od śledzenia, zapobieganie różnym rodzajom nadużyć utrudnia wdrożenie federacji tożsamości.
Interfejs API do zarządzania sfederowanymi poświadczeniami (FedCM) zapewnia abstrakcję dla konkretnych przypadków użycia sfederowanych przepływów tożsamości w internecie. Umożliwia to wyświetlenie w przeglądarce okna dialogowego, które pozwala użytkownikom wybrać konta dostawców tożsamości, aby zalogować się w witrynach.
FedCM to wieloetapowy proces, który ma na celu poprawę tożsamości w internecie. Na pierwszym etapie skupiamy się na ograniczeniu wpływu ograniczeń związanych z plikami cookie innych firm na tożsamość z federowanymi identyfikatorami (więcej informacji znajdziesz w sekcji Mapy drogowej).
Jakie są przewidywane konsekwencje?
Na podstawie działań społeczności i naszych badań wiemy, że na integracje związane z federacją tożsamości wpływają ograniczenia dotyczące plików cookie innych firm:
- Wylogowanie na froncie OpenID Connect
- Zarządzanie sesjami OpenID Connect
- Odnawianie tokena odtwarzania w tle na podstawie elementu iframe
- Wierszcie logowania w ramce iframe
Pierwszym celem FedCM jest ograniczenie wpływu ograniczeń dotyczących plików cookie innych firm na federację tożsamości. Te obszary powinny być najbardziej dotknięte zmianami. Jeśli masz dodatkowe przypadki użycia, które nie są wymienione, możesz wymienić się opiniami i przekazać opinię.
FedCM jako sygnał zaufania dla innych interfejsów API
Oprócz obsługi tożsamości sfederowanej FedCM służy też jako sygnał zaufania dla innych interfejsów API Piaskownicy prywatności.
Od wersji 131 Chrome interfejs Storage Access API (SAA) używa FedCM jako sygnału zaufania. Ta integracja jest przydatna w przypadku witryn, które korzystają z FedCM do uwierzytelniania i z SAA, aby umożliwić elementom iframe w innych domenach dostęp do niezbędnego miejsca na dane.
Gdy użytkownik uwierzytelnia się za pomocą FedCM, a RP wyraził zgodę, treści dostawcy tożsamości umieszczone w witrynie RP mogą wywołać metodę requestStorageAccess()
, aby automatycznie uzyskać dostęp do pamięci do własnych plików cookie najwyższego poziomu bez konieczności wyświetlania dodatkowego promptu dla użytkownika. Te uprawnienia będą przyznawane automatycznie tylko wtedy, gdy użytkownik jest zalogowany w FedCM i stan logowania w FedCM jest aktywny. Więcej informacji znajdziesz w dokumentacji interfejsu Storage Access API.
Kto powinien korzystać z FedCM?
Oczekujemy, że FedCM będzie przydatna tylko wtedy, gdy spełnione są wszystkie te warunki:
- Jesteś dostawcą tożsamości.
- Dotyczą Cię ograniczenia dotyczące plików cookie innych firm.
- RP to strony firm zewnętrznych. Jeśli strony docelowe są ze sobą powiązane, możesz lepiej wykorzystać zestawy powiązanych witryn.
Jesteś dostawcą tożsamości
FedCM wymaga obsługi ze strony dostawcy tożsamości. Użytkownik nie może samodzielnie korzystać z FedCM. Jeśli jesteś RP, możesz poprosić dostawcę tożsamości o instrukcje.
Dotyczą Cię ograniczenia dotyczące plików cookie innych firm
Używaj FedCM tylko wtedy, gdy na Twoją obecną integrację mają wpływ ograniczenia dotyczące plików cookie innych firm.
Jeśli nie masz pewności, czy federacja tożsamości będzie działać, gdy pliki cookie innych firm nie będą dostępne, możesz przetestować efekt w witrynie, blokując pliki cookie innych firm w Chrome.
Jeśli nie można wykryć wpływu na federację tożsamości bez plików cookie innych firm, możesz nadal używać bieżącej integracji bez FedCM.
Jeśli nie wiesz, na co zwrócić uwagę, dowiedz się więcej o funkcjach, na które mogą mieć wpływ ograniczenia dotyczące plików cookie innych firm.
Twoje RP są zewnętrzne
Jeśli jesteś dostawcą tożsamości, którego RP mają bezpośrednie relacje z dostawcą tożsamości, lepszym rozwiązaniem może być zbiór powiązanych witryn. Powiązane zestawy witryn (RWS) to sposób, w jaki organizacja może deklarować relacje między witrynami, aby przeglądarki zezwalały na ograniczony dostęp do plików cookie innych firm do określonych celów. Dzięki temu pliki cookie innych firm będą działać w zestawach powiązanych ze sobą witryn, nawet jeśli w innych przypadkach są one ograniczone.
Jak użytkownicy będą korzystać z FedCM?
Głównym celem FedCM jest ograniczenie wpływu ograniczeń dotyczących plików cookie innych firm. Użytkownicy mogą włączać i wyłączać FedCM w ustawieniach użytkownika Chrome.
FedCM jest niezależny od protokołu i oferuje te funkcje związane z uwierzytelnianiem:
Zobacz nasz demonstracyjny film, aby dowiedzieć się, jak to działa.
Logowanie się w usługach strony trzeciej
Gdy użytkownik wejdzie na stronę strony trzeciej, wyświetli się okno logowania FedCM, jeśli użytkownik jest zalogowany w dostawcy tożsamości.
Jeśli użytkownik nie ma konta w RP u dostawcy tożsamości, wyświetli się okno rejestracji z dodatkowym tekstem, takim jak warunki korzystania z usługi i polityka prywatności RP (jeśli są dostępne).
Użytkownik może dokończyć logowanie, klikając Dalej jako…. Jeśli operacja się powiedzie, przeglądarka zapisuje fakt, że użytkownik utworzył konto zaufane w RP z IDP.
RP powinny działać w przeglądarkach, które nie obsługują FedCM. Użytkownicy powinni mieć możliwość korzystania z dotychczasowego procesu logowania, który nie wykorzystuje FedCM. Dowiedz się więcej o tym, jak działa logowanie w FedCM.
Ustawienia włączania i wyłączania FedCM
Użytkownicy mogą włączać i wyłączać FedCM w ustawieniach Chrome na Androidzie. Kliknij Ustawienia > Ustawienia witryny > Logowanie przez usługę innej firmy, a następnie zmień przełącznik.
Mogą też zrobić to w Chrome na komputerze, klikając chrome://settings/content/federatedIdentityApi
.
Okres oczekiwania na prompt
Jeśli użytkownik zamknie interfejs ręcznie, wpis zostanie tymczasowo dodany do interfejsu ustawień, a interfejs nie będzie wyświetlany w tej samej witrynie przez pewien czas. Po upływie tego czasu interfejs zostanie ponownie włączony, ale czas ten będzie się wykładniczo wydłużał przy kolejnych zamknięciach. Na przykład w Chrome:
Liczba kolejnych zamknięć | Okres, w którym prompt FedCM jest pomijany |
---|---|
1 | 2 godziny |
2 | Jeden dzień |
3 | Jeden tydzień |
4+ | 4 tygodnie |
Inne przeglądarki mogą określać własne, inne okresy czasu oczekiwania.
Użytkownicy mogą ręcznie ponownie włączyć FedCM na stronie RP, otwierając stronę ustawień lub klikając interfejs PageInfo (ikonę kłódki obok paska adresu URL) i resetując uprawnienia.
Plan działań
Pracujemy nad wprowadzeniem kilku zmian w FedCM. Więcej informacji znajdziesz w sekcji Aktualizacje.
- Historia zmian: aktualizacje interfejsu Federated Credential Management API.
Wiemy, że trzeba jeszcze zrobić kilka rzeczy, w tym rozwiązać problemy zgłoszone przez dostawców usług uwierzytelniających, dostawców usług rejestrujących i producentów przeglądarek. Wiemy, jak rozwiązać te problemy:
- Obsługa iframe w wielu domenach: dostawcy tożsamości mogą wywoływać FedCM z poziomu iframe w wielu domenach (aktualizacja).
- Przycisk z personalizacją: dostawcy tożsamości mogą wyświetlać tożsamość powracającego użytkownika na przycisku logowania w ramach iframe między domenami należącym do dostawcy tożsamości (aktualizacja).
- Punkt końcowy danych: udostępnia dostawcom usług ID dane o skuteczności.
Poza tym mamy nierozwiązane problemy, które aktywnie badamy, w tym konkretne propozycje, które oceniamy lub testujemy w wersji prototypowej:
- CORS prowadzimy rozmowy z Apple i Mozilla, aby poprawić specyfikację pobierania danych z FedCM.
- Interfejs API dla wielu dostawców tożsamości: szukamy sposobów na umożliwienie współpracy wielu dostawcom tożsamości w wybieraczu kont FedCM.
- Interfejs API stanu logowania dostawcy tożsamości: Mozilla wykryła problem z atakiem opartym na czasie. Obecnie szukamy sposobów, aby dostawca tożsamości mógł aktywnie powiadamiać przeglądarkę o stanie logowania użytkownika, aby rozwiązać ten problem. (aktualizacja)
- Logowanie do interfejsu API dostawcy tożsamości: aby obsługiwać różne scenariusze, gdy użytkownik nie zaloguje się w dostawcy tożsamości, przeglądarka udostępnia interfejs użytkownika do logowania bez konieczności opuszczania RP.
Na koniec, zgodnie z opiniami Mozilla, Apple i TAG Reviewers, są jeszcze pewne kwestie, które wymagają naszej uwagi. Pracujemy nad oceną najlepszych rozwiązań dotyczących tych otwartych kwestii:
- Ułatwianie użytkownikom zrozumienia i odpowiedniego dopasowania zamiaru: jak zauważyła Mozilla, chcemy dalej testować różne formuły UX i obszary powierzchni, a także kryteria uruchamiania.
- Atrybuty tożsamości i wybrane ujawnienia: zgodnie z uwagami sprawdzających TAG chcielibyśmy udostępnić mechanizm umożliwiający selektywne udostępnianie atrybutów tożsamości (takich jak adresy e-mail, przedziały wiekowe, numery telefonów itp.).
- Zwiększenie liczby właściwości związanych z prywatnością: zgodnie z sugestiami Mozilli w jej stanowisku w sprawie standardów chcielibyśmy kontynuować badania nad mechanizmami zapewniającymi lepszą ochronę prywatności, takimi jak mechanizmy IdP blindness czy kierowane identyfikatory.
- Związek z WebAuthn: jak sugeruje Apple, jesteśmy bardzo podekscytowani postępami w przygotowaniu kluczy dostępu i możliwością zapewnienia spójnego i zintegrowanego środowiska między FedCM, Passwords, WebAuthn i WebOTP.
- Stan logowania: jak sugeruje Apple w ramach Privacy CG API stanu logowania, uważamy, że stan logowania użytkownika to przydatna informacja, która może pomóc przeglądarkom w podejmowaniu świadomych decyzji. Cieszymy się, że możemy wykorzystać tę możliwość. (aktualizacja)
- Firmy i instytucje edukacyjne: jak wynika z grupy roboczej FedID CG, nadal istnieje wiele przypadków użycia, które nie są dobrze obsługiwane przez FedCM i nad którymi chcielibyśmy popracować, takich jak wylogowywanie na froncie (możliwość wysłania przez dostawcę tożsamości sygnału do dostawców usług) i obsługa SAML.
- Związek z mDL, VC itp.: kontynuuj pracę nad zrozumieniem, jak te elementy pasują do FedCM, np. do interfejsu API Mobile Document Request.
Korzystanie z interfejsu FedCM API
Aby korzystać z FedCM, musisz mieć bezpieczny kontekst (HTTPS lub localhost) zarówno w usłudze IdP, jak i RP w Chrome.
Aby zintegrować się z FedCM, musisz utworzyć znany plik, plik konfiguracyjny i punkty końcowe dla listy kont, wydawania oświadczeń i (opcjonalnie) metadanych klienta. Następnie FedCM udostępnia interfejsy API JavaScript, których RP mogą używać do logowania się w usługach uwierzytelniania.
Aby dowiedzieć się, jak korzystać z interfejsu FedCM API, zapoznaj się z przewodnikiem dla programistów FedCM.
Uzyskiwanie opinii i ich udostępnianie
- GitHub przeczytaj informacje, zgłoś problemy i obserwuj dyskusję.
- Pomoc dla deweloperów: zadawaj pytania i ucz się na podstawie dyskusji w repozytorium Piaskownicy prywatności dla deweloperów.
Zgodność z przepisami ePrivacy
Korzystanie z FedCM jako dostawca tożsamości lub dostawca usług reklamowych wiąże się z przechowywaniem informacji na urządzeniu końcowym użytkownika lub z dostępem do informacji już na nim zapisanych. Jest to więc działanie podlegające przepisom dotyczącym prywatności w internecie w Europejskim Obszarze Gospodarczym (EOG) i Wielkiej Brytanii, które zazwyczaj wymagają zgody użytkownika. Twoim obowiązkiem jest ustalenie, czy korzystanie z FedCM jest ściśle niezbędne do świadczenia usługi online, o którą użytkownik wyraźnie poprosił, i czy w związku z tym nie jest wymagana zgoda użytkownika. Więcej informacji znajdziesz w artykule Pytania i odpowiedzi dotyczące zgodności z zasadami ochrony prywatności w Piaskownicy prywatności.