Auth w aplikacji: typowe błędy w logowaniu, rolach i sesjach (i jak je naprawić)

Logowanie i uprawnienia to zwykle pierwsza funkcja, która „działa na demie”, a potem psuje się na produkcji. Powód jest prosty: auth dotyka wszystkiego naraz — UX, bezpieczeństwa, backendu, mobilki, zgodności i wsparcia klienta. Jeden drobny skrót na początku (np. słabe odświeżanie sesji albo role trzymane tylko po stronie frontu) potrafi wrócić po kilku miesiącach jako realny incydent: wycieki danych, eskalacja uprawnień albo permanentne wylogowywanie użytkowników.

W tym artykule masz praktyczny przegląd najczęstszych błędów w obszarze logowania, ról i sesji. Każdy punkt zawiera objawy, ryzyko, szybkie poprawki i docelowe rozwiązanie. Na końcu znajdziesz checklistę wdrożeniową, którą możesz przekleić do Jiry i zamknąć temat metodycznie, bez chaosu.

1) Mieszanie uwierzytelniania (authentication) z autoryzacją (authorization)

Najczęstsza pomyłka: „użytkownik jest zalogowany, więc może to zrobić”. To nieprawda. Authentication odpowiada na pytanie „kim jesteś?”, a authorization „co możesz zrobić?”. Gdy te warstwy są zlepione, system zaczyna żyć wyjątkami.

Objawy

• Reguły dostępu rozrzucone po endpointach i komponentach.
• „Tymczasowe” if-y dla jednego klienta, które zostają na stałe.
• Niespójne decyzje: API zwraca 403, ale UI pokazuje akcję.

Jak naprawić

• Wprowadź centralną politykę dostępu (RBAC lub ABAC) po stronie backendu.
• Każdy endpoint ma jawnie wskazaną wymaganą akcję (np. invoice.read, invoice.approve).
• Frontend traktuj jako warstwę prezentacji, nie źródło decyzji bezpieczeństwa.

2) Role tylko na froncie

Ukrycie przycisku „Usuń użytkownika” w UI nie jest zabezpieczeniem. Jeśli backend nie sprawdza uprawnień, wystarczy ręczny request.

Szybki test

• Zaloguj się kontem o niskich uprawnieniach.
• Przechwyć request narzędziem devtools/Postman.
• Zmień payload i odpal endpoint administracyjny.

Jeżeli backend przepuszcza — masz krytyczny błąd.

Poprawka

• Autoryzacja obowiązkowo na serwerze, per endpoint i per zasób.
• Wrażliwe operacje loguj z userId, actorRole, resourceId.
• Dla operacji wysokiego ryzyka dołóż „step-up auth” (ponowne hasło/MFA).

3) Nadużywanie JWT bez planu na unieważnianie

JWT bywa wygodny, ale źle użyty prowadzi do sesji, których nie da się szybko odciąć. Typowy antywzorzec: access token ważny 7 dni, bez rotacji i bez blacklisty.

Dobre podejście

• Krótki access token (np. 10–20 min).
• Refresh token z rotacją i detekcją reuse.
• Możliwość natychmiastowego revoke (lista unieważnionych, wersjonowanie sesji).

Jeśli nie potrzebujesz JWT w architekturze rozproszonej, zwykła sesja serwerowa bywa prostsza i bezpieczniejsza operacyjnie.

4) Brak higieny sesji i urządzeń

Użytkownik powinien widzieć, gdzie jest zalogowany, i móc zakończyć podejrzane sesje. Bez tego support rośnie, a ryzyko też.

• Lista aktywnych sesji: urządzenie, lokalizacja przybliżona, ostatnia aktywność.
• „Wyloguj z wszystkich urządzeń” jednym kliknięciem.
• Automatyczny timeout nieaktywności.
• Osobna polityka dla panelu admina (krótsze TTL, wymuszone MFA).

5) Złe przechowywanie tokenów i ciasteczek

W aplikacjach webowych najbezpieczniej trzymać token sesyjny w HttpOnly cookie, z Secure i odpowiednim SameSite. Trzymanie tokenu w localStorage zwiększa ryzyko przy XSS.

Minimum produkcyjne

• Secure + HTTPS wszędzie.
• HttpOnly dla wartości sesyjnej.
• SameSite=Lax lub Strict (zależnie od flow).
• CSRF token dla wrażliwych akcji opartych o cookie.

6) Jedna rola „admin” do wszystkiego

