Jak wybrać dostawcę tożsamości: Ramy oceny zespołu inżynierskiego

Większość artykułów porównujących dostawców tożsamości pisana jest przez... dostawców tożsamości. Szok, prawda? Wypisują funkcje, które posiadają, pomijają te, których nie mają, i nazywają to „obiektywnym przewodnikiem”.

To nie jest taki przewodnik.

Przeanalizowaliśmy dziesiątki prawdziwych próśb o ocenę IdP — faktyczne arkusze kalkulacyjne i dokumenty RFP, które zespoły zakupowe wysyłają do dostawców. Wzorce są jasne: zespoły inżynierskie nie doceniają najważniejszych kryteriów i przeceniają te najmniej istotne.

Efekt? Zespoły wybierają IdP na podstawie dema, po sześciu miesiącach odkrywają, że migracja to koszmar i zaczynają proces od nowa.

Oto ramy oceny, które chcielibyśmy dostać, zanim zaczęliśmy własny wybór. Zbudowano je dla zespołów inżynierskich w firmach B2B SaaS — tych, które budują produkty, a nie tych kupujących SSO dla pracowników.

Szybka odpowiedź: Co decyduje o wyborze IdP#

Jeśli czytasz pobieżnie, oto skrót:

1. Głębia protokołów ważniejsza niż liczba funkcji. Samo „wsparcie OAuth2” nic nie znaczy. Jakie typy grantów? Czy można dostosować sekcje claims w tokenach? Czy możesz sam zostać dostawcą OIDC?
2. Możliwość migracji to najbardziej niedoceniane kryterium. Jeśli nie możesz przenieść istniejących użytkowników bez wymuszenia resetu hasła, IdP jest bezużyteczny, nieważne jak dobrze wygląda reszta.
3. Wielotenantowość musi być natywna, a nie doklejona na siłę. Jeśli modele organizacji i konfiguracje per-klient wymagają obejść, będziesz wiecznie walczyć z systemem.
4. Gotowość na AI to nie planowanie przyszłości — to wymóg na kolejne 12 miesięcy. Wymiana tokenów, tożsamość agentów, delegowane zakresy. Jeśli IdP tego nie obsługuje, wrócisz do oceny za rok.

Poniżej znajdziesz szczegółowy przewodnik po każdym wymiarze oceny, wraz z pytaniami i czerwonymi flagami.

Dla kogo jest ten przewodnik (a dla kogo nie)#

Ten przewodnik jest dla ciebie, jeśli:

• Jesteś CTO, wiceprezesem ds. inżynierii lub architektem platformy w firmie B2B SaaS liczącej 50-300 osób
• Masz ponad 100 000 użytkowników i nie możesz pozwolić sobie na burzliwą migrację
• Kierujesz się do klientów enterprise, którzy potrzebują SSO, modeli organizacyjnych i logów audytowych
• Musisz napisać raport techniczny i chcesz ram oceny niepochodzących od dostawcy

To NIE jest dla ciebie, jeśli:

• Szukasz IAM dla pracowników (SSO pracownicze do narzędzi wewnętrznych) — to inny wybór zakupowy
• Prowadzisz startup z 500 użytkownikami i nie masz jeszcze klientów enterprise — wybierz rozwiązanie z najlepszym SDK i ruszaj dalej
• Potrzebujesz weryfikacji tożsamości (KYC/KYB) — to osobna kategoria rozwiązań

Wymiar 1: Możliwości protokołów — nie tylko „obsługa OAuth2”#

Każdy IdP na rynku powie, że obsługuje OAuth2 i OIDC. To podstawa. Rzecz w szczegółach.

Granty: Które, i dlaczego to ważne#

Konieczne:

• Authorization Code + PKCE — Jedyny tryb, jaki powinieneś używać dla aplikacji browserowych lub mobilnych. Jeśli dostawca wciąż poleca Implicit flow, odejdź. PKCE to wymóg bezpieczeństwa.
• Client Credentials — Do komunikacji usługa-usługa. Backend musi się uwierzytelniać bez udziału użytkownika.
• Refresh Token — Brzmi banalnie, ale implementacje są bardzo różne. Czy możesz konfigurować rotację? Czas ważności? Wycofać jeden token bez zamykania całej sesji?

