Logowanie społecznościowe dla PrestaShop: Google, Facebook i Apple

Oto moment, w którym wiele sklepów PrestaShop po cichu traci sprzedaż: klient kupujący po raz pierwszy trafia na stronę rejestracji, widzi pusty formularz z prośbą o e-mail, hasło i potwierdzenie hasła, i uznaje, że zakup jednak nie był aż tak pilny. Logowanie społecznościowe usuwa tę barierę. Zamiast wymyślać kolejne hasło, klient klika „Zaloguj się przez Google” (albo Facebooka czy Apple), zatwierdza udostępnienie danych i wraca do Twojego sklepu już zalogowany, z automatycznie uzupełnionym imieniem i adresem e-mail. Ten poradnik pokazuje, jak zrobić to poprawnie w PrestaShop: jak działa wymiana OAuth, jak skonfigurować wszystkich trzech dostawców, co moduł musi obsłużyć za Ciebie i których kwestii związanych z RODO nie wolno pominąć.

Problem, który to rozwiązuje, jest tym samym tarciem, które psuje finalizację zakupu, każde dodatkowe pole to kolejne miejsce, w którym klient może się wycofać. Jeśli utworzenie konta jest barierą przy wejściu do sklepu, wieloetapowy formularz rejestracji to pokrewny problem, który warto rozpatrywać razem z nim: tekst o tym, skąd naprawdę przychodzą Twoi klienci, pomaga ustalić, z których dostawców już korzysta Twoja grupa odbiorców, a więc które przyciski logowania warto pokazać.

Dlaczego prawdziwą korzyścią jest mniejsze tarcie dla gości

Łatwo opisać logowanie społecznościowe jako „funkcję rejestracji”. W praktyce to raczej funkcja zmniejszania tarcia. Jej wartość widać w dwóch konkretnych momentach, nazwanie ich pomaga zachować właściwą perspektywę w dalszej części poradnika:

• Pierwszy kontakt. Nowy odwiedzający to najbardziej kruchy klient w sklepie. Wymuszona rejestracja konta jest jedną z najlepiej udokumentowanych przyczyn porzucania zakupów w e-commerce, a każde pole, o które prosisz przed pierwszym zakupem, daje powód do wyjścia. Jeden przycisk zamiast formularza zmienia zadanie na 60-90 sekund w dwusekundowe kliknięcie.
• Powrót do sklepu. Ludzie zapominają hasła, przeciętny kupujący żongluje dziesiątkami kont i często używa podobnych danych logowania w wielu miejscach. Powracający klient, który nie pamięta hasła i nie chce bawić się w e-mail resetujący, to ktoś, kogo już udało Ci się pozyskać i kogo zaraz możesz znów stracić. Logowanie społecznościowe całkowicie omija objazd przez „nie pamiętam hasła”: klienta rozpoznaje dostawca, a nie ciąg znaków, który trzeba sobie przypomnieć.

W tej korzyści ukryty jest też bonus bezpieczeństwa. Gdy klient loguje się przez Google, hasło nigdy nie trafia do Twojego sklepu. Nie przechowujesz hasła klienta do Google, ale dane osobowe i tokeny przechowywane w Twoim sklepie nadal mogą wyciec w razie naruszenia bezpieczeństwa. Dla właściciela sklepu oznacza to prosto: mniej danych logowania w bazie to mniejsza odpowiedzialność po Twojej stronie.

Jak działa logowanie społecznościowe: wymiana OAuth2 po ludzku

Większość rozwiązań do logowania społecznościowego korzysta z OAuth 2.0 oraz, zależnie od dostawcy, tokena tożsamości w stylu OpenID Connect, logowanie przez Google i Apple dokłada walidację tożsamości na warstwie OAuth 2.0. Mechanika ma znaczenie, bo tłumaczy, dlaczego kilku kroków konfiguracyjnych nie da się ominąć. Gdy klient klika „Zaloguj się przez Google”, sekwencja wygląda tak:

• Twój sklep przekierowuje klienta na własną stronę logowania Google, uwierzytelnienie odbywa się w Google, nigdy u Ciebie.
• Google prosi klienta o zgodę na udostępnienie Twojemu sklepowi konkretnego, nazwanego zestawu danych (zwykle imienia i nazwiska, adresu e-mail oraz zdjęcia profilowego).
• Google odsyła klienta z powrotem na adres URL callback w Twoim sklepie, przekazując jednorazowy kod autoryzacyjny.
• Twój sklep wymienia ten kod na token dostępu w wywołaniu serwer-serwer, którego klient nie widzi.
• Za pomocą tokena sklep pobiera zatwierdzone dane profilu i tworzy klienta PrestaShop albo łączy logowanie z istniejącym kontem.

