Dlaczego nie powinieneś budować własnego systemu uwierzytelniania: lekcje z dziesiątek wywiadów z klientami

Uwierzytelnianie wygląda na coś, co możesz zrobić samodzielnie. E-mail, hasło, zhashować, porównać przy logowaniu. Jak trudne może być zbudowanie własnego systemu uwierzytelniania?

Możesz. To jest pułapka.

Rozmawialiśmy z dziesiątkami zespołów o autoryzacji, którą zbudowali sami. Większość przyszła do nas z tego samego powodu – to powstrzymywało rozwój biznesu.

Różne branże, stacki i wielkości, ale ten sam finał – własny auth zmienił się w dług, który zespół nosił na swoich barkach.

Dziwne jest to, że nigdy nie objawia się jako awaria. System loguje użytkowników i działa dobrze, dopóki jedna zmiana biznesowa nie blokuje drogi: audyt bezpieczeństwa, pierwszy klient korporacyjny, przejęcie, funkcja łącząca dwa produkty.

Tydzień temu było „w porządku”. Potem kolejna rzecz na roadmapie stoi za tym w kolejnce.

Największym błędem przy własnym auth jest traktowanie go jako funkcji. Możesz to napisać pierwszego dnia. Ale gdy prawdziwy ruch zaczyna przez to przechodzić, plącze się z Twoimi użytkownikami, organizacjami i uprawnieniami.

Uwierzytelnianie to nie jest funkcja. To infrastruktura tożsamości.

Za stroną logowania kryje się cały model tożsamości#

Każdy własny system auth zaczyna się tak samo. Weź e-mail i hasło, zhashuj, zapisz, porównaj przy logowaniu. Czterdzieści linijek kodu, czysto i zrobione.

Problem zaczyna się po uruchomieniu. Boty atakują endpoint rejestracji, więc dodajesz ograniczanie liczby prób, CAPTCHA, odcisk palca urządzenia. Kody SMS przestają się wysyłać pewnego ranka, więc dokładane są ponowne próby i limit dobowy. Potem pojawiają się trudniejsze tematy: bezpieczny reset hasła, MFA i jego proces odzyskiwania, sesje i refresh tokeny oraz model uprawnień, który to znacznie więcej niż zwykły boolean is_admin.

Nic z tego nie jest trudne samo w sobie. Każdy mieści się w jednym sprincie. Ale za każdym razem odpowiadasz na większe pytanie dotyczące produktu.

Zsumuj te odpowiedzi i dostajesz model tożsamości, który Twój produkt obecnie milcząco przyjmuje za prawdziwy: kto jest użytkownikiem, czy jedna osoba może należeć do kilku organizacji, jak system tożsamości klienta korporacyjnego się integruje i jak odbierasz dostęp przy odejściu użytkownika.

Każda następna funkcja traktuje te odpowiedzi jako pewnik i im dłużej system działa, tym trudniej je zmienić.

Widzieliśmy to w jednej firmie: pionowy B2B SaaS, dwadzieścia lat na rynku, obsługujące firmy z offline’u. Sami zbudowali auth ponad dekadę temu, osobny login dla każdego klienta i uprawnienia pisane prosto w modułach biznesowych. Na tamten czas to była rozsądna decyzja.

Dwudziest lat później chcieli czegoś, co brzmi na małą zmianę: jednolita strona logowania, gdzie e-mail jest loginem. To nie była zmiana strony – te uprawnienia rozlały się na setki modułów, a zjednoczenie logowania oznaczało dotknięcie modelu użytkownika, organizacji, migracji danych uwierzytelniających i każdej granicy uprawnień. Nikt nie chciał tego „przyklepać”, więc przeciągało się to latami.

Gdy napisali tę pierwszą stronę logowania, wyglądała jak funkcja. To, co po niej zostało, to cały model tożsamości.

Gdy Twój biznes rośnie, własny auth przestaje wystarczać#

Uczciwie mówiąc, własny auth zazwyczaj działa długo. Loguje ludzi, odświeża sesje i obsługuje codzienność nawet przez lata. Złożoność narasta powoli i ogarniasz ją „na bieżąco”, mając wrażenie kontroli.