Coraz bardziej krytyczne:

• Token Exchange (RFC 8693) — Grant umożliwiający autoryzację agentów AI, przepływy impersonacji i delegowania. Jeśli dziś go nie ma, zapytaj o plan wdrożenia. Jeśli takiego nie ma — czerwona flaga.

Możliwość bycia dostawcą OIDC#

Pytanie, którego większość zespołów nie zadaje: Czy możesz używać tego IdP jako PROVIDERA OIDC, a nie tylko konsumenta?

Dlaczego to ważne: Gdy twój SaaS rośnie, partnerzy i klienci mogą chcieć logować się do własnych narzędzi przez twój system tożsamości. Musisz wydawać tokeny, zarządzać zgodami, obsługiwać rejestrację aplikacji zewnętrznych. Jeśli IdP pozwala tylko konsumować zewnętrzne IdP, ale sam nim być nie może — napotkasz ścianę przy federacji z zewnątrz.

Zapytaj:

• Czy IdP udostępnia endpoint OpenID Discovery, który możesz white-labelować?
• Czy możesz rejestrować aplikacje pierwszo- i trzecio-partnerskie z różnym poziomem zaufania?
• Czy aplikacje first-party mogą omijać ekran zgody, a third-party muszą go przechodzić?

Dostosowanie JWT#

Token to kontrakt między IdP a twoimi usługami. Jeśli nie możesz go dostosować, wszystkie usługi downstream muszą odpalać kolejne API, żeby ustalić uprawnienia użytkownika.

Zapytaj:

• Czy możesz dodawać własne claims do access/ID tokenów?
• Czy możesz osadzić kontekst organizacyjny (wybrany tenant) w tokenie?
• Czy możesz definiować własne scope’y odpowiadające modelowi uprawnień aplikacji?
• Claims są wyliczane przy wydaniu czy mogą być dynamicznie przez webhook/skrypt?

Token niosący { "org_id": "org_123", "role": "admin", "auth_level": 2 } pozwala twojemu middleware API decydować o uprawnieniach jednym sprawdzeniem. Token niosący tylko { "sub": "user_456" } wymusza dodatkowe zapytania do IdP czy bazy. Przy skali — różnica to 2ms vs 200ms na żądanie.

Wymiar 2: Przepływy uwierzytelniania — detale, które pogrążają wdrożenia#

Każdy IdP obsługuje logowanie email/hasło i przez social. Brawo — zawęziłeś pole do... prawie wszystkich.

Różnicują drobiazgi, o których nie mówi demo.

Przebieg rejestracji#

• Auto-login po rejestracji: Czy po rejestracji użytkownik jest automatycznie logowany, czy widzi ponownie stronę logowania? Wymuszanie powtórnego logowania zaraz po rejestracji zabija konwersję. Zaskakująco dużo IdP robi to źle.
• Własne pola rejestracyjne: Czy możesz zbierać rolę, nazwę firmy lub use case już przy rejestracji? Czy musisz mieć potem kolejny flow onboardingowy?
• Profilowanie progresywne: Czy możesz zbierać dane na raty podczas różnych sesji, zamiast wymagać wszystkiego naraz?

Przebieg logowania#

• Wsparcie login_hint: Czy kliknięcie w link z mailingu wypełni automatycznie adres email? Banalne? To różnica między 40% a 60% konwersji z kampanii mailingowej.
• Polityki uwierzytelniania per-organizacja: Czy Org A może wymagać SAML SSO, a Org B zwykłego email/hasło? Czy możesz wymusić MFA tylko dla tenantów enterprise? Jeśli każdy taki przypadek to zmiana kodu, a nie konfiguracji — spalisz cykle inżynierskie przy każdym onboardingu enterprise.
• Dostosowanie brandingu: Czy możesz zmieniać logowanie per tenant? Nie tylko logo i kolory — pełna kontrola nad CSS, własne domeny, white-labelowane maile. „Hosted UI vs. własny UI” to ma być twój wybór, nie ograniczenie platformy.

