Auth0, logowanie i zarzadzanie tozsamoscia

Auth0, logowanie i zarządzanie tożsamością bez własnego backendu

Auth0 przejmuje logowanie, rejestrację, resetowanie hasła, uwierzytelnianie dwuskładnikowe i połączenia z dostawcami korporacyjnymi. Twoja aplikacja przekierowuje użytkownika na stronę logowania, a w zamian dostaje token, który weryfikujesz. Od 2021 roku produkt należy do Okty, co przełożyło się na mocniejszą pozycję w segmencie korporacyjnym i na kształt cennika.

Kiedy warto oddać logowanie na zewnątrz

Napisanie logowania na e-mail i hasło zajmuje dzień. Problem zaczyna się później: resetowanie hasła, blokada po nieudanych próbach, wykrywanie haseł z wycieków, kody jednorazowe, logowanie przez Google, potem żądanie klienta korporacyjnego o SAML, a na końcu audyt bezpieczeństwa.

Warto też policzyć, ile kosztuje utrzymanie własnego rozwiązania po wdrożeniu. Nie chodzi o dzień pracy na start, tylko o reagowanie na zmiany: nową wersję biblioteki po wykryciu podatności, zmianę w API dostawcy logowania społecznościowego, dostosowanie do wymagań audytu, obsługę zgłoszeń o niedziałającym resecie hasła. To kilka dni pracy rocznie, których nikt nie planuje, a które wypadają zwykle w najgorszym momencie.

Auth0 zaczyna się opłacać przy trzecim punkcie z tej listy. Jeśli aplikacja ma jeden sposób logowania i nie sprzedaje się firmom, własna implementacja z biblioteką sesji bywa tańsza i prostsza. Jeśli w planach jest sprzedaż do przedsiębiorstw, logowanie kupuje się, bo SAML i SCIM napisane samodzielnie to projekt na kwartał.

Drugim argumentem jest odpowiedzialność. Baza haseł na własnym serwerze to zobowiązanie, które ciąży przy każdym audycie i każdym incydencie. Przeniesienie jej do dostawcy nie zwalnia z obowiązków wobec danych osobowych, ale zdejmuje najbardziej ryzykowny element.

Cennik i pułapka liczby użytkowników

Rozliczenie opiera się na aktywnych użytkownikach miesięcznie, czyli liczbie kont, które choć raz się zalogowały. Konto nieużywane przez miesiąc nie liczy się do limitu.

Zestawienie wygląda dziwnie i warto rozumieć dlaczego. Darmowy plan obsługuje 25 tysięcy użytkowników, ale bez własnej domeny, MFA i ról. Płatny plan startuje od 500 użytkowników, ponieważ płacisz za funkcje, nie za skalę. Zespół z pięcioma tysiącami użytkowników i wymogiem MFA płaci więcej niż zespół z dwudziestoma tysiącami użytkowników bez tego wymogu.

Naliczanie powyżej progu działa przedziałami, a nie stawką za pojedynczego użytkownika: przekroczenie liczby zawartej w planie przenosi rachunek do następnego przedziału w całości. Przy aplikacji z sezonowymi skokami ruchu policz więc koszt w miesiącu szczytowym, a nie średnim, bo jeden taki miesiąc ustawia rachunek na wyższym poziomie.

Druga rzecz nieoczywista przy porównywaniu ofert to osobna ścieżka dla produktów sprzedawanych firmom. Te same plany w wariancie business kosztują wielokrotnie więcej, bo Essentials zaczyna się tam od stu pięćdziesięciu dolarów, a Professional od ośmiuset. Jeśli budujesz narzędzie z logowaniem po stronie organizacji, patrz od razu na tę kolumnę.

Pierwsza integracja

W Next.js wystarcza oficjalna biblioteka i cztery zmienne środowiskowe.

npm install @auth0/nextjs-auth0

AUTH0_SECRET=wygenerowany_losowy_ciag
AUTH0_BASE_URL=http://localhost:3000
AUTH0_ISSUER_BASE_URL=https://twoja-domena.eu.auth0.com
AUTH0_CLIENT_ID=...
AUTH0_CLIENT_SECRET=...

Sesję po stronie serwera odczytujesz jednym wywołaniem, bez przekazywania tokenu przez komponenty.

// app/panel/page.tsx
import { getSession } from '@auth0/nextjs-auth0'
import { redirect } from 'next/navigation'

export default async function Panel() {
  const sesja = await getSession()
  if (!sesja) redirect('/api/auth/login')

  return <h1>Witaj, {sesja.user.name}</h1>
}

Przy wdrożeniu na Vercela pamiętaj o zmianie AUTH0_BASE_URL na adres produkcyjny i dopisaniu adresów zwrotnych w panelu Auth0. Pominięcie tego drugiego kroku to najczęstsza przyczyna błędu callback URL mismatch przy pierwszym wdrożeniu.

Actions, czyli logika w procesie logowania

Actions to funkcje w JavaScripcie uruchamiane w wybranych momentach: po weryfikacji danych logowania, przed wydaniem tokenu, po rejestracji. Tam trafia logika, której nie da się wyrazić konfiguracją.