Ale to, że „wystarcza” oznacza najczęściej, że biznes jeszcze nie uderzył w ścianę. Kiedy to się dzieje, problemem rzadko jest sam auth. To zmienił się biznes obok, i „wystarczający” staje się „na przeszkodzie” z dnia na dzień.

Poniższe sytuacje pojawiają się w większości produktów wraz ze skalą. Wyglądają różnie, ale w środku chodzi o to samo: biznes poszedł naprzód, a stary model tożsamości nie daje rady.

Klienci korporacyjni zaczynają żądać SSO#

Scenariusz: klient chce logować się przez własnego IdP, a Twój system auth nie zna pojęcia „czyjegoś innego dostawcy tożsamości”.

Pojawia się pierwsza poważna umowa korporacyjna, a dział zakupów przesyła wymagania. Najpierw SSO przez Microsoft Entra albo Google Workspace. Potem i SAML, i OIDC, bo kolejny klient używa czegoś innego. Potem SCIM do automatycznej obsługi zatrudniania i zwalniania pracowników.

Każda konfiguracja jest inna: inne protokoły, mapowania pól, rotacje certyfikatów, różnice w sposobie podpięcia ich organizacji do Twojej.

I prawie nic się nie powtarza. Następny klient – inny IdP i nowa konfiguracja, zaczynasz niemal od nowa. SSO to nie funkcja do zbudowania raz. Przy każdym dużym kliencie budujesz to ponownie, a koszt rośnie proporcjonalnie do liczby klientów.

Auth przestał być „pozwól użytkownikom zalogować się”. To „podłącz swój produkt do systemu tożsamości klienta”. Dwie zupełnie różne rzeczy.

Widzieliśmy firmę, gdzie całe SSO obsługiwał ręcznie jeden inżynier, który rozumiał wszystko od początku do końca. Gdy był obecny – klienci startowali. Gdy miał wolne – sprzedaż i wdrożenia stały w kolejce za nim. Gdy odszedł, wiedza wyszła z nim.

Tego nie rozważano w dniu podjęcia decyzji o własnym auth.

Produkt musi zunifikować rozproszoną tożsamość#

Scenariusz: dane tożsamości były rozproszone – osobno według organizacji i produktów, a wraz ze wzrostem biznesu pojawia się potrzeba jednej tożsamości.

Dwudziestoletnia firma z poprzedniego przykładu trafiła na to przy próbie zjednoczenia logowania – ten sam problem powtarza się w innych firmach. Pracowaliśmy z platformą, która przejęła dziewięć produktów, każde z osobnym auth i bazą użytkowników.

Przejęcie nie łączy tych systemów. Każdy nabyty produkt to nowy stos auth do utrzymania, a dziewięć równolegle wymaga już sporo ludzi tylko do serwisu.

Pytania mnożą się: czy ta sama osoba to jeden użytkownik w produktach A i B, czy dwa? Jak zestawić te same organizacje w obu? Jak autoryzować funkcję łączącą produkty? Gdy pracownik odchodzi, jak odciąć dostęp we wszystkich dziewięciu naraz? I gdzie to audytować?

Żaden z tych dziewięciu nie jest zepsuty. Razem tworzą mur.

„Zjednocz tożsamość” brzmi jak funkcja. W kodzie oznacza przedefiniowanie podstawy: czym jest użytkownik i organizacja. Prawie każda funkcja opiera się na starym opisie, więc zmiana przesuwa całą warstwę wyżej.

W erze AI agenci i CLI uzyskują dostęp w imieniu użytkownika#

Scenariusz: to już nie tylko ludzie logują się przez przeglądarkę. Teraz agenci, linie poleceń, skrypty – wszyscy podają się za użytkownika, a Twój auth zna tylko jedno: osobę logującą na stronie.

Agent musi wywołać narzędzia wewnętrzne w imieniu użytkownika. Serwer MCP udostępnia chronione zasoby. CLI musi uzyskać dostęp do konta bez przeglądarki.

Wszystkie trzy przypadki prowadzą do tych samych pytań: za którego użytkownika działa ten request, do jakich zasobów ma dostęp, komu wydaje się token, jaki ma zakres, jak go cofnąć, czy rejestrujesz to jako użytkownika czy agenta?