Praktyczny wniosek dla właściciela sklepu: hasło klienta nigdy nie jest Ci udostępniane, a cała wymiana zależy od dokładnej zgodności adresu callback i danych uwierzytelniających dostawcy. Jeśli te dwie rzeczy są poprawne, reszta należy do modułu. Jeśli są błędne, przycisk nic nie zrobi. Dlatego większość zgłoszeń typu „logowanie społecznościowe nie działa” kończy się na literówce w URI przekierowania.

Konfiguracja logowania przez Google

Google jest najpopularniejszym dostawcą i najłagodniejszym w konfiguracji, dlatego najlepiej zacząć właśnie od niego.

Utwórz projekt Google Cloud i ekran zgody

W Google Cloud Console utwórz nowy projekt, a następnie, zanim zrobisz cokolwiek innego, skonfiguruj ekran zgody OAuth. Jako typ użytkownika wybierz „Zewnętrzny”, wpisz nazwę sklepu, adres e-mail do wsparcia i autoryzowaną domenę. W zakresach uprawnień poproś wyłącznie o email i profile, nic więcej. Prośba o mniejszy zakres to nie tylko porządek; to lepsza postawa względem RODO i szybsza weryfikacja po stronie Google.

Utwórz klienta OAuth 2.0

W sekcji APIs & Services → Credentials utwórz identyfikator klienta OAuth 2.0 typu „Aplikacja internetowa”. Dodaj domenę sklepu do autoryzowanych źródeł JavaScript i dodaj adres callback modułu do autoryzowanych URI przekierowania. Callback korzysta ze wzorca danego modułu, często wygląda mniej więcej tak: https://yourstore.com/module/[yoursocialloginmodule]/callback?provider=google. Skopiuj uzyskane wartości Client ID i Client Secret.

Wprowadź dane uwierzytelniające w PrestaShop

Wklej Client ID i Client Secret w konfiguracji modułu logowania społecznościowego, zapisz ustawienia i przetestuj przycisk na stronie logowania sklepu. Jeśli przekierowanie wraca z błędem niezgodności, URI przekierowania w konsoli Google nie jest identyczny bajt w bajt z tym, który wysyła moduł, dotyczy to także różnicy między http i https oraz końcowej ścieżki. To najczęstszy błąd konfiguracji u wszystkich trzech dostawców.

Konfiguracja logowania przez Facebooka

Logowanie przez Facebooka tworzy się w portalu Meta for Developers i wymaga nieco więcej procesu niż Google.

Utwórz aplikację i skonfiguruj logowanie

Utwórz aplikację Meta dla Facebook Login / uwierzytelniania użytkowników, a następnie dodaj produkt lub przypadek użycia Facebook Login (proces tworzenia aplikacji w Meta zmienia się z czasem i może pokazywać przypadki użycia zamiast stałego typu aplikacji). W ustawieniach dodaj adres callback sklepu do „Valid OAuth Redirect URIs” i pozostaw włączone „Enforce HTTPS”. Domyślnie możesz poprosić o uprawnienia email i public_profile, to wystarcza do utworzenia konta. Nie warto prosić o więcej (listę znajomych, posty): nadmiarowe uprawnienia odstraszają użytkowników i mogą spowodować odrzucenie aplikacji w weryfikacji.

Weryfikacja aplikacji i tryb publiczny

Dopóki aplikacja jest w trybie „Development”, przycisk logowania działa tylko dla osób dodanych jako deweloperzy lub testerzy. Aby udostępnić go prawdziwym klientom, musisz przełączyć aplikację na „Live” i mieć skonfigurowane wymagane ustawienia zasad oraz usuwania danych. Przy standardowych danych logowania email i public_profile zwykle nie potrzebujesz App Review. Jest ono zarezerwowane dla zaawansowanych uprawnień lub funkcji wykraczających poza standardowe logowanie. Jeśli prosisz o cokolwiek ponad standardowe dane logowania, uwzględnij czas weryfikacji, żeby nie zaskoczyła Cię sytuacja, w której przycisk działa u Ciebie, ale nie działa u nikogo innego.

Pułapka Facebooka, którą warto znać wcześniej

