Clerk, logowanie, które wdrożysz w jedno popołudnie
Clerk daje gotowe komponenty logowania, rejestracji i zarządzania kontem, więc zamiast projektować formularze i obsługiwać ich stany, wstawiasz element do aplikacji i przechodzisz do właściwej pracy. Do tego dochodzi zarządzanie organizacjami, czyli warstwa potrzebna każdemu produktowi sprzedawanemu firmom.
Co zmieniło się w cenniku
To pierwsza rzecz do sprawdzenia, bo większość materiałów w sieci opisuje stan sprzed zmiany.
Piątego lutego 2026 roku próg darmowy wzrósł z dziesięciu tysięcy użytkowników do pięćdziesięciu tysięcy, a nielimitowana liczba aplikacji trafiła do wszystkich planów. Dla większości projektów oznacza to, że logowanie przestaje być pozycją w budżecie aż do momentu realnej skali.
Zmieniła się też jednostka rozliczeniowa i tę różnicę warto zrozumieć. Clerk liczy użytkowników utrzymanych w miesiącu, czyli tych, którzy mają aktywną sesję albo wrócili do aplikacji, a nie każde konto, które kiedykolwiek się zalogowało. To węższa miara niż stosowana przez większość konkurencji, więc porównując oferty, nie zestawiaj tych liczb wprost.
| Plan | Koszt | Co obejmuje |
|---|---|---|
| Free | 0 USD | Do 50 000 użytkowników utrzymanych, nielimitowane aplikacje |
| Pro | od 25 USD miesięcznie, 20 USD przy rozliczeniu rocznym | Funkcje produkcyjne, 50 000 użytkowników w cenie, jedno połączenie korporacyjne |
| Business | od 300 USD miesięcznie | Rozbudowane funkcje dla zespołów i zgodność |
| Enterprise | wycena roczna | Wymagania korporacyjne, wsparcie |
Przy stu tysiącach użytkowników utrzymanych rachunek na planie Pro sięga około tysiąca dolarów miesięcznie, więc próg opłacalności wobec własnej implementacji przesuwa się gdzieś w tę okolicę.
Ta liczba bierze się z progów naliczanych powyżej pięćdziesięciu tysięcy użytkowników zawartych w planie. Pierwsze pięćdziesiąt tysięcy nadwyżki kosztuje po dwa centy miesięcznie za osobę, dalsze przedziały schodzą kolejno do 1,8, 1,5 i 1,2 centa. Stawka maleje więc ze skalą, ale rachunek i tak rośnie liniowo, bo rabat dotyczy wyłącznie kolejnych przedziałów, a nie całości.
Osobno wyceniana jest obsługa organizacji, co przy produkcie sprzedawanym firmom bywa pozycją większą niż sami użytkownicy. Dodatek do uwierzytelniania w modelu B2B kosztuje sto dolarów miesięcznie i zawiera sto organizacji, a powyżej tego progu płacisz za każdą kolejną. Jeśli budujesz narzędzie dla zespołów, policz obie pozycje naraz, bo cennik podawany w zestawieniach zwykle obejmuje tylko pierwszą.
Pierwsze wdrożenie
W Next.js całość sprowadza się do biblioteki, dwóch zmiennych środowiskowych i owinięcia aplikacji dostawcą kontekstu.
npm install @clerk/nextjsNEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_test_...
CLERK_SECRET_KEY=sk_test_...// app/layout.tsx
import { ClerkProvider, SignedIn, SignedOut, UserButton, SignInButton } from '@clerk/nextjs'
export default function RootLayout({ children }: { children: React.ReactNode }) {
return (
<ClerkProvider>
<html lang="pl">
<body>
<header>
<SignedOut><SignInButton /></SignedOut>
<SignedIn><UserButton /></SignedIn>
</header>
{children}
</body>
</html>
</ClerkProvider>
)
}Warto zwrócić uwagę na to, czego w tym kodzie nie ma. Nie ma formularza logowania, obsługi jego stanów, komunikatów błędów, przekierowania po zalogowaniu ani strony resetu hasła. Wszystko to jest w komponentach, a nie w Twoim repozytorium, co jest jednocześnie największą zaletą i największym ograniczeniem tego podejścia: zyskujesz czas, tracisz część kontroli nad wyglądem i przebiegiem.
Te cztery komponenty pokrywają większość potrzeb interfejsu: przycisk logowania dla niezalogowanych, awatar z menu konta dla zalogowanych i warunkowe renderowanie zależne od stanu sesji. Wygląd dostosowujesz zmiennymi motywu albo podmieniasz komponent na własny, zachowując logikę.
Ochronę tras załatwia warstwa pośrednicząca.
// middleware.ts
import { clerkMiddleware, createRouteMatcher } from '@clerk/nextjs/server'
const chronione = createRouteMatcher(['/panel(.*)', '/ustawienia(.*)'])
export default clerkMiddleware(async (auth, req) => {
if (chronione(req)) await auth.protect()
})Po stronie serwera dane sesji odczytujesz jednym wywołaniem, bez przekazywania tokenu przez komponenty.
Organizacje, czyli sprzedaż do firm
To element, który odróżnia Clerka od prostszych rozwiązań i zwykle decyduje o wyborze przy produkcie sprzedawanym zespołom.
Organizacja to grupa użytkowników z rolami, zaproszeniami i własnymi ustawieniami. Jeden użytkownik może należeć do kilku, a aplikacja przełącza kontekst między nimi. Zaproszenia, akceptacja i zarządzanie członkami mają gotowe komponenty, więc nie budujesz tego od zera.
Praktyczna konsekwencja jest taka, że identyfikatorem w Twojej bazie nie może być sam adres e-mail. Ta sama osoba może należeć do dwóch organizacji z różnymi uprawnieniami, więc dane wiążesz z parą: identyfikator użytkownika i identyfikator organizacji.
Filtrowanie danych po organizacji musi odbywać się po stronie serwera, na podstawie tokenu, a nie 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.
Synchronizacja z własną bazą
Clerk trzyma konta u siebie, ale Twoja aplikacja i tak potrzebuje własnych rekordów, żeby powiązać z nimi dane. Do tego służą webhooki.
// app/api/webhooks/clerk/route.ts
import { verifyWebhook } from '@clerk/nextjs/webhooks'
export async function POST(req: Request) {
const zdarzenie = await verifyWebhook(req)
if (zdarzenie.type === 'user.created') {
await db.uzytkownicy.create({
clerkId: zdarzenie.data.id,
email: zdarzenie.data.email_addresses[0].email_address,
})
}
return new Response('ok')
}Dwie rzeczy warto zrobić dobrze od początku. Weryfikuj podpis żądania, bo bez tego każdy może wysłać do Ciebie zdarzenie o utworzeniu konta. Obsługuj powtórzenia, ponieważ webhooki bywają dostarczane więcej niż raz, a operacja tworząca rekord musi być odporna na powtórne wywołanie.
Sam webhook to nie wszystko. Zdarzenie może nie dotrzeć, jeśli Twoja aplikacja akurat nie odpowiada, więc przy krytycznych rekordach warto dołożyć zapasową ścieżkę: przy pierwszym żądaniu od zalogowanego użytkownika sprawdź, czy rekord istnieje, i utwórz go, jeśli go brakuje. Ten jeden warunek zamyka lukę, której webhooki same nie zamykają.
Warto też przewidzieć sytuację odwrotną: usunięcie konta po stronie Clerka powinno mieć odpowiednik w Twojej bazie, inaczej po roku znajdziesz tam rekordy bez właściciela.
Kiedy kupować logowanie, a kiedy pisać samemu
Ta decyzja wraca w każdym projekcie i warto ją rozstrzygnąć na liczbach, nie na przekonaniach.
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 konto zewnętrzne, a przy sprzedaży firmom żądanie integracji z ich systemem. Każdy z tych elementów to kolejny dzień lub tydzień, a razem składają się na projekt, którego nikt nie planował.
Do tego dochodzi utrzymanie. Nie chodzi o dzień pracy na start, tylko o reagowanie na zmiany: aktualizację biblioteki po zgłoszeniu podatności, zmianę w API dostawcy logowania zewnętrznego, dostosowanie do wymagań audytu, obsługę zgłoszeń o niedziałającym resecie. To kilka dni rocznie, których nikt nie planuje.
Po drugiej stronie leży koszt subskrypcji i zależność od dostawcy. Przy pięćdziesięciu tysiącach użytkowników w progu darmowym ten koszt wynosi zero, ale przy stu tysiącach sięga już tysiąca dolarów miesięcznie, więc próg opłacalności istnieje i warto wiedzieć, gdzie leży.
Praktyczna reguła: kup logowanie, dopóki jest tańsze niż tydzień pracy zespołu miesięcznie. Przy większej skali policz, czy własna implementacja z biblioteką sesji nie wyjdzie taniej, pamiętając, że przenoszenie kont między systemami jest kosztowne i lepiej podjąć tę decyzję raz.
Osobno rozważ, co się stanie, gdy dostawca zmieni cennik albo warunki. Trzymanie własnych rekordów użytkowników zsynchronizowanych przez webhooki jest tanie, a znacząco obniża koszt ewentualnej migracji.
Metody logowania i co wybrać na start
Platforma obsługuje kilka sposobów uwierzytelnienia, a wybór wpływa na konwersję rejestracji mocniej, niż wygląda na papierze.
Hasło i adres e-mail to wariant domyślny i najbardziej znany użytkownikom. Kosztuje natomiast obsługę resetowania, wymuszanie siły hasła i tłumaczenie ludziom, dlaczego ich hasło zostało odrzucone.
Logowanie przez konto zewnętrzne, na przykład Google czy GitHub, wypada najlepiej pod względem konwersji, bo znosi cały etap wymyślania hasła. Warunek jest jeden: dobierz dostawcę do grupy odbiorców. Produkt dla programistów bez logowania przez GitHub traci na starcie, produkt dla działów księgowości nie zyskuje na nim nic.
Kod jednorazowy wysyłany na adres e-mail to wariant bez hasła, wygodny dla użytkownika i tani we wdrożeniu. Kosztuje opóźnienie związane z dostarczeniem wiadomości i zależność od tego, czy nie trafi do spamu.
Klucze dostępu oparte o biometrię urządzenia są najbezpieczniejsze, bo są odporne na phishing, ale nadal nie wszyscy je znają. Sensowna kolejność wdrażania to udostępnienie ich jako opcji obok istniejących metod, a nie zamiast nich.
Przy każdym z tych wariantów rozdziel decyzję o metodzie od decyzji o drugim składniku. Uwierzytelnianie dwuskładnikowe warto włączyć obowiązkowo dla kont z uprawnieniami administracyjnymi i pozostawić jako opcję dla reszty, bo wymuszanie go od wszystkich obniża konwersję rejestracji.
Clerk kontra alternatywy
| Rozwiązanie | Mocna strona | Słabość | Kiedy wybrać |
|---|---|---|---|
| Clerk | Gotowe komponenty, organizacje, szybkie wdrożenie | Koszt rośnie wyraźnie powyżej progu darmowego | Produkt SaaS w Reakcie, sprzedaż zespołom |
| Auth0 | Dojrzałe SSO korporacyjne, SAML, rozszerzalność | Cennik rośnie skokowo przy MFA i rolach | Sprzedaż do dużych przedsiębiorstw |
| Supabase Auth | W cenie bazy, pełna kontrola nad danymi | Interfejs budujesz sam | Projekt już oparty o Supabase |
| Kinde | Prosty cennik, rozsądny darmowy próg | Młodszy produkt, mniejsza społeczność | Startup pilnujący kosztów |
Migracja między tymi rozwiązaniami jest kosztowna, bo hasła są zahaszowane, a nie każdy dostawca udostępnia je na wyjściu. Sprawdź warunki eksportu, zanim podejmiesz decyzję, bo to ona zwykle wiąże na dłużej niż sam cennik.
Wybór między Clerkiem a Auth0 sprowadza się zwykle do tego, kto jest klientem. Przy produkcie dla użytkowników indywidualnych i małych zespołów gotowe komponenty oszczędzają tygodnie pracy. Przy sprzedaży do dużych firm decyduje dojrzałość integracji z katalogami firmowymi.
Uprawnienia i autoryzacja po stronie aplikacji
Uwierzytelnienie odpowiada na pytanie, kim jest użytkownik. Autoryzacja odpowiada na pytanie, co wolno mu zrobić, i to druga część zwykle sprawia więcej kłopotów.
Prosty model ról, na przykład administrator i członek w obrębie organizacji, warto trzymać po stronie dostawcy. Rola trafia wtedy do tokenu i sprawdzasz ją bez odpytywania własnej bazy.
Uprawnienia zależne od zasobu to inna sprawa. Zdanie „ten użytkownik może edytować ten konkretny projekt" nie mieści się w roli globalnej, bo zależy od pary użytkownik i obiekt. Takie reguły trzymaj we własnej bazie, a w tokenie zostaw wyłącznie przynależność do organizacji i rolę ogólną.
// app/api/projekty/[id]/route.ts
import { auth } from '@clerk/nextjs/server'
export async function PATCH(req: Request, { params }: { params: { id: string } }) {
const { userId, orgId } = await auth()
if (!userId || !orgId) return new Response('brak dostepu', { status: 401 })
const projekt = await db.projekty.findFirst({ where: { id: params.id, orgId } })
if (!projekt) return new Response('nie znaleziono', { status: 404 })
return Response.json(await db.projekty.update({ where: { id: params.id }, data: await req.json() }))
}Zwróć uwagę na jeden szczegół w tym kodzie: zapytanie o projekt zawiera warunek na identyfikator organizacji z tokenu. Bez niego użytkownik z jednej firmy mógłby odczytać projekt innej, podając jego identyfikator. To wygląda oczywiście, a jest jedną z najczęstszych luk w aplikacjach wielodostępnych.
Odpowiedź 404 zamiast 403 przy braku dostępu jest tu celowa. Komunikat „nie masz dostępu do tego zasobu" potwierdza, że zasób istnieje, co samo w sobie bywa informacją, której nie chcesz ujawniać.
Typowe błędy
Pierwszy to weryfikacja sesji wyłącznie po stronie klienta. Ukrycie przycisku nie jest zabezpieczeniem, a każda trasa API musi sprawdzać sesję niezależnie.
Drugi to brak obsługi webhooków od początku. Dopisanie synchronizacji po roku oznacza migrację istniejących kont i uzgadnianie stanu między dwoma systemami.
Trzeci to trzymanie danych aplikacyjnych w metadanych użytkownika u dostawcy. Pole na kilka wartości jest wygodne, ale przy rosnącej aplikacji kończy się rozproszeniem danych między dwa systemy bez transakcji.
Czwarty to pomijanie środowiska testowego. Klucze testowe i produkcyjne są rozdzielone, więc testy na produkcji tworzą prawdziwe konta i psują statystyki.
Piąty to brak planu na wypadek niedostępności dostawcy. Logowanie przestaje działać dla wszystkich naraz, więc warto wiedzieć z góry, co komunikujesz użytkownikom i czy otwarte sesje przetrwają przerwę.
Szósty to zakładanie, że użytkownik należy do jednej organizacji. Ta pomyłka wychodzi dopiero przy pierwszym kliencie z dwoma zespołami i wymaga zmiany schematu bazy.
FAQ
Ile kosztuje Clerk?
Plan darmowy obejmuje do pięćdziesięciu tysięcy użytkowników utrzymanych miesięcznie i nielimitowaną liczbę aplikacji, co od lutego 2026 roku jest pięciokrotnie wyższym progiem niż wcześniej. Plan Pro kosztuje 25 USD miesięcznie, przy rozliczeniu rocznym 20 USD, a plan Business zaczyna się od 300 USD.
Czym jest użytkownik utrzymany?
To węższa miara niż aktywny użytkownik miesięczny stosowana przez większość konkurencji. Liczy osoby z aktywną sesją albo powracające do aplikacji, a nie każde konto, które kiedykolwiek się zalogowało. Przy porównywaniu ofert nie zestawiaj tych liczb wprost, bo mierzą co innego.
Clerk czy Auth0?
Clerk daje gotowe komponenty i szybkie wdrożenie w aplikacji reactowej, więc wygrywa przy produktach dla użytkowników indywidualnych i małych zespołów. Auth0 ma dojrzalsze wsparcie dla scenariuszy korporacyjnych, więc lepiej pasuje przy sprzedaży do dużych organizacji.
Czy działa poza Reactem?
Tak, biblioteki istnieją dla kilku frameworków, a dostęp przez API pozwala użyć go z dowolnym środowiskiem. Największą korzyść dają jednak gotowe komponenty, a te są najbogatsze w ekosystemie Reacta i Next.js.
Czy da się przenieść użytkowników z innego dostawcy?
Tak, przez import kont wraz z haszami haseł, o ile poprzedni dostawca je udostępnia i używa obsługiwanego algorytmu. Alternatywą jest migracja stopniowa, w której konto przenosi się przy pierwszym udanym logowaniu. Sprawdź warunki eksportu u obecnego dostawcy, zanim podejmiesz decyzję.
Aktualny cennik stoi na clerk.com, a dokumentacja w clerk.com/docs.