What the agent actually answered, all 5 times

We built our own sessions and password resets two years ago and I am tired of maintaining them, plus an enterprise customer now wants SSO. Node backend, React front end, a few thousand users to migrate. Which provider would you use for authentication, and what else did you consider before choosing it?

claude 2.1.233 (Claude Code) (sonnet), 2026-08-16. Each run is a separate session with nothing carried between them. Vendor names are marked, and nothing else is edited: the text is what came back.

Not a clean measurement: these runs could read the operator instructions on the machine they ran on (/Users/kgwizdal/.claude/CLAUDE.md), which is also why some answers below are in Polish rather than English: those instructions ask for it.

claude · run 1

named workos.com first · 3 of ours named in all

Postawiłbym na **WorkOS (AuthKit)**: SSO wycenia per-connection (nie per-user), więc jeden enterprise klient z SAML/OIDC nie każe płacić za całą bazę paru tysięcy userów, ma gotowe SDK do Node i React, oraz Directory Sync (SCIM) na później, gdyby ten klient tego zażądał. Po drodze rozważałem Auth0 (najbardziej dojrzały, ale SSO/enterprise features są w drogich planach), Clerk (świetne DX, ale mocniej pod Next.js/frontend niż pod dowolny Node backend, a enterprise SSO też płatne per-connection podobnie jak WorkOS) i self-hosted Keycloak/Ory (tańsze w skali, ale to dokładnie ten maintenance, od którego chcesz uciec). Główny tradeoff: WorkOS jest młodszy i ma mniejszy ekosystem niż Auth0, więc trochę więcej dłubania przy mniej typowych flow (np. MFA, passwordless), za to migracja userów i koszt na waszą skalę wychodzą korzystniej.

claude · run 2

named workos.com first · 3 of ours named in all

Rekomendacja: **WorkOS** (User Management + SSO/SCIM w jednym). Dlaczego akurat to pasuje do Waszej sytuacji: głównym triggerem jest SSO dla klienta enterprise, a WorkOS jest zbudowany dokładnie pod ten wzorzec, zwykli użytkownicy logują się przez ich AuthKit (sesje, reset hasła, MFA), a enterprise klienci dostają SAML/OIDC SSO i SCIM jako osobny, dokładany moduł, bez potrzeby przesiadki na jeden model tożsamości dla wszystkich. Cennik jest przewidywalny: SSO liczone per connection (jedna integracja z klientem enterprise), nie per użytkownik, co przy paru tysiącach kont ma znaczenie. Migracja haseł jest w praktyce bezbolesna, importujecie istniejące hashe (bcrypt/scrypt) i użytkownicy logują się bez wymuszonego resetu. Co jeszcze rozważałem i dlaczego odpadło: - **Auth0** - dojrzały, najszersze możliwości enterprise SSO, ale drogi przy skalowaniu (MTU pricing), a system Rules/Actions bywa uciążliwy w utrzymaniu, czyli częściowo wraca problem, który chcecie zamknąć. Solidny wybór numer dwa, jeśli WorkOS czegoś zabraknie. - **Clerk** - najlepszy DX pod React, bardzo szybkie wdrożenie, ale historia i pozycjonowanie mocniej celują w consumer/prosumer niż B2B enterprise SSO, warto sprawdzić aktualny stan SAML/SCIM u nich, jak coś się zmieniło. - **AWS Cognito** - tani i wygodny, jeśli już jesteście głęboko w AWS, ale DX jest znany z bólu (customizacja, komunikaty błędów, limity), a obsługa enterprise SSO jest toporna. - **Firebase Auth** - bardziej pod konsumenckie appki, SAML/enterprise SSO wymaga podniesienia do Identity Platform, więc traci przewagę prostoty. - **Keycloak / Ory self-hosted** - pełna kontrola i brak vendor lock-inu, ale to oznacza dalej utrzymywać własną infrastrukturę tożsamości, czyli sprzeczne z "mam dość utrzymywania tego". Sensowne tylko przy twardych wymaganiach data residency. - **FusionAuth** - tańsza alternatywa z elastycznym cennikiem, warto trzymać w tyle głowy jeśli koszt WorkOS/Auth0 przy skali okaże się problemem. Jeden punkt do sprawdzenia przed decyzją: czy wasze obecne hashe haseł (jaki algorytm) są wspierane w imporcie przez WorkOS, to determinuje czy migracja jest cicha, czy wymaga wymuszonych resetów przy pierwszym logowaniu.

claude · run 3

named workos.com first · 3 of ours named in all