Stary system nie miał mechanizmów potrzebnych takim klientom. MCP korzysta z OAuth do autoryzacji. CLI loguje się przez OAuth lub korzysta z personalnego tokena, który może być cofnięty w każdej chwili. Tego nie budowano dla strony logowania.

Jeśli Twój auth powstał pod jeden login przez stronę, teraz musisz obsłużyć klienta działającego w imieniu tej osoby.

Długoterminowe utrzymanie to największy koszt własnego auth#

Nic z powyższych przypadków to nie „auth padł”. System działa. Każdy wygląda jak mała funkcja, ale od startu zmienia się w strategię produktu, migrację danych i obsługę klienta.

MFA jest tu najlepszym przykładem. Na powierzchni to „możemy sprawdzić raz jeszcze po logowaniu”.

Po dwóch krokach okazuje się: którym organizacjom i użytkownikom narzucić MFA, czy admin może wymusić to na członkach, czy czułe akcje jak zmiana płatności lub eksport wymagają ponownej weryfikacji, jak generujesz i resetujesz kody odzyskiwania, czy support może je resetować, czy MFA użytkownika SSO należy do Ciebie czy do IdP klienta? Dodanie MFA to cała nowa warstwa polityki bezpieczeństwa.

„Po prostu zsynchronizuj użytkowników” – też nie, za tym stoi ciąg decyzji nt. onboardingu, offboardingu i członkostwa między organizacjami, każdy zakładający, że Twój model użytkownika/organizacji był od razu właściwy.

Im więcej funkcji, tym bardziej utrzymujesz produkt tożsamości we własnym produkcie. Pierwsza wersja jest tania, kilku inżynierów i kilka tygodni. Ale karmisz ją rok po roku.

Ukryty koszt: rachunek po prostu zmienia sposób płatności#

Najczęstszy powód budowania własnego to koszt – i nie jest to naiwność.

Jedna organizacja członkowska, z którą rozmawialiśmy, zrobiła rachunek pięć lat temu. Mieli sto tysięcy członków, ale tylko kilka tysięcy logowało się regularnie. Dostawcy liczyli według wszystkich kont, wycena przebiła budżet i taniej było zbudować samemu. Na tamten rok to nie była zła decyzja.

Po pięciu latach liczby się odwróciły. Utrzymanie logowania i dbanie o bezpieczeństwo już kosztowało więcej niż zakup od dostawcy.

W roku pierwszym widzisz rachunek, a czas inżynierski nie. Po pięciu latach rachunek zostaje ten sam, a czas inżynierski zamienia się w opóźnienia, dług bezpieczeństwa i utrzymanie, którego nikt nie chce przejąć.

Więc zbudowanie własnego auth nie jest darmowe. Po prostu nigdy nie dostajesz faktury „subskrypcja uwierzytelniania”. Płacisz w miesiącach roboczych, opóźnieniach, poprawkach, długu bezpieczeństwa i energii inżynierskiej, którą można by spożytkować w produkcie właściwym.

Kilku inżynierów zostaje właścicielami systemu#

Ten inżynier od SSO to nie wyjątek. Po wystarczająco długim własnym auth kluczowy kontekst osiada na jednej-dwóch osobach: który klient ma jaką konfigurację, które pole nietykalne, czemu migracja odbyła się tak a nie inaczej. Rzadko trafi to do dokumentacji – żyje w czyjeś głowie.

Gdy jest dostępny, wdrożenia postępują. Gdy go nie ma, pipeline staje i okazuje się, że najważniejsza infrastruktura nie ma właściciela, tylko „osobę z wiedzą”.

Niektóre zespoły idą dalej i budują dla klientów całą platformę do samodzielnej konfiguracji SSO. Brzmi dobrze, póki nie zapytasz ilu klientów to obsługuje. Widzieliśmy system obsługujący 1,5 mln miesięcznych aktywnych dla… kilkunastu firm.

Myślałeś, że budujesz funkcję. Zbudowałeś produkt wewnętrzny, koszt rozłożył się na garstkę klientów. Jeśli tożsamość to Twój core, warto. Jeśli nie – to ukryty rachunek w czystej postaci.

