Jak utworzyć usługę logowania współdzielonego w wielu domenach?

Myślę, że kluczem w Twoim Q Jest to, że piszesz "dzięki czemu nie musisz się logować, jeśli używasz nawigacji najwyższego poziomu do innego produktu".

Wyjaśnię: Chcesz być w stanie przenieść się z site1.com na site2.com i niech site2.com wiedz, że jesteś jakimś użytkownikiem, który zalogował się za pośrednictwem site1.com.

Ponieważ pliki cookie nie są udostępniane pomiędzy różnymi domenami (innymi niż subdomeny, ale chyba nie mówisz o subdomenach), musisz przekazać pewne informacje na link do site2.com to pozwoli mu rozmawiać z zapleczem i wiedzieć, jakim użytkownikiem jesteś.

Zacznijmy od naiwnego rozwiązania, a następnie pracujemy na swój sposób, aby rozwiązać niektóre problemy, które stwarza: Załóżmy, że masz tabelę użytkowników na jakimś zapleczu DB i twój użytkownik ma jakiś identyfikator. teraz Załóżmy, że użytkownik uwierzytelniony na site1.com i jest użytkownikiem 123 z twojego DB. Najbardziej naiwnym rozwiązaniem byłoby wywołanie site2.com/url/whatever?myRealID=123 i niech site2 sprawdzi ten identyfikator i " belive" użytkownik, że to rzeczywiście on.

Problem: każdy (nawet prawidłowy użytkownik Twojej witryny), który zobaczy twój link, może utworzyć link z myRealID=123 lub spróbować innych wartości dla niego. oraz site2.com zaakceptuje go jako tego użytkownika.

Rozwiązanie: nie pozwala używać domyślnego identyfikatora Załóżmy, że dodasz do swojej tabeli użytkowników unikalny identyfikator GUID i jeśli użytkownik 123 ma identyfikator guid 8dc70780-15e5-11e0-ac64-0800200c9a66 to wywołaj site2.com/url/whatever?myGuid=8dc70780-15e5-11e0-ac64-0800200c9a66.

Nowy Problem: cóż nawet jeśli byłoby bardzo mało prawdopodobne, że ktoś zgadnie GUID Użytkownika jego GUID może nadal być porwany przez jakiegoś pośrednika, który widzi ten link i to ktoś dostanie guid może go używać na zawsze.

Rozwiązanie: użyj klucza prywatnego zapisanego na serwerze, aby podpisać łańcuch zawierający następujące pozycje danych, bieżący znacznik czasu, witrynę docelową (np. site2.com") wspomniany GUID, ten podpis można przetłumaczyć na powiedzenie " jest to dowód, że ten link został stworzony przez stronę w wspomniany czas dla użytkownika, który ma ten GUID do uwierzytelnienia przez tę domenę " i wysłać go do site2.com wraz ze znacznikiem czasu i GUID. Teraz kiedy site2.com dostaje link może upewnić się, że jest poprawnie podpisany i jeśli jakiś pośrednik lub pierwotnie użytkownik będzie próbował go zmienić w jakikolwiek sposób (albo moja modyfikacja czasu lub GUID) to podpis nie pasuje i site2.com odmówi uwierzytelnienia użytkownika.

Ostatni problem: jeśli link zostanie przechwycony przez pośrednika, może nadal używaj, jeśli z innej maszyny.

Rozwiązanie: dodaj nonce do podanych parametrów. Nonce jest tylko przypadkową liczbą, którą Twój system uwierzytelniania powinien upewnić się, że nie pozwala na uwierzytelnienie tym numerem więcej niż jeden raz (stąd nazwa N(umber)-ONCE). Zauważ, że oznacza to, że każdy link, który tworzysz na site1.com to prowadzi do site2.com powinien mieć odrębną nonce, która musi być zapisana w back-endzie do późniejszej walidacji.

Bo nie chcesz aby w nieskończoność dodawać rekordy do tej tabeli nonce, zwyczajem jest decydowanie, że takie łącze jest ważne tylko przez określony czas po jego utworzeniu. możesz więc tworzyć rekordy inne niż starsze niż ten limit czasu.

Mam nadzieję, że to jest zarys, którego szukasz. Możliwe, że coś przeoczyłem, ale to są podstawowe wytyczne, użyj podpisu, aby udowodnić autentyczność danych w linku i użyj nonce, aby zapobiec atakom pośredników. Polecam również korzystanie z HTTPS dla tych linków, jeśli to możliwe.

Eyal