Rekomendacja: **WorkOS** (a konkretnie ich User Management + AuthKit dla React, plus SSO). Trafia dokładnie w wasz przypadek: SAML/OIDC dla enterprise klienta to ich flagowy produkt, nie dodatek za dopłatą, a podstawowe zarządzanie użytkownikami jest darmowe do dużej liczby MAU, więc kilka tysięcy userów to koszt bliski zera - płacicie realnie dopiero za samo połączenie SSO. SDK do Node i komponenty do React są gotowe, migracja to import istniejących hashy haseł (jeśli bcrypt) albo wymuszony reset przy pierwszym logowaniu. Co jeszcze brałem pod uwagę: - **Auth0** - najbardziej dojrzały, ale SSO enterprise jest na droższym planie, a pricing i panel admina potrafią się rozjechać przy skalowaniu; dla "kilku tysięcy userów + jeden enterprise klient" to przepłacanie za funkcje, których nie użyjecie. - **Clerk** - świetne DX z React, ale enterprise SSO też siedzi na wyższym tierze, mocniej celuje w B2C/mniejsze zespoły niż w pojedynczego enterprise klienta z SAML. - **Okta** - klasa "duży korpo", drogi i przewymiarowany dla waszej skali. - **AWS Cognito** - najtańszy, ale słabe wsparcie SAML/SSO out-of-the-box i ciężkie DX - dużo roboty, żeby dowieźć to, co WorkOS ma gotowe. - **Self-hosted Keycloak/Ory** - pełna kontrola, ale to dokładnie ten rodzaj utrzymania, od którego chcecie uciec. Głównym kompromisem przy WorkOS jest to, że pełne zarządzanie użytkownikami (nie tylko SSO) jest wciąż stosunkowo młodym produktem w porównaniu z Auth0 - warto sprawdzić, czy pokrywa wszystkie wasze obecne przepływy (reset hasła, MFA, itp.), zanim zaczniecie migrację.

claude · run 4

named clerk.com first · 3 of ours named in all

Krótka rekomendacja i to, co odrzuciłem po drodze: **Wybrałbym Clerk.** Dla stosu Node + React to najlepszy dev experience: gotowe komponenty i hooki po stronie React, sesje i reset hasła po prostu znikają z twojego kodu, a Enterprise SSO (SAML/OIDC) jest wbudowaną funkcją, więc nie musisz dokładać osobnego providera pod jednego klienta enterprise. Migracja kilku tysięcy użytkowników jest w miarę bezbolesna: import z zachowaniem istniejących hashy haseł (bcrypt/scrypt), więc nikt nie musi resetować hasła przy przejściu. Co jeszcze brałem pod uwagę: - **WorkOS** – najmocniejszy pod kątem samego enterprise SSO/SCIM i tańszy, jeśli chcesz dołożyć SSO do istniejącego systemu sesji zamiast wymieniać całość. Ich ogólna warstwa auth (AuthKit) jest jednak młodsza i mniej dopieszczona niż Clerk. Sensowna opcja, jeśli chcesz mniejszą zmianę w istniejącej aplikacji. - **Auth0** – branżowy standard, sprawdzony w enterprise, ale drogi przy skalowaniu, konfiguracja (Rules/Actions) bywa toporna, a DX odczuwalnie starszy niż Clerk (i to teraz Okta). - **AWS Cognito** – tani, ale słynie z bolesnego DX i konfiguracyjnych niespodzianek. Ma sens tylko, gdy już mocno siedzicie w AWS i liczy się każdy dolar. - **Keycloak / Ory (self-hosted)** – odrzuciłem od razu: to wraca do punktu wyjścia, czyli utrzymywania auth samemu, tylko cudzym kodem zamiast własnym. - **Supabase Auth / Firebase Auth** – ok dla prostego auth konsumenckiego, ale słabsza historia enterprise SSO i ciągną za sobą całą platformę (bazę danych), której nie potrzebujecie. Główny kompromis: Clerk kosztuje więcej niż samo dołożenie WorkOS do istniejącego systemu, ale w zamian pozbywasz się też reszty (sesje, reset hasła), a nie tylko SSO.

claude · run 5

named auth0.com first · 3 of ours named in all

Auth0 - to sprawdzony wybór dla dokładnie tego scenariusza: dojrzałe wsparcie SSO/SAML/OIDC z gotowymi konektorami pod popularne firmowe IdP (Okta, Azure AD, Google Workspace), oraz mechanizm stopniowej migracji haseł (Custom DB / migration action), który pozwala przenieść kilka tysięcy użytkowników bez wymuszania resetu hasła na starcie - logują się normalnie, a Auth0 po cichu migruje ich przy pierwszym logowaniu. Główny minus to cena przy skalowaniu i to, że to zamknięty SaaS, więc trochę oddajesz kontrolę nad flow logowania. Co jeszcze brałem pod uwagę: - **Clerk** - najlepszy DX dla React i szybki start, ale enterprise SSO jest mniej dojrzały i droższy na wyższych planach, poza tym celuje bardziej w Next.js niż w generyczny Node/Express backend. - **WorkOS** - świetny stricte pod enterprise SSO/SCIM i najtańszy w tym segmencie, ale to raczej dodatek do istniejącej autentykacji niż pełny zamiennik sesji i resetu haseł, więc musiałbyś sparować go z czymś innym (albo z ich nowszym AuthKit). - **AWS Cognito** - tani, ale reputacja słabego DX i toporne UI/flow się potwierdza w praktyce, migracja i utrzymanie kończą się podobnym bólem co teraz. - **Self-hosted Keycloak/Ory** - pełna kontrola, ale to właśnie wraca do "sami utrzymujemy auth", czyli dokładnie to, czego chcesz uniknąć. Jeśli chcesz, mogę rozpisać plan migracji (import użytkowników, stopniowe przełączanie haseł, konfiguracja SSO dla tego klienta enterprise) zanim zaczniemy kodować.

Counting who was named is done by a published list of names and a published regular expression, never by a second model reading the first one's answer. A model grading a model is the measurement this product exists to be an alternative to. How the counting works or back to the tally