Gdzie chcesz mieć swoich inżynierów?#

Wróćmy do tej firmy SaaS z dwudziestoletnim stażem. To nie słabi inżynierowie. Utrzymać produkt przez 20 lat to dowód, że znają klientów doskonale.

I tu tkwi problem. Wyrażając to wprost: czy chcesz, żeby ręcznie obsługiwali SSO każdego klienta i wyciągali dwadzieścia lat logiki uprawnień ze setek modułów, czy może szli głębiej w produkt branżowy?

To nie perfekcjonizm – to alokacja zasobów. Jeśli tworzysz bill pay, SaaS pionowy, portal członkowski lub oprogramowanie operacyjne – żaden klient nie zapłaci nic więcej, że masz własny serwer OAuth.

Jeden z zespołów bill pay powiedział jasno: sami napisałi IdP, działało, ale to decyzja strategiczna. Nie piszcie wiele o auth. Zaoszczędźcie energię na bill pay, a auth bierzcie najpewniejszy z rynku.

Auth musi być niezawodny. Ale „niezawodny” to nie znaczy „stworzony przez was”. Twoja baza danych, wysyłka maili i chmura też muszą być niezawodne, a dojrzały zespół nie zakłada, że wszystko musi być własne, skoro jest ważne.

W większości produktów auth to zależność podstawowa, nie przewaga konkurencyjna. O ile tożsamość nie jest Twoim core, własny produkt tożsamości w środku najczęściej nie jest fosą obronną – to wypływ zasobów na lata.

Kiedy własny auth wciąż ma sens?#

Łatwo popaść w skrajność: nigdy nie pisać auth. To też błąd.

Na pewnych etapach zrobienie własnego (lub połowy) ma sens: wewnętrzne demo, bardzo wczesny prototyp, jednorazowe walidacje. Albo jeśli masz bardzo specyficzną, szczegółową autoryzację, jakiej gotowe platformy nie obsłużą – wtedy zostaw to u siebie, ale całą resztę (auth, sesje, SSO, MFA, katalog użytkowników) daj na zewnątrz.

Uważaj tylko na efekt POC. Znamy typową ścieżkę: dwie osoby przez sześć-osiem miesięcy klecą prototyp integracji do systemu zewnętrznego. Metoda ok, efekt dobry. Ale nigdy nie miało to udźwignąć skali.

A POC najprościej przerobić w architekturę długoterminową. Po pół roku to „bieżące rozwiązanie”, po dwóch latach – „system legacy”, po pięciu – „infrastruktura, której nie da się ruszyć”. Najlepszy moment na odejście od własnego auth to nie gdy pęka, lecz zanim stanie się fundamentem.

Więc granica wygląda tak: pytanie nie brzmi, czy napisałeś linijkę auth. To, czy przyjąłeś na siebie genericki kawałek infrastruktury tożsamości do utrzymania na długie lata.

Buduj samodzielnie tylko rzeczy brzegowe. Uważaj na kluczową warstwę tożsamości. I nie buduj przez przypadek pełnej platformy CIAM.

Jeśli nie budujesz sam, jak wybierać auth?#

Jeśli decydujesz się nie pisać samemu, pojawia się następne pytanie: czyje wziąć i jak wybrać?

Większość dojrzałych rozwiązań już ma funkcje: SSO, MFA, wiele organizacji, zjednoczone logowanie, agent access. Więc prawdziwa różnica rzadko leży w spisie feature’ów.

Łatwo przeoczyć, a warto porównać poniższe. Wszystko sprowadza się do jednego: nie wychodź z kilku tysięcy linii własnego kodu by dać się zamknąć w innym systemie, z którego nie możesz wyjść.