Czego nie ma na większości checklist#

• Ciche uwierzytelnienie: Jeśli token wygasa, czy aplikacja może go odświeżyć w tle bez przekierowania użytkownika? A jeśli refresh token też wygasł — czy jest fallback (np. przedłużająca sesja przez iframe)?
• Łączenie kont: Użytkownik rejestruje się przez Google, za chwilę loguje przez email. To dwa konta, czy jedno? Jak IdP obsługuje merge tożsamości? Jeśli źle — do końca życia będziesz mieć „duchy” kont w systemie.
• Opcje bezhasłowe: Magic linki, passkeye, WebAuthn. Nie każdy potrzebuje tego dziś, ale twoi klienci enterprise poproszą o to w ciągu 6 miesięcy.

Wymiar 3: Zarządzanie sesją i tokenami — głęboka woda#

Na tym rozjeżdżają się demonstracje i produkcyjne wdrożenia. Zarządzanie sesją i tokenami jest nudne do momentu, gdy padnie — a wtedy wszyscy są wylogowani naraz.

Bezpieczeństwo cookies#

Zero atrakcji. Zero tolerancji na błędy.

• HttpOnly, Secure, SameSite: Wszystkie trzy atrybuty MUSZĄ być ustawione poprawnie. IdP bez HttpOnly na cookies nie jest gotowy na produkcję.
• Wsparcie subdomen: Jeśli aplikacja działa na app.twojprodukt.com, a API na api.twojprodukt.com, czy sesje obejmują subdomeny? Jak?
• Wycofanie third-party cookies: Chrome je usuwa. Jak IdP obsługuje auth flow cross-origin bez tych cookies? Odpowiedź „pracujemy nad tym” nie wystarcza.

„Zapamiętaj mnie” i sesje trwałe#

Użytkownicy chcą być zalogowani tygodniami, nie minutami. 180 dni sesji vs. 30 minut — zupełnie inne ryzyka.

Zapytaj:

• Czy czas trwania sesji konfigurowalny niezależnie od czasu życia tokena?
• Czy jest opcja „zapamiętaj mnie” wydłużająca sesję przy krótszych tokenach?
• Czy możesz wymuszać ponowne uwierzytelnienie do wrażliwych operacji bez rozłączania sesji?

Bezpieczeństwo refresh tokenów#

• Rotacja tokenów: Czy refresh token zmienia się przy każdym użyciu? (Powinien.)
• Szyfrowane przechowywanie: Czy są szyfrowane w spoczynku?
• Granulacja cofnięcia: Czy możesz unieważnić tylko jedną sesję urządzenia bez wylogowania wszędzie?
• Konfigurowalna ważność: Każda aplikacja może potrzebować innych timeoutów refresh tokena. Czy da się to ustawić per app, czy tylko globalnie?

Wymiar 4: Model autoryzacji — coś więcej niż RBAC#

RBAC to minimum. Jeśli IdP go nie ma, nie oceniamy dalej. Ale w B2B SaaS to za mało.

Uprawnienia w ramach organizacji#

Użytkownicy należą do wielu organizacji. Ich uprawnienia w każdej organizacji różnią się od uprawnień platformowych.

Użytkownik może być adminem w Org A, a widzem w Org B. Ten sam login, różne role w różnych miejscach. Jeśli IdP nie modeluje tego natywnie — zbudujesz równoległy system uprawnień, a więc dwa źródła prawdy.

Pytania:

• Czy możesz definiować role na poziomie organizacji, a nie tylko użytkownika?
• Czy jeden użytkownik może mieć różne role w różnych organizacjach?
• Czy kontekst bieżącej organizacji jest zaszyty w tokenie, żeby API wiedziało, w czyim imieniu działa użytkownik?

Wielopoziomowa autoryzacja (auth_level)#

Dla finansów, branży medycznej czy tam, gdzie operacje niosą większe ryzyko: nie każda uwierzytelniona sesja jest równa.