exports.onExecutePostLogin = async (event, api) => {
  const namespace = 'https://twojaaplikacja.pl'

  if (!event.user.email_verified) {
    api.access.deny('Potwierdz adres e-mail przed zalogowaniem.')
    return
  }

  api.idToken.setCustomClaim(`${namespace}/rola`, event.user.app_metadata.rola ?? 'uzytkownik')
  api.accessToken.setCustomClaim(`${namespace}/organizacja`, event.user.app_metadata.organizacja)
}

Dwie rzeczy warto wiedzieć od początku. Własne pola w tokenie wymagają przedrostka w formie adresu URL, bo standard OIDC zabrania dodawania nazw bez przestrzeni nazw. Actions wykonują się przy każdym logowaniu, więc odpytywanie w nich zewnętrznego API wydłuża czas logowania wszystkim użytkownikom.

Dane trwałe użytkownika trzymaj w app_metadata, bo tego pola użytkownik nie zmieni. Pole user_metadata jest edytowalne przez samego zainteresowanego i nie nadaje się na role ani uprawnienia.

Passkeys i uwierzytelnianie dwuskładnikowe

Klucze dostępu oparte na WebAuthn zastępują hasło danymi biometrycznymi urządzenia. Dla użytkownika to logowanie odciskiem palca, dla aplikacji odporność na phishing, bo klucz jest związany z domeną.

Adaptacyjne MFA włącza drugi składnik warunkowo: przy logowaniu z nowego kraju, nieznanego urządzenia albo przy nietypowej porze. To sensowny kompromis, bo stały wymóg kodu przy każdym logowaniu obniża konwersję, a całkowity brak drugiego składnika zostawia konta otwarte po wycieku hasła.

Kolejność wdrażania, która sprawdza się w praktyce: najpierw wykrywanie haseł z wycieków, potem MFA dla kont administracyjnych, następnie MFA adaptacyjne dla reszty, na końcu passkeys jako opcja dla chętnych. Odwrotna kolejność kończy się zgłoszeniami do wsparcia i porzuconymi rejestracjami.

Organizacje, czyli wielodostępność w praktyce

Aplikacja sprzedawana firmom potrzebuje pojęcia organizacji: użytkownik należy do jednej lub kilku, ma w każdej inną rolę, a dane są od siebie odseparowane. Auth0 ma to wbudowane jako Organizations i warto z tego skorzystać zamiast budować własny model.

Praktyczne konsekwencje są trzy. Ten sam adres e-mail może należeć do dwóch organizacji, więc identyfikatorem użytkownika nie może być e-mail, tylko para identyfikator konta i identyfikator organizacji. Logowanie może zaczynać się od wyboru organizacji albo od adresu, z którego domena wskazuje właściwą. Zaproszenia do organizacji obsługuje platforma, co oszczędza budowania własnego przepływu z tokenami w linkach.

W tokenie dostępu pojawia się wtedy pole z identyfikatorem organizacji i to na jego podstawie API filtruje dane. Kluczowe, żeby filtrowanie działo się po stronie serwera na podstawie tokenu, a nie na podstawie parametru przysłanego przez klienta. Pomyłka w tym miejscu to najpoważniejsza klasa błędów w aplikacjach wielodostępnych, bo pozwala zobaczyć dane cudzej firmy przez podmianę jednego identyfikatora w żądaniu.

Model ról także warto trzymać po stronie Auth0 tylko wtedy, gdy jest prosty. Przy uprawnieniach zależnych od zasobu, na przykład dostępie do konkretnego projektu, sensowniej trzymać je we własnej bazie, a w tokenie umieszczać wyłącznie przynależność do organizacji i rolę ogólną.

Firmowe SSO krok po kroku

Żądanie logowania przez system klienta pojawia się zwykle w trakcie negocjacji, a nie w planie na kwartał. Dobrze wiedzieć wcześniej, co ono oznacza.

Klient przekazuje metadane swojego dostawcy tożsamości, najczęściej w formie adresu XML albo pliku. Konfigurujesz połączenie w Auth0, wskazujesz je jako dostępne dla organizacji tego klienta i mapujesz atrybuty, czyli decydujesz, które pole z ich katalogu jest imieniem, a które adresem e-mail.

Największa niespodzianka dotyczy zwykle grup. Klient przysyła listę grup katalogowych o własnym nazewnictwie i oczekuje, że przełożą się na role w Twojej aplikacji. To mapowanie robisz w Actions, a jego kształt warto uzgodnić przed podpisaniem umowy, bo indywidualne reguły dla każdego klienta rosną szybciej niż zespół.

Drugą sprawą jest wyłączenie logowania hasłem dla użytkowników z domeny klienta. Firma, która wdraża SSO, zwykle wymaga, żeby dostęp bez ich systemu przestał działać, także dla kont założonych wcześniej.

Auth0 kontra alternatywy

Decyzja rzadko jest odwracalna bez kosztów, bo migracja tożsamości między dostawcami wymaga przeniesienia haseł, które są zahaszowane. Auth0 pozwala importować hasze z popularnych formatów, ale nie wszystkie dostawcy udostępniają je na wyjściu. Sprawdź warunki eksportu, zanim wybierzesz platformę.