Meta stopniowo zaostrza dostęp do danych. W e-commerce szczególnie często boli jedno: uprawnienie email czasem zwraca brak adresu e-mail, zwykle wtedy, gdy klient założył konto na Facebooku wyłącznie przy użyciu numeru telefonu. Proces logowania zakładający, że e-mail zawsze nadejdzie, będzie psuł się po cichu. Poprawne zachowanie, które powinien zapewniać dobrze zbudowany moduł, polega na wykryciu brakującego adresu i poproszeniu klienta o jego wpisanie przed dokończeniem tworzenia konta. Jeśli Facebook jest już dla Ciebie kanałem sprzedaży, warto szerzej zrozumieć, jak platforma traktuje dane, omawiamy to w tekście o sprzedaży na Facebooku z PrestaShop, a stronę pomiarową wyjaśniamy w artykule o tym, dlaczego Facebook Pixel nadal ma znaczenie.

Konfiguracja logowania przez Apple

Logowanie przez Apple jest najnowsze z tej trójki i najmocniej zaprojektowane pod prywatność, co oznacza, że wymaga najwięcej od modułu. Konfiguruje się je w portalu Apple Developer i wymaga płatnego konta Apple Developer (99 USD rocznie).

Kroki konfiguracji

• Zarejestruj nowy App ID i włącz dla niego „Sign in with Apple”.
• Utwórz Services ID. Działa ono jako identyfikator klienta OAuth.
• Ustaw adres powrotu na callback Twojego sklepu.
• Wygeneruj klucz prywatny do uwierzytelniania klienta. Apple nie używa prostego ciągu Client Secret; oczekuje sekretu klienta opartego na JWT i podpisanego tym kluczem, który moduł składa za Ciebie.

Dwa zachowania Apple, które moduł musi obsłużyć

• Ukryj mój adres e-mail. Apple pozwala klientowi ukryć prawdziwy adres za losowym adresem @privaterelay.apple.com. Wiadomości wysyłane na ten adres są przekazywane do rzeczywistej skrzynki, ale Twój sklep widzi wyłącznie adres pośredniczący, a moduł musi traktować go jak w pełni poprawny e-mail, nie odrzucać jako podejrzany.
• Imię i nazwisko udostępniane tylko raz. Apple wysyła dane klienta przy pierwszym uwierzytelnieniu i nigdy później. Jeśli moduł nie przechwyci ich i nie zapisze w tym pierwszym callbacku, stracisz je bezpowrotnie, chyba że klient ponownie autoryzuje dostęp. To klasyczne źródło zagadek typu „dlaczego połowa klientów logujących się przez Apple nie ma nazwiska”, rozwiązanie polega na natychmiastowym pobraniu danych przy pierwszej wymianie.

Co faktycznie otrzymujesz od każdego dostawcy

Znajomość dokładnego kształtu danych z góry chroni przed zaprojektowaniem rejestracji opartej na polach, które mogą nigdy nie przyjść:

To, który dostawca jest wart konfiguracji, zależy wyłącznie od tego, gdzie już są Twoi klienci. Google i Facebook dominują na większości rynków anglojęzycznych; w Niemczech popularność logowania przez Facebooka jest niższa ze względu na prywatność, podczas gdy Google pozostaje mocny; logowanie przez Apple mocniej ciąży ku użytkownikom iOS, którzy często mają wyższe wartości zamówień. Nie musisz wdrażać wszystkich trzech, dopasuj przyciski do swojej grupy odbiorców i wracaj do tej mieszanki, gdy zmienia się struktura ruchu. Szersze pytanie o to, które platformy faktycznie na siebie pracują, omawiamy w tekście o integracji kanałów Instagram i Facebook ze sklepem.

Obsługa klientów, którzy mają już konto

To przypadek brzegowy, który odróżnia porządny moduł logowania społecznościowego od chaotycznego. Co powinno się stać, gdy ktoś, kto wcześniej zarejestrował się tradycyjnie, e-mailem i hasłem, kliknie „Zaloguj się przez Google”, używając tego samego adresu e-mail?

• Dopasuj po e-mailu, potem połącz, nigdy nie duplikuj. Jeśli e-mail z konta społecznościowego pasuje do istniejącego klienta PrestaShop, moduł powinien przypiąć tę tożsamość społecznościową do istniejącego konta, a nie tworzyć drugi profil rozbijający historię zamówień.
• Potwierdź połączenie za pierwszym razem. Lepsze moduły proszą klienta o jednorazowe wpisanie dotychczasowego hasła PrestaShop w celu potwierdzenia połączenia. Ten jeden krok blokuje przejęcie konta w scenariuszu, w którym atakujący kontroluje konto społecznościowe z pasującym adresem e-mail i mógłby inaczej wejść w cudzą historię zamówień.
• Pozwól na wielu dostawców dla jednego konta. Klient może używać Google na laptopie i Apple w telefonie. Przechowywanie identyfikatorów użytkownika specyficznych dla dostawcy w tabeli mapującej pozwala obu ścieżkom prowadzić do tego samego konta PrestaShop.