Podgląd dashboardu? Wystarczy cookie. Przelew? Musisz wymusić świeże MFA, nawet jeśli użytkownik jest już zalogowany.

To tzw. „podniesienie poziomu uwierzytelnienia” — auth_level jako first-class citizen w tokenach.

Zapytaj:

• Czy token może mieć claim auth_level, który backend sprawdzi?
• Czy możesz wywołać podniesienie poziomu z aplikacji bez pełnego relogowania?
• Czy auth_level ma własny czas życia niezależny od ogólnej sesji?

Brak natywnego wsparcia = konieczność budowy własnego rozwiązania — czyli dokładnie tej logiki, którą IdP miał zaoszczędzić.

Autoryzacja „na tokenie”#

Ideał: twoje middleware API czyta token, widzi organizację, rolę, auth_level i podejmuje decyzję bez API IdP.

Rzeczywistość: token mówi kto, ale musisz robić dodatkowe wywołania, by uzyskać uprawnienia.

Każde takie wywołanie to opóźnienie, zależność, ryzyko awarii. Przy 1000 żądań na sekundę nie chcesz mieć takiego „skoku” sieciowego przy sprawdzeniu uprawnienia.

Wymiar 5: Migracja — kryterium decydujące o wszystkim#

Statystyka, o której się nie mówi: większość ocen IdP kończy się nie dlatego, że IdP nie jest wystarczająco dobry, ale dlatego, że zespół nie wie, jak przenieść użytkowników.

Mając 100K+ użytkowników, migracja to nie „fajny dodatek” — to CAŁOŚĆ projektu.

Trzy strategie migracji (i które musi obsłużyć IdP)#

1. Import masowy z istniejącymi hashami haseł

Użytkownicy mają hasła zhashowane bcrypt, argon2, czymkolwiek. Czy IdP może zaimportować bezpośrednio te hashe i uwierzytelniać po nich?

Tak — użytkownik loguje się dotychczasowym hasłem, różnicy nie ma. Scenariusz idealny.

Nie — wszyscy dostają maila o resecie hasła. Utracisz 30–50% userów podczas migracji. To nie teoria, tak jest w praktyce.

2. Migracja progresywna (leniwa)

Migracja pojedyncza per logowanie: pierwsze logowanie idzie do starego systemu, jeśli hasło poprawne, użytkownik trafia do nowego IdP. Następne logowania idą już tylko do nowego IdP.

To najbezpieczniejsze dla dużych baz użytkowników, ale wymaga od IdP:

• Hook do własnego uwierzytelniania przez legacy
• Możliwości on-the-fly tworzenia użytkownika przy logowaniu
• Śledzenia, kto już został przeniesiony, a kto nie

3. Dual-write (równoległa praca systemów)

Przez jakiś czas obydwa systemy są aktywne. Zapisy do obu, odczyty stopniowo przesuwane na nowy. Daje drogę powrotną, ale dodaje złożoność.

Czerwone flagi migracji#

• „Obsługujemy import CSV” — To import profili, nie haseł. Nadal jesteś skazany na reset haseł.
• „Mamy poradnik migracji” — Czytaj uważnie. Jeśli jest tam „użytkownicy będą musieli ustawić nowe hasło” — to scenariusz migracji z utratą 30–50% userów.
• Brak informacji o hashach — Jeśli vendor nie mówi nic o migracji hashy, nie obsługiwał jeszcze klientów twojej skali.

Pytania do zadania#

• Jakie algorytmy hashów haseł obsługujecie do importu? (bcrypt, argon2, scrypt, PBKDF2, własny?)
• Czy możemy zrobić migrację progresywną (użytkownik przenoszony przy pierwszym logowaniu)?
• Czy możemy śledzić postęp migracji — ilu procent użytkowników już przeniesiono?
• Jaka jest strategia rollbacku jeśli migracja nie pójdzie dobrze?
• Czy możemy utrzymać ciągłość sesji — tak żeby użytkownicy nie zostali wylogowani w trakcie?

Jeśli dostawca nie odpowiada konkretnie na te pytania — nie robił tego wcześniej. Przechodzimy dalej.

