Możesz zbudować własny system uwierzytelniania w jeden dzień. W tym tkwi pułapka.
Dziesiątki zespołów B2B opowiedziały nam tę samą historię. Zaczyna się od prostego formularza logowania. Potem przez lata obsługuje prawdziwy ruch i po cichu staje się infrastrukturą tożsamości, na której opiera się cały Twój produkt.
Wyglądało jak jedna funkcja. Zostawiło za sobą cały model tożsamości.
Każdy samodzielny system uwierzytelniania zaczyna się od kilku linijek. Problemy pojawiają się po wdrożeniu, gdy każda z drobnych decyzji po cichu utrwala się w modelu, na którym opiera się Twój produkt.
Dzień pierwszy: czterdzieści linijek kodu
Email, hasło, haszuj, zapisz, porównaj przy logowaniu. Czysto i gotowe.
Dzień dwusetny: cichy model tożsamości
Kto liczy się jako użytkownik. Do której organizacji należy. Która sesja jest wciąż zaufana. Jak cofa się dostęp.
Rok piąty: fundament, którego nie można ruszyć
Zamiana strony logowania na papierze znaczyła przebudowę fundamentów tożsamości w kodzie.
Własny system uwierzytelniania działa dobrze — dopóki biznes się nie zmienia
Lata loguje użytkowników bez incydentów. Potem nagła zmiana biznesowa zamienia „wystarczy” na „przeszkodę” z dnia na dzień. Te trzy wyzwania pojawiają się niemal w każdym produkcie, który się rozwija.
Klienci korporacyjni zaczynają pytać o SSO
Pierwszy duży kontrakt i dział zakupów chce SSO przez własne Entra lub Google Workspace. Potem i SAML, i OIDC, bo następny klient używa czegoś innego. Konfiguracja tożsamości każdego klienta jest inna, a prawie żadna praca się nie powtarza.
- Różne protokoły, mapowania pól i rotacje certyfikatów dla każdego klienta
- SSO nie buduje się raz. Budujesz je dla każdego klienta firmowego od nowa
- Po cichu staje się ręczną robotą, którą rozumie tylko jeden inżynier
Tożsamości, które były rozproszone, muszą stać się jedną
Podzielone według organizacji, podzielone według produktów, często przejęte przy okazji akwizycji. „Unifikacja tożsamości” brzmi jak funkcja; w kodzie oznacza przedefiniowanie tego, co oznacza jeden użytkownik i jedna organizacja.
- Czy jeden email może należeć do kilku organizacji? Jak migrować historyczne nazwy użytkowników?
- Dziewięć produktów po akwizycjach to dziewięć stosów uwierzytelniania działających równolegle
- Odwołaj dostęp od jednego użytkownika we wszystkich naraz i zrób z tego jeden audyt
Agenci AI i CLI zaczynają działać w imieniu użytkownika
To już nie tylko ludzie w przeglądarce. Agenci, serwery MCP i linie komend podszywają się pod użytkownika. A Twój system uwierzytelniania zna tylko logowanie osoby na stronie.
- Komu wydawany jest token, z jakim zakresem i dla jakiej grupy odbiorców?
- Przyznaj dostęp tylko jednemu narzędziu lub zakresowi danych, a potem cofnij go
- Dostęp MCP oraz CLI opiera się na OAuth, nie na formularzu logowania
Prawdziwy koszt to nie budowa. To noszenie tego przez lata.
Pierwsza wersja jest tania: kilku inżynierów, kilka tygodni, gotowe. Potem co roku dokładasz czas, który powinien być przeznaczony na Twój właściwy produkt.
Rachunek się nie zmienia, jedynie sposób płatności
Nigdy nie dostajesz faktury z tytułem „uwierzytelnianie”.
Cały ciężar spoczywa na jednej lub dwóch osobach
Kluczowa wiedza tkwi w czyjejś głowie, nie w dokumentacji.
Gdzie chcesz swoich inżynierów?
Nikt nie płaci więcej, bo napisałeś własny serwer OAuth.
Jeśli nie budujesz sam, jak wybierasz?
Dojrzałe systemy uwierzytelniania mają już potrzebne funkcje: SSO, MFA, organizacje, jedno logowanie, dostęp dla agentów. Prawdziwa różnica to możliwość odejścia. Nie zamieniaj własnych kilku tysięcy linijek na system, z którego potem nie wyjdziesz.
Standardowe protokoły, nie wymyślony stack
Drzwi, przez które możesz wyjść
Rozliczenia, które nie śledzą tabeli użytkowników
Twoje dane nigdy nie są zablokowane
Uwierzytelnianie to prawdopodobnie nie Twój core biznes. Tak je traktuj.
Logto jest open source, może być hostowane samodzielnie i oferowane jako zarządzana chmura. Logowanie, MFA, SSO i RBAC działają od razu dzięki standardowemu OIDC. Rozliczanie dotyczy tokenów, a kiedy chcesz odejść, drzwi są otwarte.