Zbieranie danych i RODO, część, której nie możesz pominąć

Logowanie społecznościowe pobiera dane osobowe od podmiotu trzeciego do Twojego sklepu, więc stajesz się ich administratorem. To nie powód, by z niego rezygnować; to powód, by dobrze je opisać. Obowiązki są konkretne:

• Zgoda. Ekran zgody OAuth dostawcy autoryzuje przekazanie danych od dostawcy do sklepu, ale nie wyczerpuje Twoich obowiązków: sklep nadal potrzebuje własnej podstawy prawnej, informacji o prywatności wyjaśniającej, co otrzymujesz przez logowanie społecznościowe i co z tym robisz, oraz obsługi zgód wymaganych w Twojej jurysdykcji.
• Minimalizacja danych. Proś tylko o te uprawnienia, których naprawdę używasz. Pobieranie listy znajomych z Facebooka, gdy potrzebny był wyłącznie e-mail, to nie tylko brak dobrych manier, to problem zgodności.
• Prawo do usunięcia danych. Gdy klient prosi o usunięcie, cofnij połączenie społecznościowe i usuń powiązane dane razem z kontem.
• Uczciwość wobec adresu pośredniczącego. Jeśli akceptujesz adresy Apple Hide My Email, Twoje wiadomości transakcyjne i marketingowe nadal muszą działać przez pośrednika, projektuj procesy z założeniem, że adres przekazuje pocztę dalej, a nie rozwiązuje się do „prawdziwej” skrzynki, którą możesz podejrzeć.

Gdzie umieścić przyciski

Umiejscowienie po cichu decyduje o wykorzystaniu funkcji. Kilka zasad sprawdza się w różnych sklepach:

• Nad formularzem, nie pod nim. Na stronach logowania i rejestracji przyciski społecznościowe powinny być pierwsze, użytkownicy skanują stronę od góry do dołu, a opcja jednego kliknięcia ma być pierwszą rzeczą, którą widzą, nie nagrodą pocieszenia pod ścianą pól.
• Pokaż je w zakupach jako gość. Komunikat „Zaloguj się przez Google, aby automatycznie uzupełnić dane” jest naprawdę przekonujący dokładnie w chwili, gdy klient przygotowuje się do wpisywania adresu.
• Używaj oficjalnych stylów przycisków. Google, Facebook i Apple publikują dokładne specyfikacje, kolory, rozmiary, brzmienie tekstu. Własnoręcznie sklecony przycisk wygląda niewiarygodnie właśnie tam, gdzie zaufanie jest najważniejsze.
• Dostosuj rozmiar do kciuków. Zadbaj o duży obszar dotknięcia (44×44px i więcej). Logowanie społecznościowe daje najwięcej na urządzeniach mobilnych, gdzie wpisywanie hasła jest najwolniejsze i najbardziej podatne na błędy, nie pozwól więc, aby zbyt ciasny przycisk zmarnował tę przewagę.

Szczegóły bezpieczeństwa, które moduł powinien obsługiwać poprawnie

Logowanie społecznościowe usuwa ryzyko przechowywania haseł, ale dodaje kilka własnych. Nie musisz wdrażać ich samodzielnie, ale warto wiedzieć, że są obsługiwane:

• Parametr state. Każdy przepływ OAuth powinien generować losową wartość state, zapisywać ją w sesji i weryfikować przy callbacku, to właśnie blokuje ataki CSRF na wymianę logowania.
• HTTPS, zawsze. W sklepach produkcyjnych używaj adresów callback HTTPS, dostawcy wymagają ich dla działających publicznie sklepów. Localhost lub wyjątki testowe mogą istnieć na potrzeby developmentu, ale nie opieraj się na nich w działającym sklepie: jeśli sklep nie jest w pełni na HTTPS, logowanie społecznościowe nie ruszy.
• Tokeny poza zasięgiem wzroku. Tokeny dostępu powinny znajdować się w bezpiecznym magazynie po stronie serwera, nigdy w adresach URL, logach ani JavaScripcie po stronie klienta.

Jak mierzyć, czy to naprawdę pomogło