Wymiar 6: Wielotenantowość — natywna vs. dosztukowana#

B2B SaaS = wielotenantowość. Twoi klienci to organizacje z wieloma użytkownikami, rolami i politykami. IdP musi rozumieć to natywnie.

Co znaczy „wielotenantowość natywna”#

• Organizacja jako bycie tworem „first-class entity”: To nie pole custom w profilu użytkownika, lecz osobny model danych z ID, konfiguracją i listą członków.
• Polityki uwierzytelniania na organizację: Org A korzysta z SAML SSO; Org B z email/hasło i MFA; Org C z Google Workspace. Wszystko przez UI/API, nie przez kod.
• Zaproszenia i zarządzanie członkostwem: Admin każdej organizacji może zapraszać ludzi, przypisywać role, kasować członków. Flow zaproszeń, potwierdzenie adresu, role — zapewnia IdP.
• Tokeny kontekstowe organizacyjnie: Użytkownik działa w kontekście organizacji — token niesie info, która to organizacja. API wie, które dane zwrócić.

Obejście „custom metadata”#

Niektóre IdP nie mają modelu organizacji, polecają trzymać user.app_metadata.org_id = "123" jako się udaje.

Szybko klapa:

• Użytkownik w wielu organizacjach = tablice do zarządzania w metadanych
• Zero natywnego flow zaproszeń/członkostwa
• Brak polityk auth per organizacja
• Brak tokenów z kontekstem organizacji — trzeba domyślać się z innych sygnałów
• Logi audytu nie rozumieją czym są organizacje

Jeśli vendor mówi „można modelować organizacje metadanymi” — to jak trzymać relacyjną bazę w kolumnie JSON. Działa do czasu.

Pytania do zadania#

• Czy model organizacji jest natywny, czy dopięty do user metadata?
• Czy użytkownicy mogą jednocześnie należeć do wielu organizacji?
• Czy możemy konfigurować różne wymagania uwierzytelniania dla każdej organizacji?
• Czy role/uprawnienia organizacyjne są natywnie obsługiwane?
• Czy admini organizacji zarządzają członkami przez self-service UI?
• Czy token niesie info o organizacji?

Wymiar 7: Gotowość na AI — kryterium, którego nikt jeszcze nie pyta#

12 miesięcy temu „uwierzytelnianie agentów AI” nie istniało na checklistach. Dziś, jeśli budujesz AI (copilotów, agentów, workflow AI), IdP musi obsłużyć nowy byt: agenta.

Czemu agenci łamią klasyczny model#

Tradycyjny auth: użytkownik i aplikacja (OAuth2 do tego powstał).

Agent AI — trzeci aktor: nie-człowiek działający w imieniu usera, z ograniczonymi uprawnieniami, własnym audytem.

• Agent to nie user — nie ma hasła/seryjnej sesji
• Agent to nie typowy M2M — działa w imieniu konkretnego usera
• Agent potrzebuje scope’ów na czas — nie pełnych uprawnień usera

Co musi obsłużyć IdP#

Token Exchange (RFC 8693): Agent przedstawia swój credential plus autoryzację usera i dostaje token ze scope’em: kto (user), co (agent), zakres (scope), do kiedy (expires).

Agent jako typ klienta: Agent to pełnoprawny OAuth2 client z własnym client_id, nie improvizowany klucz API czy token usera.

Delegowane scope’y: User nadaje agentowi konkretne uprawnienia — odczyt bez zapisu, dostęp do wybranych zasobów.

Wyraźny ślad audytowy: Logi muszą rozróżniać „user zrobił X” vs. „agent zrobił X w imieniu usera”. Brak rozdziału = fail na SOC2 gdy audytor spyta „kto wykonał akcję?”

Kompatybilność MCP (Model Context Protocol)#

MCP staje się standardem dla integracji agentów AI. Jeśli IdP obsługuje OAuth pod MCP, agenci mogą się autoryzować przez protokół, nie przez klucze API.

Pytania do zadania#

