Case study: dlaczego nie napisaliśmy logowania od zera
W wielu projektach logowanie traktowane jest jak drobny element aplikacji. Formularz, baza użytkowników, hasło, token i gotowe. W praktyce jednak moduł logowania szybko staje się jednym z najbardziej wrażliwych elementów systemu. W tym case study pokazujemy, dlaczego przy jednym z projektów zdecydowaliśmy się nie pisać logowania od zera, tylko oprzeć je o gotowe rozwiązanie — Keycloak.
Nie każdy element aplikacji trzeba piec od zera. Czasem lepiej użyć gotowego, sprawdzonego składnika — szczególnie jeśli mówimy o bezpieczeństwie. Logowanie to nie dekoracja na wierzchu aplikacji, tylko jeden z jej fundamentów. Jeżeli fundament jest słaby, cały projekt może się posypać.
Kontekst projektu
Pracowaliśmy nad aplikacją webową, która miała być dostępna dla kilku typów użytkowników. Część osób miała korzystać z podstawowego panelu, a administratorzy potrzebowali dostępu do dodatkowych funkcji zarządzania.
Na początku wymagania były klasyczne: użytkownik zakłada konto, loguje się, może zresetować hasło, a administrator nadaje mu odpowiednie uprawnienia. Brzmiało prosto. Ale po rozpisaniu szczegółów szybko okazało się, że samo logowanie może stać się osobnym mini-projektem.
Logowanie to nie tylko formularz
Logowanie to jedna z tych funkcji, które wyglądają prosto tylko na makiecie. Formularz logowania można napisać szybko. Bezpieczny system uwierzytelniania to już zupełnie inna historia.
Największym wyzwaniem nie było stworzenie formularza logowania. Problemem było wszystko, co dzieje się dookoła: bezpieczne hashowanie haseł, obsługa resetu hasła, wygasanie sesji, odświeżanie tokenów, role i uprawnienia, zabezpieczenie przed brute force, historia logowań, możliwość dodania 2FA, integracja z logowaniem Google lub Microsoft oraz utrzymanie całego mechanizmu przez kolejne lata.
Własny moduł logowania oznaczałby więc nie tylko więcej kodu na start, ale też większą odpowiedzialność za bezpieczeństwo i utrzymanie. I tutaj pojawia się najważniejszy wniosek: logowanie to nie tylko ekran z inputem na email i hasło. To cały obszar bezpieczeństwa aplikacji.
Dlaczego wybraliśmy gotowe rozwiązanie
Zamiast budować wszystko od zera, zaproponowaliśmy wykorzystanie gotowego systemu zarządzania tożsamością — Keycloak. W takim podejściu aplikacja nie musi sama implementować wszystkich mechanizmów związanych z kontami użytkowników. Zamiast tego korzysta z rozwiązania, które zostało stworzone właśnie do obsługi logowania, sesji, ról i integracji z zewnętrznymi dostawcami.
Aplikacja nadal może mieć własny interfejs, własną logikę biznesową i własną bazę danych. Różnica polega na tym, że odpowiedzialność za uwierzytelnianie zostaje przeniesiona do narzędzia, które jest do tego przeznaczone. Gotowe narzędzie nie odbiera kontroli nad aplikacją — ono zdejmuje z zespołu część odpowiedzialności za najbardziej wrażliwy fragment systemu.
Jak Keycloak pomógł ograniczyć ryzyko
Keycloak to dojrzałe narzędzie open source do zarządzania tożsamością i dostępem (IAM). Obsługuje między innymi logowanie i rejestrację użytkowników, reset hasła, role i grupy, tokeny JWT oraz standard OAuth2 i OpenID Connect, logowanie przez zewnętrznych dostawców (Google, Microsoft, GitHub), dwuskładnikowe uwierzytelnianie (2FA), zarządzanie sesjami, panel administracyjny oraz polityki haseł.
Dzięki temu projekt zyskał mniej własnego kodu odpowiedzialnego za bezpieczeństwo, szybsze wdrożenie logowania, łatwiejszą obsługę ról i uprawnień, możliwość dodania 2FA bez przebudowy aplikacji, gotowy panel administracyjny do zarządzania użytkownikami, prostszą integrację z Google i Microsoft, lepszą skalowalność rozwiązania oraz mniejsze ryzyko popełnienia błędów w krytycznym obszarze aplikacji.
W tym projekcie nie chodziło o to, żeby napisać jak najwięcej kodu. Chodziło o to, żeby dostarczyć bezpieczne rozwiązanie możliwie rozsądnie.
Kiedy własne logowanie nadal ma sens
Własne logowanie ma sens w bardzo prostych projektach albo wtedy, gdy wymagania są specyficzne i świadomie akceptujemy koszt utrzymania. Jeśli aplikacja ma dosłownie jednego rodzaju użytkownika, nie planuje integracji z zewnętrznymi dostawcami i raczej nie będzie rosła — prosty własny moduł może być wystarczającym wyborem.
Ale w aplikacjach biznesowych, panelach B2B, SaaS-ach czy systemach z rolami użytkowników gotowe rozwiązanie najczęściej będzie rozsądniejszym wyborem. Nie chodzi o to, że programista nie potrafi napisać logowania. Chodzi o to, że w profesjonalnym projekcie warto inwestować czas tam, gdzie powstaje realna wartość biznesowa, a nie w ponowne tworzenie mechanizmów, które istnieją, są sprawdzone i rozwijane od lat.
Wnioski dla firm planujących aplikację
Jeśli planujesz aplikację z kontami użytkowników, rolami i bezpiecznym dostępem do panelu — warto już na etapie planowania porozmawiać o tym, jak ma wyglądać system logowania. Decyzja o tym, co budujemy samodzielnie, a co opieramy na gotowych, sprawdzonych rozwiązaniach, ma bezpośredni wpływ na koszt projektu, czas realizacji i bezpieczeństwo systemu.
Nie wciskamy klientowi customowego rozwiązania tylko dlatego, że możemy je napisać. Dobieramy technologię do problemu, budżetu, ryzyka i przyszłego rozwoju projektu. Najlepszy kod to czasem ten, którego nie trzeba pisać samemu.