Bezpieczeństwo po Twojej stronie

Auth0 zabezpiecza logowanie, ale weryfikacja tokenu jest zadaniem aplikacji. Trzy błędy powtarzają się najczęściej.

Pierwszy to sprawdzanie samego podpisu bez weryfikacji pól aud i iss. Token wystawiony dla innej aplikacji w tym samym najemcy przejdzie taką kontrolę.

Drugi to trzymanie tokenu dostępu w localStorage. Skrypt wstrzyknięty na stronę odczyta go bez przeszkód. Ciasteczko z flagami HttpOnly i Secure jest bezpieczniejsze, a przy renderowaniu po stronie serwera także wygodniejsze.

Trzeci to podejmowanie decyzji o uprawnieniach na podstawie tokenu identyfikacyjnego zamiast tokenu dostępu. Pierwszy opisuje, kim jest użytkownik, drugi mówi, co wolno mu zrobić w konkretnym API.

Czwarty dotyczy czasu życia tokenów. Domyślne ustawienia bywają zbyt hojne dla aplikacji obsługującej dane finansowe, a zbyt surowe dla narzędzia używanego przez cały dzień. Krótki token dostępu i dłuższy token odświeżający z rotacją to układ, który godzi wygodę z możliwością odcięcia sesji po wykryciu nadużycia. Bez rotacji wykradziony token odświeżający działa aż do wygaśnięcia i nie ma jak go unieważnić punktowo.

Osobno warto ustawić rotację kluczy podpisujących i sprawdzić, czy biblioteka po stronie aplikacji pobiera je dynamicznie z punktu JWKS, a nie ma ich zaszytych na stałe.

Typowe błędy przy wdrożeniu

Pierwszy to brak środowiska testowego. Osobny najemca dla wersji roboczej kosztuje nic, a pozwala testować zmiany w Actions bez ryzyka zablokowania logowania na produkcji.

Drugi to konfiguracja klikana w panelu bez zapisu w repozytorium. Po roku nikt nie pamięta, dlaczego dana reguła istnieje. Konfigurację da się eksportować i wersjonować narzędziem wiersza poleceń.

Trzeci to logowanie użytkowników z całego świata bez ustawienia regionu najemcy. Przekierowanie na serwer po drugiej stronie oceanu dokłada kilkaset milisekund do każdego logowania.

Czwarty to brak planu na wypadek niedostępności dostawcy. Logowanie przestaje działać dla wszystkich naraz, więc warto z góry wiedzieć, co wtedy komunikujesz użytkownikom i czy sesje już otwarte przetrwają awarię. Dłuższy czas życia sesji sprawia, że zalogowani nie odczują krótkiej przerwy.

Piąty to ignorowanie limitów zapytań do API zarządzania. Skrypt synchronizujący użytkowników nocą potrafi wyczerpać limit i cofnąć się z błędem, przez co część kont zostaje niezsynchronizowana bez żadnego alarmu.

FAQ

Ile kosztuje Auth0 przy tysiącu użytkowników?

Zależy od potrzebnych funkcji, nie od samej liczby. Tysiąc użytkowników mieści się w planie darmowym, jeśli wystarcza logowanie hasłem i społecznościowe. Wymóg MFA, ról albo integracji SSO przenosi projekt na plan Professional od 240 USD miesięcznie.

Czy da się migrować użytkowników z własnej bazy?

Tak, dwoma sposobami. Import haszy haseł działa, gdy używasz obsługiwanego algorytmu, na przykład bcrypt. Alternatywą jest migracja stopniowa, w której Auth0 przy pierwszym logowaniu odpytuje Twoją starą bazę i przenosi konto po poprawnym uwierzytelnieniu.

Czym Auth0 różni się od Clerk?

Auth0 celuje w scenariusze korporacyjne: SAML, katalogi firmowe, rozbudowane reguły. Clerk stawia na gotowe komponenty interfejsu i szybkie wdrożenie w aplikacji reactowej. Przy sprzedaży do dużych firm zwykle wygrywa Auth0, przy produkcie dla użytkowników indywidualnych częściej Clerk.

Czy Auth0 działa bez przekierowania na stronę logowania?

Da się zbudować własny formularz i wysyłać dane przez API, ale tracisz wtedy część zabezpieczeń wbudowanych w Universal Login, w tym ochronę przed atakami na hasła i wykrywanie botów. Rekomendowanym wariantem jest strona logowania z własnym stylem i domeną.

Co się dzieje po przekroczeniu limitu MAU?

Usługa działa dalej, a rachunek przechodzi do wyższego przedziału cenowego, bo dostawca nie nalicza nadwyżki od pojedynczego użytkownika. Warto ustawić alert na poziomie 80 procent limitu, bo próg przekracza się bez ostrzeżenia przy skoku ruchu, a skutkiem jest skok rachunku, a nie jego stopniowy wzrost.

Aktualny cennik stoi na auth0.com, a dokumentacja w auth0.com/docs.