• Czy obsługiwany jest OAuth2 Token Exchange?
• Czy agenci mogą być osobnym typem klienta?
• Czy tokeny niosą info o delegacji (kto autoryzował agenta, jaki scope)?
• Czy logi rozróżniają akcje agenta od ludzkich?
• Czy jest integracja MCP/OAuth dla auth agentów do narzędzi?

Brak tych tematów = IdP budowany pod 2020, ty planujesz na 2026.

Wymiar 8: Wymagania niefunkcjonalne — rzeczy, przez które nie śpisz#

Funkcje sprzedają. O operacjach decyduje przedłużenie kontraktu.

Wydajność#

• Przepustowość auth: Czy system obsłuży 100+ auth requestów/sekundę w piku? A 1000+?
• Latencja walidacji tokenów: Aplikacje powinny same walidować JWT (sub-ms). Jeśli IdP wymaga introspekcji, jakie jest P99?
• Sufit skalowania: Jakie MAU są obsługiwane? Czy są referencje na twojej skali?

Zgodność#

• SOC2 Type II: Nie Type I — Type II to audyt ciągły, Type I to punkt w czasie. Jeśli jest tylko Type I, zapytaj kiedy będzie II.
• Logi audytu: Każdy event uwierzytelniania, zmiana uprawnień, akcja admina. Możesz eksportować do SIEM? Czy logi są niezmienialne?
• Lokalizacja danych: Czy wskazujesz region przechowywania danych? Dla UE wymóg bezwzględny.

Niezawodność#

• SLA dostępności: 99,9% daje 8,7 godzin braku działania rocznie. 99,99% — 52 minuty. Dla auth — różnica kolosalna.
• Failover: Co podczas awarii dostawcy? Czy jest fallback? Serwery na wielu regionach?
• Historia incydentów: Przejrzyj archiwum statuspage — nie obietnice, tylko rzeczywiste alerty.

Przenośność danych#

• Eksport użytkowników: Czy wyeksportujesz wszystkich userów, metadane, członkostwa, role? W jakim formacie?
• Standardy: Czy używają protokołów OIDC/SCIM? Ułatwia to przejście do innego dostawcy, gdyby co.
• Brak sygnałów lock-in: Własne API, custom protokoły, niestandardowe formaty tokenów — to lock-in. Im bardziej niestandardowe powiązania, tym trudniej odejść.

Matryca oceny: praktyczne kryteria priorytetów#

Po analizie wszystkich wymiarów potrzebujesz sposobu porównania. Oto najważniejszy podział:

P1 — Deal-breakery (obowiązkowe, dyskwalifikują przy niepowodzeniu)#

P2 — Silnie pożądane (wymagają dużych nakładów, jeśli brak)#

P3 — Ważne (zaplanować w 12 miesięcy)#

P4 — Mile widziane (nie blokują decyzji)#

Jak używać: Zacznij od P1. Jeśli vendor nie spełnia jakiegokolwiek z P1 — koniec. Następnie oceniaj P2/P3. Wygrywa ten z najlepszym sumarycznym wynikiem P2+P3.

Typowe błędy podczas oceny#

Widujemy te same błędy wielokrotnie. Oto jak uniknąć:

Błąd 1: Ocena po cechach, nie architekturze#

Tabela funkcji pokazuje co jest, nie jak zbudowane. IdP może „mieć organizacje” przez pole org_id w user metadata. Zaznaczysz ptaszek, a w produkcji odkryjesz prawdziwe koszty.

Jak naprawić: Przy każdej funkcjonalności pytaj „jak wdrożone?”, nie tylko „czy jest?”

Błąd 2: Ignorowanie migracji do końca#

Wybierasz IdP, zaczynasz wdrożenie, potem okazuje się, że migracja userów bez resetu haseł niemożliwa. Masz do wyboru: fatalną migrację albo od nowa cały proces.

Jak naprawić: Kryterium migracji filtruj na starcie, NIE na końcu.

Błąd 3: Nadmierna wiara w demo#

Demo każdego vendora jest perfekcyjne. Prezentuje ścieżkę bez błędów, czyściutką bazę, zero edge case’ów. Produkcja: połączone konta, dziwne znaki w danych userów, sesje-widma.

