Jak to zrobić: LOGOWANIE

Cześć! W tej serii dzielę się codzienną praktyką dotyczącą prostych, niedocenianych rzeczy, na których potykają się menedżerowie i właściciele.

Pierwsi szukają właściwej logiki. Drudzy walczą o pozyskanie użytkowników, retencję i ten cały „idealny UX”.

Dzisiaj oddaję logikę logowania do strony lub aplikacji mobilnej. Za darmo.

Dlaczego Google?

Trzeba wpuścić użytkownika do aplikacji i ustalić, z jakim kontem mamy do czynienia. Proste? Niby tak. Ale gwarantuję, że część scenariuszy nawet nie przyszła wam do głowy.

Jedna z najprostszych opcji to logowanie przez Google.

Zalety:

Wady: oszuści nadal istnieją, a nie każdy chce logować się przez Google. Zbadaj ludzi, dla których robisz produkt.

Który sposób logowania wybrać?

Po prostu zaufać kodowi w przeglądarce? Nie, dziękuję. Serwer musi zweryfikować token ID: podpis, wystawcę, przeznaczenie dla twojej aplikacji i termin ważności.

Obsłużyć logowanie i sesję po stronie serwera? Tak. Szczególnie w CRM-ach i aplikacjach z wrażliwymi danymi. Samo istnienie serwera niczego jeszcze nie zabezpiecza. Te sprawdzenia trzeba zaimplementować.

Google One Tap? Wygodne, gdy liczy się płynny przebieg. Ale niespodziewane okienko może uruchomić „czynnik nienawiści”. Nie strasz ludzi własnym UX-em.

Dane: zacznij od minimum

Konfigurując scopes, musisz rozumieć, po co ci każde uprawnienie. Nie zbieraj informacji „bo się da”. Ktoś właśnie powierza ci swoją prywatność.

1. Pobieraj tylko potrzebne dane podstawowego profilu.

2. O wiek, płeć i dodatkowe informacje pytaj wyłącznie wtedy, gdy są rzeczywiście potrzebne. Zwykłe logowanie nie dostarcza ich automatycznie.

3. O kolejne uprawnienia proś w momencie, w którym potrafisz wyjaśnić użytkownikowi ich sens.

Ta nieszczęsna awatarka

Po co jest? Żeby użytkownik rozpoznał własne konto i wiedział, że trafił we właściwe miejsce.

MOŻNA KOPIOWAĆ: jeżeli produkt potrzebuje własnej kopii zdjęcia, pobierz dostępny awatar przy rejestracji i zapisz go we własnym magazynie plików. Przy kolejnym logowaniu sprawdź, czy się zmienił. Zmienił się — aktualizujesz. Zdjęcia nie ma — pokazujesz wariant zastępczy.

Tę kopię też uwzględnij w zasadach przechowywania i usuwania danych.

Baza, prywatność i tabele

W polityce prywatności opisz to, co faktycznie robisz. Reklamy? Wyjaśnij śledzenie i zbierz wymaganą zgodę. Przechowywanie? Zaplanuj kontrolę dostępu i szyfrowanie. Tekst polityki nie zabezpieczy bazy.

I nie wrzucaj wszystkiego do jednego worka.

Podstawowe dane profilu trzymaj oddzielnie. Sekretne klucze serwisowe zostają na serwerze, nie w przeglądarce. Uprawnienia sprawdzaj przy każdej operacji.

Poziom wyżej: rzeczy, które łatwo przeoczyć

1. Łączenie kont. Email z hasłem i Google powinny prowadzić do jednego konta, jeśli rzeczywiście chodzi o tę samą osobę. Ale sam zgodny email to za mało, żeby bezwarunkowo scalać konta. Potwierdź kontrolę nad obiema metodami; tożsamość Google wiąż przez stały identyfikator `sub`, nie zmienny adres. Czas ostatniego logowania aktualizuj osobno.

2. Tokeny i sesje. Token ID potwierdza tożsamość, a access token służy do dostępu do API. Nie myl ich. Sesja po stronie serwera, na przykład w Redisie, albo poprawnie skonfigurowana sesja z JWT — wybór zależy od architektury. Cookie musi być zabezpieczone. Sam skrót JWT nie robi tu magii.

3. Usuwanie danych. Zaprojektuj rzeczywiste usuwanie lub odpowiednią anonimizację, razem z kopią awatara i powiązanymi rekordami. „Dodaliśmy sól i zrobiliśmy hash” nie oznacza „nie da się ustalić, kto to jest”. Jeśli osobę można odtworzyć dzięki innym danym, mówimy o pseudonimizacji, a nie anonimizacji. Warunki dalszego przechowywania niektórych danych sprawdzaj dla konkretnego przypadku.

I tyle. Jeden przycisk logowania, a za nim tyle danych i logiki. Nie da się udawać, że to osobne światy.