Nie przyjmuj korzyści na wiarę i nie oceniaj jej po trzech dniach danych. Zanim włączysz funkcję, zanotuj współczynnik rejestracji oraz współczynnik porzuceń koszyka przez nowych klientów. Po wdrożeniu obserwuj te same dwie liczby w sensownym oknie czasowym, przy wystarczającej liczbie zamówień, żeby widzieć trend, a nie szum, i dodaj jeszcze dwie:

• Podział według dostawców. Które przyciski klienci faktycznie klikają? To pokazuje, czy trzeci skonfigurowany dostawca naprawdę na siebie pracuje.
• Wskaźnik łączenia kont. Ilu istniejących klientów podłącza konto społecznościowe? Wysoki wynik to czytelny sygnał, że klienci cenią wygodę i że funkcja spełnia swoje zadanie.

Najczęściej zadawane pytania

Dlaczego przycisk logowania społecznościowego wraca z błędem „redirect URI mismatch”?

URI przekierowania zarejestrowane u dostawcy nie jest identyczne bajt w bajt z tym, które wysyła moduł. Sprawdź http vs https, brakującą lub dodatkową końcową ścieżkę oraz www vs gołą domenę, wszystkie trzy warianty liczą się jako różne URI. Ta jedna niezgodność jest najczęstszą przyczyną problemu „logowanie społecznościowe nie działa” u wszystkich trzech dostawców.

Czy muszę skonfigurować wszystkich trzech dostawców?

Nie. Dopasuj przyciski do miejsc, w których już są Twoi klienci. Google i Facebook dominują na większości rynków anglojęzycznych; w Niemczech popularność Facebooka jest niższa ze względów prywatności, podczas gdy Google pozostaje mocny; Apple trafia głównie do użytkowników iOS, często o wyższej wartości zamówień. Wdróż jednego lub dwóch dostawców, z których korzysta Twoja grupa odbiorców, i dodaj trzeciego dopiero wtedy, gdy dane pokażą, że na siebie pracuje.

Klient zalogował się przez Facebooka, ale nie dostałem adresu e-mail. Czy to błąd?

Nie, to oczekiwane zachowanie. Facebook czasem nie zwraca adresu e-mail, zwykle wtedy, gdy klient zarejestrował się wyłącznie numerem telefonu. Proces logowania zakładający, że e-mail zawsze przyjdzie, psuje się po cichu. Moduł powinien wykryć brak adresu i poprosić klienta o jego wpisanie przed dokończeniem tworzenia konta.

Połowa moich klientów logujących się przez Apple nie ma imienia i nazwiska. Co się stało?

Apple wysyła imię i nazwisko klienta tylko przy pierwszym uwierzytelnieniu i nigdy później. Jeśli moduł nie przechwyci i nie zapisze ich w tym pierwszym callbacku, dane przepadają, chyba że klient ponownie autoryzuje dostęp. Upewnij się, że moduł pobiera imię i nazwisko przy pierwszej wymianie, i akceptuje adresy „Ukryj mój adres e-mail” Apple w domenie @privaterelay.apple.com jako poprawne.

Co się stanie, jeśli ktoś użyje Google z tym samym e-mailem, co na istniejącym koncie z hasłem?

Dobrze zbudowany moduł dopasuje konto po e-mailu i połączy tożsamość społecznościową z istniejącym kontem, zamiast tworzyć duplikat rozdzielający historię zamówień. Lepsze moduły proszą jednorazowo o dotychczasowe hasło, aby potwierdzić połączenie, ten krok blokuje przejęcie konta, w którym ktoś kontrolujący pasujące konto społecznościowe mógłby inaczej wejść na cudze konto klienta. Czyste połączenie z istniejącym rekordem klienta to dokładnie ten typ szczegółu, o który dbają nasze moduły do finalizacji zakupu i obsługi klientów.

Uczciwe ujęcie tematu ma tu znaczenie: logowanie społecznościowe to możliwość, nie gwarancja. Usuwa tarcie przy pierwszym wejściu i przy powrocie do sklepu; to, czy przełoży się na więcej zamówień, zależy od reszty lejka. Ale spośród zmian, które możesz wprowadzić w sklepie PrestaShop, niewiele jest tak tanich we wdrożeniu i tak łatwych do zmierzenia. W mypresta.rocks tworzymy moduły, które usuwają tarcie z doświadczenia klienta PrestaShop, a logowanie społecznościowe naturalnie pasuje obok zoptymalizowanej finalizacji zakupu i narzędzi do zarządzania klientami jako kolejne miejsce, w którym przestajesz prosić klientów o rzeczy, których woleliby nie podawać.