Jak naprawić: Poproś o PoC na TWOJEJ rzeczywistej bazie. Załaduj 1000 realnych userów i przetestuj rzeczywisty flow uwierzytelniania.

Błąd 4: Brak odpowiednich osób w ocenie#

Tylko platforma? Wybiorą najczystsze inżyniersko. Tylko produkt? Najłatwiejsze do integracji. Tylko bezpieczeństwo? Najwięcej checkboxów.

Jak naprawić: W ocenie powinni uczestniczyć inżynierowie od platformy, ludzie od produktu i bezpieczeństwa. Każdy dba o inne kryteria P1/P2.

Błąd 5: Zapominanie, że kiedyś trzeba będzie odejść#

Lock-in jest realny. Własne SDK, customowe API, niestandardowe tokeny — utrudniają ucieczkę później.

Jak naprawić: Preferuj standardowe protokoły (OIDC, OAuth2, SCIM). Twój przyszły ja ci podziękuje.

FAQ#

Ile trwa typowa ocena IdP?#

Solidna ocena, łącznie z PoC, to 4-8 tygodni. Pośpiech kończy się błędami (np. migracyjnym). Załóż 2 tygodnie na określenie wymagań, 2-3 tyg. na ocenę vendorów + PoC, 1-2 tyg. na uzgadnianie decyzji.

Czy lepiej budować auth samodzielnie?#

To zależy. Mniej niż 10k użytkowników i brak enterprise — własna biblioteka wystarczy. Ale przy SSO, wielotenantowości, MFA i compliance — koszt utrzymania własnego auth przekracza koszt IdP. Typowo 2–3 etaty rocznie poświęcone na własny auth = 300–500 tys. USD rocznie kosztu alternatywnego.

Różnica CIAM a workforce IAM?#

Customer Identity and Access Management (CIAM) — flow użytkowników twojego produktu: rejestracja, logowanie, profile. Workforce IAM — dostęp pracowników do narzędzi (Okta do Slacka, Google Workspace itd.). Różne decyzje zakupowe, inne priorytety. Ten przewodnik dotyczy CIAM.

Otwarte źródło vs. proprietary — jak ważne?#

Open-source daje transparentność (sprawdzisz kod), portowalność (możesz wdrożyć samodzielnie) i wsparcie społeczności. Proprietary — często ładniejszy UI i SaaS. Kluczowe pytanie: nie „open vs. closed”, tylko „czy mogę łatwo odejść?”. Open-source zwykle to ułatwia, bo publiczne modele i API.

Kiedy auth agentów AI ma być P1 zamiast P3?#

Jeśli już budujesz AI korzystające z danych userów (copiloty, workflow itd.), daj P1. Przy AI na roadmapie 6-12 mies., zostaw w P3 ale wysoko waż. AI poza radar — P4, wróć za pół roku.

Jak porównywać ceny vendorów o różnych modelach?#

Większość IdP liczy MAU. Ale definicje „MAU” się różnią — niektóre każda autoryzacja, niektóre unikalny user, niektóre rozdzielają M2M tokeny. Poproś o wycenę pod własny przypadek: X userów, Y organizacji, Z połączeń M2M, twoje parametry auth volume. Porównuj koszt CAŁOŚCIOWY, nie jednostkowy.

Na koniec#

Wybór IdP to decyzja o infrastrukturze, a nie o funkcjach. Oddajesz mu pierwszą interakcję każdego użytkownika z produktem, każdy check uprawnień API oraz każdy wpis w logach dla compliance.

Powyższe ramy skupiają się na tym, co naprawdę istotne — nie na marketingowych hasłach. Użyj ich, by szybko filtrować kandydatów (najpierw P1), potem głębiej oceniać (P2/P3 i PoC), wreszcie podejmuj decyzję na lata, nie na miesiące.

Ci, którzy robią to dobrze, mają ze sobą jedno: traktują zarządzanie tożsamością jak infrastrukturę, nie jak funkcję do odhaczenia na road mapie.