Defragmentacja logowania w wielu domenach

Eiji Kitamura

Nowoczesne architektury biznesowe często obejmują wiele różnych domen. Organizacje utrzymują dedykowane środowiska dla różnych funkcji, np. brand.example na potrzeby marketingu, service-app.example na potrzeby podstawowego produktu i support-portal.example na potrzeby obsługi klienta. Idealnie byłoby, gdyby użytkownicy mogli korzystać z ujednoliconego logowania jednokrotnego podczas przechodzenia między tymi usługami. Zespoły inżynierów często integrują jednak te domeny za pomocą technik ad hoc, które powodują fragmentację. Zakłóca to wbudowane zarządzanie danymi logowania w przeglądarce, ponieważ przerywa przepływy autouzupełniania menedżera haseł i opóźnia wdrażanie kluczy dostępu.

Jeśli to samo konto obejmuje wiele domen, użytkownik musi rozpoznać, że domeny należą do tej samej organizacji, i podczas logowania podać te same dane logowania. W najgorszym przypadku użytkownik tworzy duplikat konta lub podaje hasło na stronie wyłudzającej informacje.

Dowiedz się, jak używać standardów i rozwiązań architektonicznych (takich jak metadane, elementy iframe z różnych domen, federacja tożsamości i konsolidacja subdomen), aby rozwiązać problem fragmentacji tożsamości w różnych domenach i zapewnić użytkownikom płynną ścieżkę.

Typowe obejścia

Organizacje stosują kilka sprawdzonych technik, aby zapewnić użytkownikom płynną ścieżkę w różnych domenach. Chociaż te metody są powszechne, napotykają przeszkody strukturalne, ponieważ przeglądarki egzekwują bardziej rygorystyczne granice prywatności i standardy bezpieczeństwa.

Żądania pobierania CORS

Gdy domeny działają niezależnie, interfejsy często korzystają z żądań z różnych domen fetch() kierowanych do scentralizowanego interfejsu API uwierzytelniania, na które można bezpiecznie zezwolić za pomocą współdzielenia zasobów między domenami (CORS). Ponieważ przeglądarki często blokują lub ograniczają pliki cookie między witrynami, deweloperzy mogą wyraźnie zaprojektować te interfejsy API tak, aby zwracały tokeny uwierzytelniania, takie jak tokeny sieciowe JSON (JWT), w ładunkach JSON zamiast polegać na nagłówkach Set-Cookie.

Udostępnianie bazy danych kont

Aby ujednolicić tożsamość w backendzie bez skomplikowanych integracji frontendowych, możesz scentralizować magazyn danych użytkowników. Chociaż wiele domen uwierzytelnia się w tej samej bazie danych, ich interfejsy logowania pozostają oddzielne. Zmusza to użytkowników do zapamiętywania, w których domenach używali tych samych danych logowania, co pogarsza wygodę użytkowników.

Problemy z rozłącznymi logowaniami

Chociaż obejścia techniczne mogą zapewnić podstawową funkcjonalność, nie zapewniają płynnej ścieżki. Rozłączne przepływy logowania wprowadzają punkty tarcia, które pogarszają zarówno użyteczność, jak i bezpieczeństwo.

Fragmentacja menedżera haseł

Największym punktem tarcia jest zakłócenie działania menedżerów haseł. Menedżery haseł wiążą zapisane dane logowania z konkretnym źródłem, w którym są zarejestrowane. Uniemożliwia to przeglądarce oferowanie autouzupełniania w różnych domenach, nawet jeśli należą one do tej samej organizacji.

Gdy użytkownik przechodzi z domeny z zapisanymi danymi logowania do nowej domeny w Twojej organizacji, menedżer haseł nie rozpoznaje relacji i nie wyświetla prośby o autouzupełnienie. Powoduje to tarcie związane z ręcznym wprowadzaniem danych. Użytkownicy muszą wyszukać swoje dane logowania, zresetować hasło lub utworzyć duplikat konta.