Gdy system rośnie, „admin” staje się workiem bez dna. To utrudnia audyt i łamie zasadę najmniejszych uprawnień.

Lepszy model

• Role biznesowe (np. Owner, Finance, Support, Viewer).
• Uprawnienia granularne (read/write/approve/export).
• Dziedziczenie tylko tam, gdzie naprawdę potrzebne.
• Przegląd uprawnień kwartalnie.

Zobacz też: Kontrakt API: jak spisać specyfikację, żeby development przyspieszył.

7) Brak izolacji tenantów (multi-tenant)

W SaaS to klasyk: poprawne logowanie, ale błędny filtr danych i użytkownik widzi rekordy innej firmy. To nie jest „bug UI”, tylko incydent bezpieczeństwa.

Jak ograniczyć ryzyko

• tenant_id wymagany na każdym poziomie zapytania.
• Policy enforcement w warstwie repozytorium lub DB (RLS tam, gdzie ma sens).
• Testy integracyjne „cross-tenant leakage”.

8) Brak monitoringu zdarzeń auth

Bez logów bezpieczeństwa nie odtworzysz incydentu i nie wykryjesz anomalii. Potrzebujesz telemetryki, nie tylko „200 OK”.

• Loguj logowania udane/nieudane, reset hasła, zmianę roli, MFA challenge.
• Dodaj alerty na nietypowe wzorce: wiele faili, nierealny geovelocity, masowe resety.
• Wdroż retencję i redakcję danych wrażliwych.

9) Kiepski UX resetu hasła i odzyskiwania konta

Najwięcej frustracji użytkownika dzieje się właśnie tutaj. Zbyt restrykcyjny flow blokuje legalnych użytkowników, zbyt luźny otwiera furtki atakującym.

Balans praktyczny

• Jednorazowe linki z krótkim TTL.
• Brak ujawniania, czy email istnieje („jeśli konto istnieje, wysłaliśmy link”).
• Powiadomienie o zmianie hasła na niezależny kanał.
• Rate limiting i captcha tam, gdzie ruch jest podatny na abuse.

10) Brak planu migracji, gdy auth już działa „jako tako”

Wiele zespołów wie, że auth jest przeciętny, ale boi się ruszać. Słusznie — to krytyczna ścieżka. Dlatego potrzebny jest plan etapowy.

Plan 30/60/90

• 30 dni: inwentaryzacja endpointów, ról, tokenów i sesji; szybkie łatki krytyczne.
• 60 dni: centralizacja polityk, rotacja refresh tokenów, monitoring zdarzeń.
• 90 dni: hardening (MFA dla adminów, step-up auth, testy penetracyjne i chaos testy sesji).

Checklist wdrożeniowy (kopiuj-wklej)

• [ ] Każdy endpoint ma jawne wymagane uprawnienia.
• [ ] Autoryzacja jest egzekwowana na backendzie, nie tylko w UI.
• [ ] Access token ma krótki TTL, refresh token jest rotowany.
• [ ] Istnieje mechanizm revoke sesji/tokenu.
• [ ] Cookie i CSRF ustawione zgodnie z polityką bezpieczeństwa.
• [ ] Role są granularne i zgodne z zasadą least privilege.
• [ ] Testy sprawdzają izolację tenantów.
• [ ] Logi auth są kompletne i mają alerting.
• [ ] Flow resetu hasła ma zabezpieczenia anty-abuse.
• [ ] Dla panelu admina wymuszone MFA.

Podsumowanie

Najdroższy błąd to myślenie, że auth jest „zrobiony”, bo użytkownik potrafi się zalogować. Produkcyjne auth to ciągła praktyka: jasny model uprawnień, krótkie sesje, dobra obserwowalność i regularne przeglądy. Jeśli zrobisz te fundamenty porządnie, oszczędzasz czas devów, nerwy supportu i realne ryzyko biznesowe.

FAQ

Czy JWT jest zawsze lepszy od sesji serwerowej?

Nie. JWT jest wygodny w części architektur, ale sesje serwerowe często są prostsze do odwoływania i bezpieczniejsze operacyjnie.

Kiedy wprowadzić MFA?

Natychmiast dla ról uprzywilejowanych (admin, finance, owner). Dla pozostałych stopniowo, zależnie od ryzyka.

Co poprawić najpierw, jeśli mamy mało czasu?

Backendowe sprawdzanie uprawnień, skrócenie TTL access tokenu, rotację refresh tokenu i monitoring logowań.