• Trzymaj się standardowych protokołów, nie wymyślonych stosów jednego vendora. OIDC, OAuth, signed JWT RS256 – już to rozumiesz. Możesz czytać claimsy z normalnego tokena, bez uczenia się API konkretnego vendora.
• Zostaw sobie rzeczywiste wyjście. Jeśli rozwiązanie jest open-source i hostowalne własnoręcznie – możesz wyjść kiedy chcesz. (Utrzymanie samodzielnej wersji to oczywiście swój własny ukryty koszt).
• Nie pozwalaj billingowi śledzić Twojej tabeli użytkowników. Rozliczanie według liczby użytkowników lub aktywnych miesięcznie to tabela, która rośnie – wypełniana nieaktywnymi. W skali robi się z tego „podatek wzrostowy”. To ten cennik wepchnął organizację członkowską wyżej w budowę własnego auth.
• Twoje dane nie będą zamknięte. Możesz eksportować dane użytkowników kiedykolwiek. Powierzenie tych wrażliwych danych wyspecjalizowanemu hostowi chroni Cię przed ryzykiem trzymania prywatnych danych, których w ogóle nie powinieneś posiadać.

Pełna jasnośc: Logto to produkt auth, który zbudowaliśmy właśnie przeciw tym czterem punktom. Jest open-source, hostowalny samodzielnie i także jako zarządzana chmura: Cloud dla braku utrzymania, wersja Open Source dla pełnej kontroli. Gdy chcesz się przenieść, drzwi są otwarte.

Logowanie, MFA, SSO i RBAC działają gotowe, na standardowym OIDC, billing odnosi się do tokenów – płacisz za użycie.

Są inne dojrzałe opcje, a auth nigdy nie ma jednej właściwej odpowiedzi. Jeśli rozważasz, napisałem cały artykuł o jak wybrać dostawcę tożsamości, który może Ci pomóc.

Podsumowanie: nie myl infrastruktury tożsamości z zwykłą funkcją#

Własny auth ma sens pierwszego dnia. Haczyk – z czasem wyrasta na infrastrukturę.

Każdy krok biznesu to obnaża: enterprise chce SSO, bezpieczeństwo MFA, produkt – jednorazowe logowanie, produkty muszą się łączyć, agenci AI żądają dostępu dla użytkownika. Za każdą niepozorną funkcją stoi seria decyzji polityki, a karmienie własnego auth przez lata pożera czas inżynieryjny właściwego produktu.

Ten rachunek nie pojawia się na dzień dobry. Wychodzi po latach. Dopiero wtedy widać: ta strona logowania była od początku infrastrukturą tożsamości, która zostanie z produktem przez całe życie.

Auth raczej nie jest Twoją główną działalnością. Im wcześniej to zrozumiesz, tym szybciej oddasz czas, energię i pieniądze tworzonemu naprawde produktowi.

FAQ#

Czy nigdy nie powinieneś budować własnego systemu uwierzytelniania?#

Nie. Wczesne demo, narzędzia wewnętrzne, jednorazowe projekty walidujące, czy bardzo szczegółowa autoryzacja, której gotowce nie obsłużą – tu własny auth się nada. Unikaj przyjęcia na siebie generycznej infrastruktury tożsamości na wieczność, lądującej w utrzymaniu zespołu biznesowego.

Jaka jest różnica między uwierzytelnianiem a autoryzacją?#

Uwierzytelnianie odpowiada na pytanie „kim jesteś”. Autoryzacja na „co możesz zrobić”. W realnym SaaS trudno je rozdzielić: użytkownicy, organizacje, role, uprawnienia, sesje, claimsy w tokenach, logi audytowe – wszystko się przeplata. Gdy więc wymieniasz auth, nie możesz patrzeć tylko na stronę logowania.

Dlaczego SSO dla enterprise komplikuje własny auth?#

Bo oznacza podłączenie produktu do systemu tożsamości klienta. Klienci mają różnych IdP, protokoły, pola claimów, certyfikaty, mapowania organizacji. Połączenie pierwszego nie znaczy, że kolejne są „kopiuj-wklej”. Najczęściej to praca ręczna rozumiana przez jednego inżyniera.

Sami prowadzimy własny auth od lat. Czy możemy się przenieść?#

Tak, choć twarde cięcie rzadko jest dobre. Migruj warstwami: nowe rejestracje, logowania, enterprise SSO wrzucaj najpierw na platformę tożsamości; obecnych użytkowników przenoś przy ich najbliższym logowaniu. Zachowaj drogę powrotną i logi audytowe – żeby migracja nigdy nie była nieodwracalna.