Koszty ukryte w złej strategii logowania: 3 błędy SSO
Single Sign-On (SSO) brzmi jak ideał: jedno hasło, jeden klik, dostęp do wszystkiego. Bezpiecznie, wygodnie, nowocześnie. W teorii. W praktyce, gdy wdrażam audyty u klientów, widzę, że SSO często staje się wąskim gardłem, generującym koszty, które nie są widoczne na pierwszy rzut oka. Nie chodzi oczywiście o licencję na Okta czy Azure AD – te są oczywiste. Mówię o kosztach utraconych klientów, spadku produktywności i lukach bezpieczeństwa, które wynikają z błędów w strategii wdrożenia.
Oto trzy najczęstsze błędy, które widzę w firmach – i jak je naprawić, zanim uderzą w Twój budżet.
1. Zbyt restrykcyjna sesja – kara dla użytkownika
Pamiętam przypadek klienta z branży e-commerce. Wdrożyli SSO z sesją wygasającą po 15 minutach. Brzmi bezpiecznie? Tylko że ich klienci to głównie managerowie, którzy w ciągu dnia przerywają zakupy, by odebrać telefon, pójść na spotkanie. Po powrocie – ekran logowania. Jeszcze raz wpisują dane, frustracja, porzucenie koszyka. Wskaźnik porzuceń wzrósł o 12% w ciągu miesiąca od wdrożenia. Koszt? Setki tysięcy złotych utraconych przychodów.
Kluczowa lekcja: zbyt krótki czas sesji to nie bezpieczeństwo, tylko zły UX. Powinieneś dostosować time-out do realnych wzorców użytkowania. Dla aplikacji B2B sesja 8 godzin może być OK, dla bankowości – 5 minut. Ale nigdy nie ustawiaj globalnie jednego czasu dla wszystkich ról. Zastosuj różne polityki dla adminów, pracowników i klientów. I zawsze dawaj użytkownikowi ostrzeżenie przed wylogowaniem – to prosta rzecz, która radykalnie zmniejsza tarcia.
2. Brak fallbacku na tradycyjne logowanie
SSO opiera się na zaufaniu do dostawcy tożsamości (IdP). Gdy IdP pada – a pada, bo każdy cloud ma awarie – cały dostęp do aplikacji znika. Bez alternatywnego mechanizmu logowania (np. hasło + 2FA) Twoi pracownicy nie mogą pracować. Obserwowałem firmę, która straciła 8 godzin roboczych całego zespołu przez awarię Azure AD. Koszt: ok. 40 000 zł w wynagrodzeniach + opóźnienia w projekcie.
Rozwiązanie? Wdróż mechanizm awaryjny, np. lokalne konto z silnym hasłem, aktywowane tylko wtedy, gdy IdP jest niedostępny. Upewnij się, że taki fallback jest bezpieczny – ograniczony czasowo, logowany i wymagający osobnej autoryzacji. To nie jest krok wstecz, to odpowiedzialność biznesowa.
3. Single point of failure w dostawcy SSO
Większość firm wybiera jednego dostawcę SSO (Google, Microsoft, Facebook) i na tym poprzestaje. To wygodne, ale ryzykowne. Jeśli ten dostawca zmieni politykę bezpieczeństwa (np. zaostrzy wymagania dotyczące haseł) albo po prostu zawiedzie, Twoja aplikacja staje się niedostępna. Widziałem startupy, które zablokowały dostęp swoim użytkownikom, bo Twitter zmienił API – bez zapasowego IdP.
Dobrą praktyką jest obsługa wielu dostawców (np. Google + GitHub + email/hasło) i umożliwienie użytkownikowi wyboru. To nie tylko zwiększa odporność, ale też buduje zaufanie – dajesz kontrolę. Ponadto, jeśli jeden dostawca podnosi ceny (np. za liczbę zapytań), możesz łatwo przenieść część użytkowników do tańszej alternatywy. To realna oszczędność.
Podsumowanie
SSO nie jest złe – jest świetne, jeśli wdrożone z myślą o realnych scenariuszach. Klucz to balans między bezpieczeństwem a użytecznością. Pamiętaj: każda bariera na drodze użytkownika to potencjalny koszt. Analizuj swoje polityki sesji, przygotuj plan awaryjny na awarię IdP i nie stawiaj wszystkiego na jedną kartę. Twoi klienci (i Twój budżet) Ci podziękują.
