Single Sign-On (SSO) w sklepie internetowym: co to jest i kiedy go potrzebujesz

Single Sign-On (SSO) to jedno logowanie do kilku systemów naraz: klient potwierdza tożsamość raz i wchodzi do sklepu, aplikacji mobilnej czy platformy dla firm bez kolejnego formularza. Wygodę widać od razu, dlatego SSO łatwo sprzedać i łatwo kupić za wcześnie. Sens pojawia się przy drugim kanale, a rachunek za całość wystawia dopiero dzień, w którym chcesz zmienić dostawcę logowania. Pokazujemy to na dwóch sklepach na Magento: w Bolero wybór zapadł przed pierwszą linijką kodu, w drugim zmiana dostawcy zepsuła logowanie w aplikacji mobilnej.

Czym jest Single Sign-On (SSO) w sklepie internetowym

Single Sign-On (SSO) to jedno logowanie, które otwiera klientowi kilka Twoich systemów naraz: sklep, aplikację mobilną, platformę B2B. Jedno konto, jedno hasło, a potem klient wchodzi wszędzie tam, gdzie mu na to pozwolisz, bez kolejnego formularza. Na pytanie, co to jest single sign on, to wystarczająca odpowiedź. Dla sklepu to dopiero początek rozmowy.

Mechanika jest prostsza, niż wygląda skrót. Logowanie przestaje żyć w sklepie i przenosi się do osobnego systemu, czyli do dostawcy tożsamości. Klient podaje tam dane raz, a w zamian dostaje token: podpisany dowód, że jest tym, za kogo się podaje. Każdy podłączony kanał ten token sprawdza i wpuszcza klienta bez pytania o hasło. Pod spodem stoją standardy SAML albo OIDC i na tym etapie wystarczy wiedzieć, że istnieją.

Klient kupuje u Ciebie od dwóch lat, ma konto, historię zamówień i zapisany adres dostawy. Instaluje Twoją aplikację i pierwsze, co widzi, to ekran rejestracji. Dla niego to ta sama firma i to samo konto. Dla systemu to dwie osobne bazy użytkowników, które nic o sobie nie wiedzą, i dwa miejsca, w których trzeba potem zmieniać hasło, resetować dostęp i odpowiadać na pytania obsługi.

Większość tekstów o SSO kończy się w tym punkcie listą zalet: wygoda, mniej haseł, scentralizowana kontrola. Żadna z nich nie mówi Ci jednak, czy masz to robić i jak. Z naszych wdrożeń wychodzi coś innego: najdroższe decyzje zapadają na długo przed wdrożeniem i pierwsza z nich dotyczy tego, gdzie mieszkają konta Twoich klientów.

Czy logowanie przez Google to SSO?

Nie w tym znaczeniu, w jakim SSO planuje się dla sklepu. Przycisk „Zaloguj się przez Google" to technicznie bliski krewny: jest zewnętrzny dostawca tożsamości, jest token, jest jedno uwierzytelnienie zamiast kolejnego hasła w Twojej bazie.

Tylko że logowanie przez Google czy Facebooka, czyli social login, rozwiązuje jeden konkretny problem: tarcie przy rejestracji. Klient nie wymyśla hasła, nie potwierdza maila, wchodzi w dwóch kliknięciach. Płacisz za to tym, że wybór tożsamości zostaje po jego stronie. On decyduje, które konto przyniesie, a kontrolę nad tym kontem ma ktoś trzeci.

SSO odpowiada na inne pytanie. Jak sprawić, żeby kanały, które należą do Ciebie, uznawały to samo konto, a dostęp do niego trzymało jedno miejsce po Twojej stronie. Sklep, aplikacja, panel dla handlowców. Social login obniża próg wejścia dla klienta. SSO daje Ci punkt, w którym dostęp nadajesz albo odbierasz, i to od razu we wszystkich kanałach.

Te dwie rzeczy nie konkurują i często stoją obok siebie: dostawca tożsamości po Twojej stronie, a w nim logowanie Google jako jedna z dostępnych metod. Pomyłka zaczyna kosztować dopiero wtedy, gdy zastępuje decyzję. Zdanie „klient nie musi pamiętać hasła, bo kliknie Facebookiem" jest argumentem za social loginem. Jeśli przeważa w rozmowie o wdrożeniu, cały projekt ma załatwić coś, co załatwia jeden przycisk w formularzu rejestracji. O kanały trzeba zapytać osobno.

Kiedy sklep internetowy potrzebuje SSO