Ponieważ menedżer haseł jest w tych usługach zawodny, użytkownicy mogą zrezygnować z narzędzi w tych witrynach. Zamiast tego często tworzą słabe, łatwe do zapamiętania hasła, których mogą używać w innych miejscach, co pogarsza ogólne bezpieczeństwo organizacji.

Brama do phishingu

To zakłócenie działa jak brama do phishingu. Odmowa autouzupełnienia przez menedżera haseł w nierozpoznanej domenie jest podstawowym mechanizmem obronnym. Wymagając od użytkowników ręcznego wprowadzania danych logowania w różnych adresach URL, nieumyślnie uczysz ich, jak padać ofiarą ataków phishingowych.

Przeszkoda w kluczach dostępu

Tarcie nasila się, gdy używasz kluczy dostępu. Podstawowa architektura zabezpieczeń protokołu WebAuthn kryptograficznie wiąże klucze dostępu ściśle z określonym identyfikatorem strony zależnej (RP ID).

Powoduje to „pułapkę RP ID”. Klucz dostępu zarejestrowany w domenie brand.example jest nieużyteczny w domenie service-app.example, ponieważ przeglądarka odmawia dostępu między domenami. Aby uniknąć wyświetlania użytkownikom prośby o zarejestrowanie różnych kluczy dostępu w każdej witrynie, musisz skonsolidować te usługi w jednym identyfikatorze RP.

Zalecane działania

Aby zapewnić ciągłość tożsamości, musisz odejść od integracji logowania ad hoc i przyjąć uznane standardy architektoniczne:

• Używaj plików konfiguracji metadanych: hostuj pliki metadanych, takie jak Digital Asset Links i Related Origin Requests, aby utworzyć kryptograficzny łańcuch zaufania. Umożliwia to bezproblemowe udostępnianie danych logowania i kluczy dostępu w różnych domenach i aplikacjach mobilnych. To podejście jest tanim, cichym rozwiązaniem problemu fragmentacji tożsamości, które nie wymaga złożonej przebudowy istniejącej infrastruktury internetowej.
• Używaj elementów iframe z różnych domen: umieść scentralizowane źródło uwierzytelniania jako element iframe w stronie zależnej, aby połączyć zapisane dane logowania i klucze dostępu w różnych witrynach. To podejście wykorzystuje zasadę uprawnień i podzielone pliki cookie, aby zapewnić bezproblemowe logowanie w kontekście, przy jednoczesnym zachowaniu ścisłych granic bezpieczeństwa dzięki CSP i przesyłaniu wiadomości między dokumentami.
• Postępuj zgodnie ze standardową federacją tożsamości: przyjmij standardowe protokoły, takie jak OpenID Connect, aby scentralizować uwierzytelnianie w dedykowanej domenie dostawcy tożsamości. Formalizuje to ścieżkę logowania za pomocą bezpiecznych przekierowań, zastępując kruche integracje niezawodnym i skalowalnym rozwiązaniem własnym.
• Skonsoliduj subdomeny: przejdź na subdomeny w ramach wspólnej domeny głównej. Umożliwia to bezproblemowe udostępnianie sesji za pomocą plików cookie z symbolami wieloznacznymi i ciągłość kluczy dostępu w całej domenie, którą można zarejestrować. Wiele menedżerów haseł może rozpoznać udostępnioną domenę główną i automatycznie sugerować zapisane dane logowania w powiązanych subdomenach.

Używaj plików konfiguracji metadanych

Głównym wyzwaniem związanym z tożsamością w różnych domenach jest fragmentacja zapisanych danych logowania. Menedżery haseł traktują różne domeny i aplikacje jako całkowicie odizolowane jednostki, co uniemożliwia im autouzupełnianie danych logowania zapisanych w jednej usłudze w innej.

