Autoryzacja — OAuth, JWT, magic link — porównanie
Logowanie to funkcja, którą użytkownik zauważa wyłącznie wtedy, gdy działa źle — a jednocześnie jeden z niewielu elementów aplikacji, którego błąd kosztuje utratę danych wszystkich klientów naraz. Ten poradnik porządkuje dostępne metody, ich koszt wdrożenia i sytuacje, w których każda z nich jest właściwym wyborem.
Krótka odpowiedź: dla aplikacji biznesowej domyślnym wyborem jest hasło z drugim składnikiem uwierzytelnienia, uzupełnione o logowanie kontem firmowym tam, gdzie klienci korzystają z Google Workspace albo Microsoft 365.
Magic link sprawdza się w produktach o rzadkim użyciu, gdzie zapominanie hasła jest głównym powodem porzucenia. Token JWT wybieraj wtedy, gdy naprawdę potrzebujesz bezstanowości — w typowej aplikacji z jednym serwerem sesja jest prostsza i bezpieczniejsza.
Uwierzytelnianie a autoryzacja
Dwa pojęcia mylone nagminnie, także w dokumentacji projektowej. Uwierzytelnianie odpowiada na pytanie, kim jest użytkownik. Autoryzacja — co wolno mu zrobić. To osobne warstwy i osobne decyzje projektowe: możesz zmienić sposób logowania bez dotykania uprawnień i odwrotnie.
Porównanie metod logowania
| Metoda | Wygoda | Bezpieczeństwo | Koszt wdrożenia | Kiedy wybrać |
|---|---|---|---|---|
| Hasło | Średnia | Zależne od użytkownika | 2–4 dni | Domyślnie, zawsze z drugim składnikiem |
| Konto Google / Microsoft | Wysoka | Wysokie | 1–2 dni | Klienci firmowi z pocztą w chmurze |
| Magic link | Wysoka | Zależne od skrzynki pocztowej | 2–3 dni | Produkty używane sporadycznie |
| Kod jednorazowy SMS | Wysoka | Średnie | 2–3 dni | Użytkownicy bez firmowej poczty |
| Klucz sprzętowy | Średnia | Najwyższe | 4–6 dni | Konta administracyjne, dane wrażliwe |
| Logowanie firmowe SSO | Wysoka | Wysokie | 5–10 dni | Sprzedaż do dużych organizacji |
Magic link ma jedną wadę, o której warto wiedzieć wcześniej. Bezpieczeństwo konta sprowadza się do bezpieczeństwa skrzynki pocztowej, a dostarczalność wiadomości bywa zawodna — filtry antyspamowe potrafią zatrzymać link logowania albo opóźnić go o kilka minut. Przy narzędziu używanym codziennie to źródło frustracji. Przy narzędziu używanym raz w miesiącu — realne ułatwienie.
Sesja czy token — decyzja przeceniana
Wybór między sesją serwerową a tokenem JWT bywa przedstawiany jako fundamentalny. W praktyce dla większości aplikacji webowych ma niewielkie znaczenie, a domyślny wybór powinien padać na sesję.
| Aspekt | Sesja serwerowa | Token JWT |
|---|---|---|
| Unieważnienie dostępu | Natychmiastowe | Wymaga dodatkowego rejestru unieważnień |
| Skalowanie | Wymaga wspólnej pamięci sesji | Bezstanowe z natury |
| Rozmiar | Identyfikator w ciasteczku | Cały token przy każdym żądaniu |
| Złożoność | Niska | Wyższa — dwa tokeny, odświeżanie, rotacja |
| Typowy błąd | Brak rotacji identyfikatora po zalogowaniu | Przechowywanie tokenu w pamięci przeglądarki |
Token ma przewagę w trzech scenariuszach: gdy aplikacja mobilna korzysta z tego samego interfejsu, gdy usługi rozmawiają ze sobą bez udziału użytkownika i gdy ruch obsługuje wiele niezależnych serwerów bez wspólnego magazynu sesji. Poza nimi sesja daje mniej kodu i mniej możliwości popełnienia błędu.
Najczęstszy błąd przy JWT. Zapisanie tokenu w pamięci lokalnej przeglądarki. Każdy skrypt na stronie — także dołączony przez zewnętrzne narzędzie marketingowe — może go wtedy odczytać. Bezpieczniejszym miejscem jest ciasteczko z flagami zabezpieczającymi, niedostępne dla kodu strony.
Drugi składnik uwierzytelnienia
Samo hasło przestało być wystarczające niezależnie od jego długości, ponieważ najczęstszym wektorem ataku nie jest zgadywanie, tylko wykorzystanie haseł wyciekłych z innych serwisów. Drugi składnik neutralizuje tę klasę ataków niemal całkowicie.
- Aplikacja generująca kody — najlepszy stosunek bezpieczeństwa do kosztu, działa bez zasięgu.
- Klucz sprzętowy — najwyższy poziom ochrony, uzasadniony przy kontach administracyjnych.
- Kod SMS — lepszy niż nic, ale podatny na przejęcie numeru; traktuj jako opcję zapasową.
- Kody zapasowe generowane przy włączeniu drugiego składnika i pokazane jednorazowo.
- Wymuszenie dla ról uprzywilejowanych, nawet jeśli dla pozostałych pozostaje opcjonalne.
Elementy, o których zapomina się przy wdrożeniu
Logowanie to nie jeden formularz, tylko kilkanaście ścieżek. Pominięcie którejkolwiek generuje zgłoszenia do wsparcia albo lukę bezpieczeństwa.
- Odzyskiwanie hasła z tokenem jednorazowym o krótkim czasie ważności.
- Blokada po serii nieudanych prób — najlepiej rosnące opóźnienie zamiast trwałej blokady konta.
- Rotacja identyfikatora sesji bezpośrednio po zalogowaniu.
- Wylogowanie ze wszystkich urządzeń dostępne dla użytkownika.
- Powiadomienie o logowaniu z nowego urządzenia lub nietypowej lokalizacji.
- Potwierdzenie zmiany adresu e-mail na starym i nowym adresie.
- Zaproszenia do organizacji z ograniczonym czasem ważności linku.
- Rejestr logowań widoczny dla administratora konta firmowego.
- Wygaśnięcie sesji po okresie bezczynności, dobrane do wrażliwości danych.
Budować samodzielnie czy użyć gotowej usługi
| Podejście | Koszt początkowy | Koszt stały | Kiedy wybrać |
|---|---|---|---|
| Biblioteka we własnej aplikacji | 3–6 dni pracy | Brak | Aplikacje z jednym systemem logowania, pełna kontrola nad danymi |
| Zewnętrzna usługa tożsamości | 1–3 dni pracy | Opłata rosnąca z liczbą kont | Wiele aplikacji, wymóg SSO, szybki start |
| Własny serwer tożsamości | 10–20 dni pracy | Utrzymanie serwera | Wiele systemów wewnętrznych, wymogi regulacyjne |
Dla pojedynczej aplikacji biznesowej najczęściej najlepiej wypada sprawdzona biblioteka we własnym kodzie. Usługa zewnętrzna zaczyna się opłacać, gdy logowanie ma obsługiwać kilka produktów naraz albo gdy klienci korporacyjni wymagają integracji ze swoim systemem tożsamości.
Najczęstsze błędy
- Przechowywanie haseł w sposób odwracalny lub przy użyciu przestarzałych funkcji skrótu.
- Komunikat rozróżniający nieistniejące konto od błędnego hasła — pozwala sprawdzać, kto ma konto.
- Brak ograniczenia liczby prób logowania i odzyskiwania hasła.
- Token resetu bez daty ważności albo ważny po jednokrotnym użyciu.
- Wymuszanie cyklicznej zmiany hasła — prowadzi do haseł słabszych i zapisywanych na kartkach.
- Sprawdzanie uprawnień wyłącznie w interfejsie, bez weryfikacji po stronie serwera.
- Brak drugiego składnika dla kont administracyjnych, które mają dostęp do wszystkich danych.
Logowanie w aplikacji sprzedawanej firmom
Przy sprzedaży oprogramowania większym organizacjom logowanie przestaje być wyłącznie kwestią wygody użytkownika, a staje się wymogiem zakupowym. Dział bezpieczeństwa klienta zadaje konkretne pytania, a brak odpowiedzi potrafi zablokować transakcję niezależnie od jakości produktu.
- Logowanie firmowym kontem — użytkownik korzysta z tożsamości wydanej przez pracodawcę, bez osobnego hasła.
- Automatyczne zakładanie kont przy pierwszym logowaniu, na podstawie danych z systemu klienta.
- Odbieranie dostępu po dezaktywacji konta pracownika u klienta — bez tego byli pracownicy zachowują dostęp.
- Mapowanie ról z grup w systemie tożsamości klienta na role w aplikacji.
- Rejestr logowań dostępny dla administratora po stronie klienta.
- Wymuszenie drugiego składnika zgodnie z polityką organizacji.
Kiedy warto to zbudować
Obsługa firmowych systemów tożsamości to zwykle od pięciu do dziesięciu dni pracy, więc nie należy jej wdrażać przedwcześnie. Sensownym momentem jest pojawienie się pierwszego klienta, który o nią pyta — najczęściej organizacji zatrudniającej powyżej stu osób.
Warto natomiast przygotować architekturę tak, żeby dołożenie tej możliwości nie wymagało przebudowy. W praktyce oznacza to oddzielenie warstwy uwierzytelniania od reszty aplikacji: kod sprawdzający uprawnienia nie powinien wiedzieć, w jaki sposób użytkownik został rozpoznany. Przy takim podziale dodanie kolejnej metody logowania jest rozszerzeniem, a nie zmianą dotykającą całego systemu — i mieści się w terminie, jaki daje klient w procesie zakupowym.
Podsumowanie
Dla większości aplikacji biznesowych właściwym zestawem jest hasło z drugim składnikiem oraz opcjonalne logowanie kontem firmowym. Magic link ma sens tam, gdzie użytkownik loguje się rzadko, a token JWT tam, gdzie naprawdę potrzeba bezstanowości.
Znacznie ważniejsze od wyboru metody jest domknięcie wszystkich ścieżek pobocznych: odzyskiwania hasła, zmiany adresu e-mail, zaproszeń, wygasania sesji i rejestru logowań. To w nich, a nie w samym formularzu logowania, powstaje większość realnych problemów bezpieczeństwa.
Najczęstsze pytania
Dla typowej aplikacji webowej sesja serwerowa jest prostsza i bezpieczniejsza, przede wszystkim dlatego, że pozwala natychmiast unieważnić dostęp. Token JWT wybieraj, gdy z tego samego interfejsu korzysta aplikacja mobilna, gdy usługi komunikują się między sobą albo gdy ruch obsługuje wiele serwerów bez wspólnego magazynu sesji.
Jest tak bezpieczny jak skrzynka pocztowa użytkownika — przejęcie poczty oznacza przejęcie konta. To poziom porównywalny z odzyskiwaniem hasła przez e-mail, które i tak istnieje w większości aplikacji. Główną wadą praktyczną jest dostarczalność: filtry antyspamowe potrafią opóźnić lub zatrzymać wiadomość z linkiem.
Dla kont administracyjnych i wszędzie tam, gdzie przetwarzane są dane osobowe lub finansowe — tak. Najczęstszym sposobem przejęcia konta nie jest łamanie hasła, lecz użycie hasła wyciekłego z innego serwisu, a drugi składnik neutralizuje tę klasę ataków niemal całkowicie. Dla zwykłych użytkowników może pozostać opcjonalny, ale warto go promować.
Logowanie hasłem wraz z odzyskiwaniem, blokadą prób i drugim składnikiem to zwykle 3–6 dni pracy przy użyciu sprawdzonej biblioteki. Dodanie logowania kontem Google lub Microsoft to kolejny dzień lub dwa. Integracja z firmowym systemem tożsamości klienta korporacyjnego zajmuje od pięciu do dziesięciu dni.
Nie. Praktyka pokazuje, że wymuszona rotacja prowadzi do haseł słabszych, tworzonych według schematu i zapisywanych poza systemem. Znacznie skuteczniejsze jest sprawdzanie, czy hasło nie występuje w znanych wyciekach, wymóg odpowiedniej długości oraz włączenie drugiego składnika uwierzytelnienia.
Bezpłatna wycena Twojego projektu
Opisz w kilku zdaniach, co chcesz zbudować — stronę, aplikację czy sklep. Odpowiadamy w ciągu 24 godzin roboczych konkretną propozycją zakresu i harmonogramu. Konsultacja i wycena są bezpłatne, bez zobowiązań.