Sklep potrzebuje SSO wtedy, gdy ma drugi kanał (aplikację, drugi sklep, platformę dla firm), a klient ma w nich mieć jedno konto. Aplikacja mobilna Bolero nie dostała własnego formularza logowania. Powstała w React Native jako osobny kanał sprzedaży i rozmawia tylko z dwoma systemami: z warstwą odczytu, która podaje jej katalog, i z Keycloakiem, który rozpoznaje klienta. Magento zostało źródłem prawdy, zamówienia i płatności wracają do niego cyklicznie, a jak taka warstwa odczytu działa, opisaliśmy w tekście o integracjach ecommerce. Logowanie zeszło warstwę niżej, do osobnej warstwy kont, więc w aplikacji nie ma go po co budować.

Brak własnego formularza nie był decyzją o aplikacji, tylko skutkiem wcześniejszego ustalenia, gdzie mieszka konto klienta.

Ten sam kształt problemu wraca w innych układach. Drugi sklep na tej samej bazie klientów, osobna domena dla innej marki, a kupujący ma w obu rozpoznać jedno konto. Platforma dla firm, gdzie pod kontem jednej firmy pracuje kilka osób z działu zakupów i każda ma swój własny dostęp. Konta firmowe mają przy tym tyle swoich komplikacji, że zebraliśmy je w osobnym tekście o platformach B2B.

Sklep z jednym kanałem nie dostaje po wdrożeniu SSO niczego, czego nie ma w zwykłym logowaniu: nadal jest jedna baza użytkowników, jeden formularz i jedno miejsce, w którym klient resetuje hasło. Nie mamy pomiaru konwersji po wdrożeniu SSO ani podstaw, żeby wiązać SSO w sklepie internetowym z porzuconymi koszykami.

Gdzie żyją konta

Gdzie mają żyć konta Twoich klientów? Pytanie brzmi technicznie, więc zwykle pada dopiero po wyborze narzędzia, kiedy ktoś już odpowiedział na nie za Ciebie.

Możliwości jest w praktyce cztery i układają się w spektrum:

• W bazie sklepu. Tak działa domyślnie każda platforma i dopóki masz jeden kanał, nie ma po co tego ruszać.

• W osobnej warstwie tożsamości, którą trzymasz u siebie, na swoim serwerze i w swoim kodzie.

• U dostawcy, który sprzedaje tożsamość jako usługę. Nic nie utrzymujesz, ale rachunek rośnie razem z liczbą kont.

• Na platformie sklepowej, która trzyma konta, a Ty korzystasz z nich na jej warunkach.

Reszta, czyli wdrożenie SSO w sklepie internetowym, układa się już pod tę jedną odpowiedź.

Ostatnia opcja ma swoją głośną odmianę: Shoper ONE daje klientowi jedno konto do zakupów w ponad dwudziestu tysiącach sklepów na tej platformie i według Shopera w pierwszych trzydziestu dniach liczba logowań przekroczyła 600 tysięcy. To SSO platformy, nie SSO Twoich własnych kanałów: jedno konto klienta działa w wielu sklepach na tej samej platformie, a Twój sklep jest jednym z nich.

Bolero wybrało drugą opcję, czyli osobną warstwę kont opartą na Keycloaku i moduł, który spina ją z Magento. Ciekawsze od samego wyboru jest to, co go poprzedziło. Zanim powstała pierwsza linijka kodu, zrobiliśmy porównanie dwóch wariantów z diagramami sekwencji: własny SSO zbudowany na django-allauth albo Keycloak jako gotowy dostawca tożsamości. Tak samo zaczynał się POC przed migracją u innego klienta i warsztaty integracyjne u kolejnego. Keycloak wybraliśmy w obu projektach, o których tu piszemy.

Jeden profil klienta bierze się właśnie z tej decyzji. Konta mieszkają w jednym miejscu, więc dane o kliencie nie mają jak się rozjechać na dwie bazy.

Jedno pytanie zadaj jeszcze przed wyborem: co się stanie z kontami i hasłami, które już masz. Każdy z czterech wariantów radzi sobie z tym inaczej i wykonawca powinien wiedzieć jak, zanim ruszy projekt.

Gotowy moduł, usługa czy własne rozwiązanie

Są trzy drogi. Gotowy moduł, dostawca jako usługa, własne rozwiązanie. Poradniki stawiają je obok siebie jak wiersze w tabelce, z kolumną ceny i kolumną czasu wdrożenia, a w takim zestawieniu gotowy moduł SSO zawsze wygląda najrozsądniej. Różnica między nimi wychodzi w dniu, w którym chcesz coś zmienić.