Aby rozwiązać problem fragmentacji, możesz skonfigurować działanie menedżerów haseł zamiast zmieniać strukturę witryny. Dzięki hostowaniu określonych plików konfiguracji metadanych organizacje mogą kryptograficznie potwierdzić, że różne domeny i aplikacje należą do tej samej organizacji. Umożliwia to systemom operacyjnym, przeglądarkom i menedżerom haseł rozpoznawanie tej relacji i automatyczne łączenie kontekstu tożsamości, udostępnianie haseł i kluczy dostępu w Twoich usługach. To podejście jest też wymagane do udostępniania haseł i kluczy dostępu w aplikacjach mobilnych, nawet jeśli domeny internetowe są skonsolidowane.

Aby mieć pewność, że obejmujesz różne platformy i ekosystemy, użyj 2 różnych plików konfiguracji:

• Menedżer haseł Google na Androidzie i w Chrome: hostuj plik JSON Digital Asset Links (DAL) w lokalizacji /.well-known/assetlinks.json, aby utworzyć weryfikowalną relację zaufania między powiązanymi aplikacjami i witrynami organizacji. To zaufanie umożliwia linki bezpośrednie w aplikacjach i bezproblemowe udostępnianie danych logowania, w przypadku których hasła zapisane w internecie są automatycznie uzupełniane w powiązanych witrynach (jednak udostępnianie kluczy dostępu w wielu domenach internetowych nadal wymaga Related Origin Requests). Więcej informacji znajdziesz w przewodniku Bezproblemowe udostępnianie danych logowania.

• Hasła Apple w iOS i Safari: hostuj plik Apple App Site Association (AASA) w lokalizacji /.well-known/apple-app-site-association, aby utworzyć kryptograficzny łańcuch zaufania niezbędny do łączenia stanów haseł Apple w aplikacjach na iOS i Safari. Aby obsługiwać ekosystemy innych firm, możesz zadeklarować te powiązane domeny centralnie za pomocą repozytorium crowdsourcingowego. Dzięki temu niezależne narzędzia (np. 1Password, które wyraźnie korzysta z tego repozytorium) również rozpoznają udostępniony kontekst tożsamości. Więcej informacji o Apple App Site Association znajdziesz w artykule Obsługa powiązanych domen.

Aby włączyć klucze dostępu w różnych domenach internetowych i rozwiązać problem z kluczami dostępu roadblock, deweloperzy mogą hostować plik Related Origin Requests (ROR) w lokalizacji /.well-known/webauthn. ROR wyraźnie deklaruje autoryzowane domeny, które mogą bezpiecznie udostępniać ten sam identyfikator RP klucza dostępu. Więcej informacji o Related Origin Requests znajdziesz w artykule Zezwalanie na ponowne używanie kluczy dostępu w witrynach za pomocą Related Origin Requests.

• Zalety:
  • Rozwiązanie działające w tle dla użytkowników: działa całkowicie w tle, co automatycznie rozwiązuje problem fragmentacji autouzupełniania i zapewnia ciągłość kluczy dostępu na poziomie systemu operacyjnego lub przeglądarki bez widocznych zmian w interfejsie.
  • Prosta implementacja: jest to tanie rozwiązanie, które wymaga tylko hostowania statycznych plików JSON. Nie wymaga przebudowy backendu ani złożonej logiki wymiany tokenów.
  • Zachowuje istniejącą infrastrukturę: możesz znacznie poprawić ścieżkę w różnych domenach bez zmiany marki ani konsolidowania domen.
• Wady:
  • Ograniczenia platformy: platformy zwykle nakładają ścisłe limity na ROR. Na przykład Chrome ogranicza pojedynczy identyfikator RP do maksymalnie 5 powiązanych etykiet eTLD+1. Na przykład example.co.uk i example.de mają tę samą etykietę example eTLD+1, ale example-rewards.com używa osobnej etykiety example-rewards. Jeśli zarządzasz rozbudowanym lub zróżnicowanym portfolio domen, te limity mogą być niewystarczające.
  • Zwiększone opóźnienie operacyjne: rozwiązywanie plików metadanych wymaga dodatkowej podróży w sieci, co zwiększa opóźnienie podczas przetwarzania uwierzytelniania przez przeglądarkę.

