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.

Autor: zespół Convert Studio — software house z Kielc i Krakowa, projektujemy aplikacje webowe, sklepy i wdrożenia AI dla firm.

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

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ę.

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.

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

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.