Wprowadzenie
Autoryzacja to nie tylko kwestia bezpieczeństwa. To element UX, który decyduje o tym, czy użytkownik czuje się swobodnie, czy rezygnuje z Twojego SaaS. Przez lata pracy przy platformach B2B i B2C widzę jeden powtarzający się schemat: firmy skupiają się na uwierzytelnianiu (logowanie, SSO, MFA), a autoryzację traktują po macoszemu. Efekt? Rozbudowana kontrola dostępu staje się labiryntem, który hamuje sprinty i irytuje klientów.
1. RBAC na sterydach – gdy rola nie wystarcza
Role-Based Access Control (RBAC) to standard. Jednak w praktyce wiele firm wrzuca do jednej roli zbyt wiele uprawnień, bo łatwiej dodać kolejną rolę niż przemyśleć model. Kończymy z 20 rolami, z których nikt nie wie, co faktycznie robią.
Realny przykład: W startupie logistycznym mieli role: „menedżer”, „super-menedżer”, „admin magazynu”, „admin systemu”. Różnica między pierwszą a drugą polegała na dostępie do raportów finansowych. Zamiast tego wystarczyłoby dodać atrybut finansów do roli menedżera i warunek w API. Rozwiązanie? Użyj ABAC (Attribute-Based Access Control) tam, gdzie potrzebujesz fine-grained permissions. To więcej logiki, ale mniej roli i chaosu.
2. Płaska struktura organizacyjna w kodzie
SaaS-y często odwzorowują strukturę firmy w modelu autoryzacji. To błąd. Firma zmienia się szybciej niż kod. Gdy dział IT zaczyna raportować do CFO, a nie do CTO, trzeba przebudowywać drzewo uprawnień. Zamiast tego zaprojektuj autoryzację wokół zasobów i akcji, a nie hierarchii.
Przykład: Firma wdrożyła moduł projektowy dla „wszystkich działów”. Po roku okazało się, że marketing nie powinien widzieć kosztów wewnętrznych. Musieli dodawać ręczne wykluczenia. Gdyby od początku zdefiniowali uprawnienia do raportów kosztowych jako osobny resource, dodanie reguły nie wymagałoby zmian w strukturze.
3. Brak audytu i testowania autoryzacji
Autoryzacja jest testowana rzadziej niż logowanie. A to właśnie błędy autoryzacji (np. IDOR – Insecure Direct Object Reference) są najczęstszym źródłem wycieków danych. Firmy koncentrują się na odporności na ataki, a zapominają o testowaniu, czy użytkownik z rolą „edytor” nie może przypadkiem usuwać zasobów innego klienta.
Jak to robić dobrze: Automatyzuj testy dla każdego endpointu z różnymi rolami. Używaj moków, aby sprawdzić, czy serwer zwraca 403 tam, gdzie powinien, a nie tylko 401. Bonus: rejestruj każde nieudane żądanie autoryzacji – to źródło wiedzy o tym, czy użytkownicy próbują wykonać akcje, do których nie mają prawa (często to sygnał, że potrzebują wyższej roli).
Podsumowanie
Autoryzacja to nie firewall. To mapa uprawnień, która rośnie razem z produktem. Złe decyzje na początku – jak przerost RBAC, sztywna hierarchia czy brak testów – będą generować dług techniczny i frustrację. Zamiast dokładać kolejne role, przemyśl model atrybutów i zasobów. A jeśli już masz bałagan – audyt autoryzacji to pierwszy krok do odzyskania kontroli.
Twoi klienci nie muszą wiedzieć, jak działa Twój system autoryzacji. Ale jeśli zaczną mieć problemy z dostępem do swoich danych – dowiedzą się szybko.