Używaj elementów iframe z różnych domen

Jeśli nie możesz użyć plików konfiguracji metadanych z powodu ograniczeń domeny ROR, elementy iframe z różnych domen oferują niezawodną, obsługiwaną przez standardy ścieżkę do rozwiązania problemów z logowaniem w różnych domenach.

Umieszczając scentralizowane źródło uwierzytelniania (np. auth.brand.example) jako element iframe w stronie zależnej (np. brand.example), możesz wchodzić w interakcje zarówno ze zwykłymi polami formularza, jak i nowoczesnymi interfejsami API. W przypadku haseł menedżer danych logowania przeglądarki kojarzy działania autouzupełniania ze źródłem elementu iframe (auth.example). Umożliwia to użytkownikom bezproblemowy dostęp do scentralizowanych danych logowania w różnych witrynach.

W przypadku kluczy dostępu okno nadrzędne musi przyznać elementowi iframe dostęp za pomocą zasady uprawnień , co umożliwi elementowi iframe wywoływanie protokołu WebAuthn w celu uwierzytelnienia w identyfikatorze RP własnego źródła. W obu przepływach, CSP (Content Security Policy) jest przydatna do ochrony użytkowników przed atakami, takimi jak clickjacking i cross-site scripting. Po pomyślnym uwierzytelnieniu sesja jest ustanawiana za pomocą podzielonego pliku cookie, a token jest bezpiecznie przesyłany z powrotem do okna nadrzędnego za pomocą postMessage().

• Zalety:
  • Scentralizowane dane logowania: omija problem fragmentacji danych logowania. Pojedyncze, scentralizowane źródło zarządza zarówno zapisanymi hasłami, jak i ujednoliconym identyfikatorem RP klucza dostępu, co umożliwia różnym domenom udostępnianie tych danych logowania bez konieczności konsolidowania domen.
  • Uwierzytelnianie kontekstowe: cały proces logowania – autouzupełnianie hasła lub weryfikacja za pomocą klucza dostępu – odbywa się bezproblemowo w kontekście strony nadrzędnej, co pozwala uniknąć zakłócających przekierowań sfederowanych.
  • Odporność na ochronę przed śledzeniem: to podejście działa prawidłowo nawet w przypadku ścisłej ochrony przed śledzeniem między witrynami za pomocą podzielonych plików cookie.
• Wady:
  • Ograniczenia implementacji: ta architektura wymaga specjalistycznej wiedzy inżynierskiej. Wymaga ścisłego przestrzegania CSP (frame-ancestors), aby ograniczyć osadzanie do zaufanych domen nadrzędnych i zapobiegać clickjackingowi, konfiguracji zasad uprawnień HTTP, aby włączyć interfejs API WebAuthn, oraz bezpiecznego, zweryfikowanego przesyłania wiadomości między dokumentami (postMessage()), aby ograniczyć ataki polegające na podszywaniu się pod źródło i CSRF. Poznaj sprawdzone metody w artykule Klucze dostępu w elementach iframe.

Postępuj zgodnie ze standardową federacją tożsamości

Przyjęcie standardowej federacji tożsamości, takiej jak OpenID Connect, to niezawodne i zrównoważone podejście do utrzymywania systemu kont. To podejście formalizuje proces uwierzytelniania, konsolidując go w jednej, dedykowanej domenie dostawcy tożsamości, np. auth.brand.example. Dzięki ustalonemu protokołowi aplikacje przekierowują użytkowników do tego centralnego centrum uwierzytelniania, a następnie bezpiecznie otrzymują transfer tokena, aby dokończyć logowanie w domenie docelowej. Chociaż standardowa federacja jest często kojarzona z logowaniem przez strony trzecie (np. Zaloguj się przez Google), jest ona całkowicie prawidłowa i powszechnie stosowana jako rozwiązanie własne, które zastępuje kruche obejścia.