Sklep z aplikacją mobilną, z którym pracowaliśmy, miał logowanie w sklepie i w aplikacji oparte na płatnym module miniOrange Enterprise, a ten spięty z Auth0 jako dostawcą tożsamości. Płacił więc dwa razy: za moduł i za dostawcę. Zejście z licencji i z opłat za dostawcę było jednym z powodów, dla których przebudowujemy to logowanie. Nie policzyliśmy jeszcze, ile to da.

Potem wyłączenie starego modułu zepsuło endpoint logowania aplikacji mobilnej. Aplikacja uwierzytelniała klienta pod konkretnym adresem, który należał do modułu, i razem z modułem ten adres zniknął. Odtworzyliśmy go z identycznym kontraktem, a logowanie ma przejąć własny moduł oparty na Keycloaku, z pełną weryfikacją tokenu. Resztę projektu rozbiliśmy na etapy z osobną wyceną, zamiast przełączać wszystko jednym ruchem.

Dla kogoś, kto logowanie dopiero wybiera, zostaje z tego jedna zasada. Kontrakt logowania aplikacji traktuj jak publiczne API: wolno Ci pod nim wymienić dostawcę tożsamości, ale nie wolno Ci ruszyć adresu ani kształtu odpowiedzi, których aplikacja się spodziewa. Wszystko, co moduł wystawia na zewnątrz, w dniu zmiany okazuje się Twoim zobowiązaniem.

Cenę gotowego modułu widzisz od razu, w cenniku. Cenę wyjścia z niego poznajesz dopiero wtedy, gdy chcesz wyjść.

Czy SSO jest bezpieczne?

SSO podnosi bezpieczeństwo sklepu, ale dopiero wtedy, gdy ktoś zadba o szczegóły wdrożenia. Hasło przestaje leżeć w kilku bazach naraz i żyje u jednego dostawcy tożsamości. Mniej miejsc, z których może wyciec, i jedno miejsce, w którym da się wymusić reguły: długość hasła, blokadę po nieudanych próbach, wymuszoną zmianę. Przy dwóch osobnych logowaniach każdą z tych rzeczy ustawiasz dwa razy albo nie ustawiasz wcale.

Jedno konto otwiera teraz wszystkie kanały, więc przejęte konto otwiera je równie skutecznie. Dlatego dwuetapowa weryfikacja, krótkie sesje i powiadomienie o logowaniu z nowego urządzenia należą do zakresu wdrożenia. Jeśli wykonawca wycenia je osobno, jako coś do rozważenia w drugim etapie, zapytaj, co w pierwszym etapie pilnuje tego jednego konta.

Pełna weryfikacja tokenu po stronie sklepu wygląda na szczegół implementacyjny, a rozstrzyga całe „pod warunkiem". Sklep, który przyjmuje token, bo token wygląda jak token, nie sprawdzając podpisu, ważności i tego, do kogo został wystawiony, wpuszcza każdego, kto umie takiego tokena przygotować. Własny moduł oparty na Keycloaku, który ma przejąć logowanie w tamtej aplikacji mobilnej, ma tę weryfikację wbudowaną. Gwarancji bezpieczeństwa nie da Ci natomiast żaden dostawca ani żaden wykonawca, bo nikt nie kontroluje wszystkiego naraz: urządzeń klientów, ich haseł i swojego własnego kodu. Sprawdzić można, czy wdrożenie ma te trzy zabezpieczenia i czy token jest weryfikowany po stronie sklepu. O to pytaj wykonawcę przed podpisaniem umowy.

Podsumowanie

Sklep przebudujesz, front wymienisz, platformę kiedyś zmienisz. Baza kont zostaje. Konta klientów przechodzą kolejne wersje sklepu i wędrują z systemu do systemu, zbierając historię zakupów, adresy i zgody, których nie odtworzysz z niczego innego. Logowanie trafia więc do specyfikacji między zwykłe funkcje, a zachowuje się jak zobowiązanie: decyzja o tym, kto przechowuje tożsamość Twojego klienta, zostaje z firmą dłużej niż większość technologii, które wtedy wybierasz. Gdzie dziś mieszkają konta Twoich klientów i kto trzyma do nich klucz?

Jeśli chcesz sprawdzić, co z tego wynika dla Twojego sklepu i planowanych kanałów, umów bezpłatną konsultację. Przejdziemy przez te decyzje po kolei i powiemy, co oznaczają dla zakresu wdrożenia.