• Zalety:
  • Wspólny język inżynierski: deweloperzy nie muszą uczyć się ani utrzymywać konkretnego, niestandardowego protokołu. Mogą polegać na sprawdzonej wiedzy branżowej i kompleksowych bibliotekach. Dostępne są też gotowe rozwiązania.
  • Sprawdzona niezawodność: standardowe protokoły są sprawdzone, bezpieczne i znacznie mniej podatne na awarie niż implementacje ad hoc.
  • Łatwe rozszerzanie: jeśli organizacja musi sfederować się z nową usługą innej firmy lub później zintegrować przejęcie, infrastruktura tożsamości jest już wyposażona w dane logowania.
  • Spójny interfejs: użytkownicy rozpoznają scentralizowaną stronę dostawcy tożsamości jako autorytatywne źródło marki, co pozwala im dokładnie określić, kiedy i gdzie wymagane są dane logowania.
• Wady:
  • Wysokie koszty integracji: opracowanie scentralizowanego dostawcy tożsamości lub migracja do niego wiąże się z wysokimi kosztami integracji i wymaga specjalistycznej wiedzy z zakresu bezpieczeństwa. Organizacje muszą zainwestować w bezpieczne refaktoryzowanie wszystkich połączonych aplikacji, aby obsługiwały bezpieczne wzorce oparte na przekierowaniach.
  • Zakłócające przekierowania: proces uwierzytelniania wymaga przekierowania użytkowników z witryny źródłowej na scentralizowaną stronę dostawcy tożsamości, co uniemożliwia bezproblemowe logowanie w kontekście.

Skonsoliduj subdomeny

Innym podejściem strukturalnym jest ujednolicenie wszystkich domen przez przeniesienie różnych usług cyfrowych pod wspólną domenę główną, którą można zarejestrować (eTLD+1). Wymaga to przekształcenia oddzielnych domen, takich jak brand.example i service-app.example w subdomeny, np. www.brand.example i service.brand.example.

• Zalety:
  • Ujednolicone zarządzanie danymi logowania: menedżery haseł mogą rozpoznawać domenę główną i traktować wszystkie subdomeny jako jeden wpis, co eliminuje duplikaty próśb i ręczne wprowadzanie haseł.
  • Ciągłość kluczy dostępu: deweloperzy mogą natywnie określić zakres identyfikatora RP klucza dostępu w domenie, którą można zarejestrować, co natychmiast rozszerza obsługę kluczy dostępu na wszystkie powiązane subdomeny. W tym przypadku identyfikator RP brand.example będzie działać zarówno w domenie www.brand.example, jak i service.brand.example.
  • Łatwe udostępnianie sesji: konsolidacja struktury domeny umożliwia udostępnianie pojedynczej sesji za pomocą plików cookie z symbolami wieloznacznymi (np. określanie zakresu pliku cookie na Domain=brand.example).
• Wady:
  • Ograniczenia dotyczące marki i migracji: to podejście może nakładać potencjalne ograniczenia dotyczące marki, jeśli Twoja organizacja wymaga odrębnych domen najwyższego poziomu. Migracja jest złożona i wymaga starannego zarządzania przekierowaniami HTTP oraz rozległego usuwania problemów z konfiguracjami starszych wersji z różnych domen.

Podsumowanie

Aby zapewnić ciągłość tożsamości, musisz przejść od integracji logowania ad hoc do ustalonych standardów uwierzytelniania. Oceniając ograniczenia biznesowe w kontekście tych sprawdzonych metod – takich jak federacja, konsolidacja domen, elementy iframe czy metadane – możesz wyeliminować tarcie w interfejsie i poprawić uwierzytelnianie w całym ekosystemie.

Aby dowiedzieć się więcej o powiązanych tematach, śledź naszego bloga i zapoznaj się z dodatkowymi materiałami w portalu tożsamości Chrome.