WolfieAuth vs rynek IAM

Auth0, Okta, WorkOS, Stytch, FrontEgg, AWS IAM Identity Center, better-auth — co robią, czego nie robią, i gdzie tryb reseller WolfieAuth faktycznie się różni.

WolfieAuth vs rynek IAM

Po co ta strona istnieje: większość artykułów typu “porównanie IAM” to sponsorowany content udający analizę. Ten dokument to uczciwe notatki inżynierskie z budowy produktu w tej samej kategorii. Gdzie tabela mówi “yes” / “no”, to na podstawie czytania własnej dokumentacji vendora (linkowane przy każdej sekcji). Tam gdzie nie byłem pewny, sekcja mówi to wprost.

TL;DR — matryca

Kolumny które mają znaczenie dla B2B-z-B2B SaaS:

Legenda: ✅ wdrożone i udokumentowane · ⚠️ częściowe / wymaga workaroundów · 💰 gated do enterprise tier · ❌ niedostępne

Auth0 — incumbent który nigdy nie wypuścił B2B-z-B2B

Auth0 dodał feature Organizations w 2021 i tam ewolucja stanęła. Każda organizacja to flat-tenant; możesz mieć usera w wielu orgach, ale organizacje nie mogą zawierać innych organizacji. Community pyta o parent-child od co najmniej 2018 i oficjalna odpowiedź to “użyj metadata + własnej logiki.”

Co dostajesz:

• Organization metadata, branded login per org, role assignments scoped per-org.
• Connections (SAML/OIDC inbound) per-org — przydatne dla “każdy klient ma własny SAML IdP.”

Czego nie dostajesz:

• Żadnego konceptu “ta org jest właścicielem tamtych orgów.”
• Żadnego billing prymitywu który rozumie resellera sprzedającego seat-packi swoim sub-tenantom.
• Żadnego cascade-suspend ani branding-inheritance idącego po drzewie orgów.

Cennik dla relevantnych tierów B2B Essentials / Professional zaczyna się w wysokich trzech cyfrach USD/mc i skaluje per Monthly Active Users. Reseller-z-resellera musi być zbudowany w całości w twojej apce.

Auth0 Organizations docs

Okta — ma hierarchię, ale jako osobny płatny SKU

Okta ma “Org Creator API” (zmienione w niektórych materiałach na Multi-Org Deployment), zaprojektowany explicite dla ISV-ów którzy chcą stawiać Okta org-i per klient. To nie jest część zwykłych Workforce / Customer Identity SKU — osobno negocjowany add-on, cennika nie ma na stronie. Public sales decks opisują to jako “for partners, MSPs, and ISVs.”

Co dostajesz:

• API do programowego tworzenia child Okta orgów; każdy to prawdziwy, izolowany tenant.
• Tooling do push-owania userów / apek z “hub” orga do childów.
• Każdy child dostaje własną subdomenę na okta.com (np. <klient>.okta.com); custom domeny wymagają dodatkowego licensingu.

Czego nie dostajesz (out of the box):

• Żadnego pre-built reseller billing modelu. Seat-pack accounting to twój problem.
• Natywnego UI w Okta dla admina reseller-tenanta do prowizjonowania jego end-customerów bez admin API calli.

To jest najbliżej co mainstream IAM podchodzi do prawdziwego multi-tier, ale gating-by-SKU + brak turn-key reseller billing layer-a oznaczają że większość ISV-ów buduje custom rozwiązanie na wierzchu.

Okta Org Creator API overview · Okta Multi-Org pricing requires direct contact

WorkOS — hierarchia przez FGA, brak first-class konceptu reseller

WorkOS pozycjonuje się jako “Stripe dla B2B auth.” Ich Organizations API jest solidne dla flat multi-tenancy; dla hierarchii wskazują na FGA (Fine-Grained Authorization) — Zanzibar-style relationship engine.

Co możesz zbudować z FGA:

• Definiujesz typy organization, workspace, user i relacje parent, member.
• Wyrażasz “user X ma access do wszystkich workspace-ów pod org Y przez inheritance.”
• Query “co ten user widzi” z permission-inheritance traversal.

Co nadal twoje:

• Modelowanie “ta org jest resellerem acme-cloud-product” — nie ma opinionated prymitywu na to; kodujesz to w FGA tuples + reseller seat-limity w swoim DB.
• Splity billingowe, cascade-suspend, branding cascade, custom domeny per-reseller — wszystko greenfield.

Siłą WorkOS jest dev ergonomics (czyste API, hojny free tier na connections), a FGA jest faktycznie użyteczne do permission inheritance. Ale “robimy reseller mode” jest dokładniej oddane jako “nasze prymitywy nie wchodzą w drogę kiedy budujesz reseller mode.”

WorkOS Organizations · WorkOS FGA

Stytch — tylko flat orgi, brak nested hierarchii

Stytch B2B ma Organizations + Members. Brak natywnej parent-child organization hierarchy, brak konstrukcji MSP/reseller, brak konceptu “jedna org widzi dane drugiej przez inheritance.” Optymalizują pod flat-tenant SaaS i tyle.

Jeśli budujesz single-tier B2B SaaS, Stytch jest świetny — czyste SDK-i, dobry passwordless, cennik skaluje sensownie. Z chwilą gdy potrzebujesz “agencja ma 50 sub-tenantów i bills je per-seat,” budujesz to na własnym backendzie.

Stytch B2B Organizations

FrontEgg — najbliższy konkurent na B2B-z-B2B

To jest jedyny produkt na rynku który explicite marketuje się do MSP i resellerów. FrontEgg ma wdrożone Sub-Accounts (parent-child tenant hierarchy), admin UI z Table + Graph view drzewa, i dedykowane API do tworzenia sub-tenantów w imieniu rodzica.

Co FrontEgg robi dobrze:

• Sub-account creation API z konceptem “delegation” — admin rodzica może zarządzać child tenantami.
• Per-tenant branding dziedziczone od rodzica, override-owalne.
• Zintegrowany entitlements layer który płynie przez sub-tenanty.

O czym docsy FrontEgg-a są ciszej:

• Per-reseller seat-pack billing prymitywy (ich entitlement engine ogarnia flat per-tenant; multi-tier seat allocation nie jest wymieniony).
• Cascade-suspend przez sub-account tree.
• Reseller-specific custom domeny w odróżnieniu od per-app custom domain.

Cennik per-tenant + szybkie wchodzenie wyżej po starter SKU. Dla MSP plays, contact-sales territory.

FrontEgg to platforma do której WolfieAuth porównałbyś head-to-head jeśli kupowałbyś produkt. Edge WolfieAuth-a: tańsze bo to Wolfie-hosted SaaS (brak enterprise sales overhead), opinionated reseller billing wbudowane w ten sam panel co reszta IAM, model cascade-suspend / signup-token explicite jeden klik.

FrontEgg Sub-Accounts

AWS IAM Identity Center — zły shape dla SaaS reseller

IAM = Identity and Access Management — parasolowy termin Amazonu na wszystko wokół “kim jest ten principal i co mu wolno” wewnątrz AWS account-u. Bazowa usługa (po prostu IAM) pozwala tworzyć users, groups, roles i policies rządzące API access do AWS resources. IAM Identity Center (kiedyś AWS SSO) siedzi jedną warstwę wyżej: zamiast zarządzać userami per-AWS-account, daje single sign-on dashboard przez całą AWS Organization (top-level kontener Amazonu który grupuje wiele AWS accountów pod jedną encją rozliczeniową), federuje korporacyjny IdP do wszystkich, i daje userom role-based access do tych accountów do których mają uprawnienia.

AWS IAM Identity Center zbudowany dla AWS-account-internal identity federation. Federujesz korporacyjne IdP-y, przypisujesz userów do AWS account-ów przez permission sets, jeden Identity Center per AWS Organization.

Multi-tier w tym świecie znaczy:

• AWS Organizations → AWS accounts (granica “tenant” w terminach chmurowych).
• MSP odsprzedający AWS klientom prowadzi AWS Control Tower który prowizjonuje osobne AWS account per klient, z osobnym Identity Center setupem.
• Splity billingowe idą przez AWS consolidated billing — usage rolluje się do management accounta, MSP rebillsuje klientów out-of-band.

To działa dla “reseller of cloud infrastructure,” nie dla “reseller of a SaaS app I built on top of WolfieAuth.” Jeśli twój end-product to “use my web app,” IAM Identity Center jest złym narzędziem. AWS by cię skierował do Cognito User Pools + własna multi-tenancy layer — a hierarchy story Cognito jest nie lepsza niż Auth0.

AWS IAM Identity Center · AWS Control Tower

better-auth — piękny TypeScript-native kod, flat orgi

better-auth to młoda, szybko rosnąca biblioteka auth pisana TypeScript-first z first-class passkeys, magic-link i organization plugin. Open-source, self-hostujesz wewnątrz swojej apki (bez osobnego IdP service), jakość kodu naprawdę dobra.

Co robi:

• Email/password, passkey, magic link, OAuth providery (Google/GitHub/etc), 2FA — wszystko czyste.
• Organizations plugin: userzy należą do jednej lub wielu org, role per org.
• Open SDK ecosystem; community pluginy.

Czego nie robi:

• Brak nested organisations. Cytat z oficjalnych docsów: organizations są flat, nie ma plugina parent-child hierarchy.
• Brak reseller / MSP prymitywu jakiegokolwiek rodzaju.
• Brak multi-app SSO (bo żyje wewnątrz twojej apki, nie jako osobny IdP — inny shape całkowicie).

Jeśli twój problem to “chcę auth w mojej jednej Node.js apce i nie chcę osobnego IdP service’u,” better-auth jest świetny i darmowy. Jeśli twój problem to “buduję platformę gdzie 50 klientów odsprzedaje mój produkt swoim klientom,” to zła warstwa do tego.

better-auth docs

Gdzie ląduje WolfieAuth

WolfieAuth jest zbudowany i obsługiwany przez @wolfie jako hostowany SaaS — auth.wolfieguard.com siedzi na infrastrukturze VPS Wolfie, ty go nie self-hostujesz. Opinia produktowa która napędziła pracę nad reseller mode:

Warstwa auth to właściwe miejsce dla hierarchii, branding cascade i seat-pack billingu — bo to jedyna warstwa która widzi każdego tenanta, każdy login, każdą płatność. Pchanie tej pracy do każdej downstream apki oznacza budowanie tego pięć razy.

Co dostajesz na wierzchu OIDC podstaw, czego nikt inny (poza FrontEgg częściowo) nie wdraża:

1. OidcClient.resellerMode = true opt-in per app — twoje istniejące flat-tenant apki zostają flat dopóki nie chcesz hierarchii.
2. Tabela AppReseller z seat-limit, signup-token, custom-domain-per-reseller, fee-bps overrides.
3. 3-poziomowa polityka fee (PlatformConfig → OidcClient override → AppReseller override) — Wolfie bills platform-fee od reseller-subskrypcji, owner-org dostaje seat-pack revenue, reseller fakturuje end-customerów out-of-band.
4. Branding cascade — client.theme ← OidcClient.defaultChildTheme ← AppReseller.childTheme.
5. OIDC claimy — wolfieauth_org_parentId, wolfieauth_reseller_apps[] żeby SDK-i w dowolnym frameworku gateowały UI przez isResellerOf(claims, clientId).
6. Cascade-suspend — flipnij AppReseller.status = "SUSPENDED" i cron flipnie LinkedAccount.suspendedAt dla każdego child-org membera tej apki.

Czego WolfieAuth nie próbuje być:

• Self-hostable jak Keycloak / better-auth. To hostowany SaaS — celowo; trade-off cenowy to że dostajesz aktywnie utrzymywany, KSeF-aware, EU-resident IdP bez konieczności prowadzenia go.
• Workforce-IAM (corporate SSO dla pracowników). Flow jest consumer-IAM i B2B SaaS auth — nie “federuj Okta z mojego AD.”
• First-class FGA / ReBAC engine jak WorkOS FGA. Permissions są role-based z permissions[] claim; dla relationship-based gates twoja apka robi modelowanie.

Uczciwe źródła i status weryfikacji

Każda sekcja powyżej oparta o linkowany doc vendora i source code WolfieAuth w repo wolfieauth. Verified vs inferred:

• Zweryfikowane przez czytanie aktualnych docsów (kwiecień 2026): Auth0 Organizations, WorkOS FGA, Stytch B2B Organizations, FrontEgg Sub-Accounts, better-auth Organization plugin.
• Wywnioskowane z public materials, niedeeptestowane: Okta Multi-Org pricing/SKU specifics (sales-gated, brak public price), AWS Control Tower MSP billing flow at scale.
• Po stronie WolfieAuth: bezpośrednio ze źródła — schema w apps/server/prisma/schema.prisma, fee resolver w apps/server/src/billing/platform-fee-resolver.ts, helpery SDK w packages/wolfieauth-sdk-*.

Jeśli zauważysz factual error w sekcji konkurenta, mailnij Wolfie i strona zostanie poprawiona — vendor positioning zmienia się szybciej niż ten doc, a faktyczna prawda ma większe znaczenie niż retoryczne punkty.

Kiedy wybierać WolfieAuth

WolfieAuth to właściwy wybór gdy chcesz dowieźć SaaS-a albo PaaS-a w light speed i traktować identity, membership, billing, branding i usage metering jako rozwiązane problemy zamiast miesięcy klepania. Konkretnie:

• Budujesz nowy B2B SaaS i chcesz auth/orgi/role/plany/billing day one. Większość “auth providers” kończy na sign-in; resztę — Stripe, plan picker UI, seat-based billing, wystawianie faktur, organisation management, member invites, role assignments, plan gating w kodzie — i tak musisz wpiąć sam. WolfieAuth dostarcza ten cały stack jako jedno drop-in. Z git init do płacącego klienta w dni, nie miesiące.
• Chcesz hostowany IdP ale apki zostają na własnej infrastrukturze. WolfieAuth siedzi pod auth.wolfieguard.com. Twoje apki lecą gdziekolwiek chcesz — twój VPS, twój Kubernetes, twój Vercel, twoje Cloudflare Workers. WolfieAuth ogarnia IdP, ty zachowujesz operational ownership produktu. Best of both worlds w porównaniu do “all-in na Auth0/Okta gdzie vendor widzi każdy product request.”
• Multi-app suite. Jeśli budujesz kilka apek dzielących customer base (CRM, mail, billing, portfolio micro-SaaS), WolfieAuth znaczy JEDNA tożsamość per klient przez wszystkie, JEDNO miejsce na definiowanie planów, JEDNO miejsce na zarządzanie orgami i memberami. Cross-app SSO + claim linked_accounts to dokładnie ten scenariusz.
• Model B2B-z-B2B / reseller. To killer feature którego nikt inny (poza FrontEgg, częściowo) nie wdraża first-class. Chcesz żeby agencje odsprzedawały twój hosting? Network operatorzy spawn-owali org per gabinet w twoim dental CRM? Corporate trainerzy kupowali seat-packi dla wewnętrznych “kursantów”? Opt-in OidcClient.resellerMode i multi-tier hierarchia jest twoja, włącznie z custom domain per-reseller, branding cascade i 3-poziomową polityką fee.
• Chcesz plan gating który działa bez myślenia. Czytaj wolfieauth_plans z tokenu OIDC, wywołaj hasActiveFeature(claims, 'wolfie-twojaapka', 'ksef_enabled'), narenderuj feature albo nie. Bez DB joina z tabelą subscriptions którą musiałbyś inaczej utrzymywać. Dodanie nowego feature flag-a to jeden row w admin UI.
• Chcesz pay-per-use metering bez pisania pipeline-u meteringu. Sub-mituj usage events przez SDK; WolfieAuth agreguje, aplikuje free tiers, charge-uje overages, i bills na następnej fakturze klienta. Bez Kafki, bez Redis counterów, bez cron-job invoicing logiki po twojej stronie.
• EU residency i KSeF. Dane rezydują w EU. Polski KSeF jest zintegrowany przez wolfiecrm bridge — relewantne dla każdego vendora sprzedającego do polskich firm gdzie działa mandat KSeF 2026.
• Nie chcesz być tym który spierdoli auth security. Passkeys, TOTP, magic-links, RP-initiated logout, JWKS rotation, session sealing, replay-resistant webhooki, RFC 7662 introspection, RFC 7009 revocation — wszystko już jest, wszystko już zaudytowane przez ludzi którzy nic innego nie robią. Twoja praca staje się “drop in the SDK” zamiast “czytaj OIDC spec o północy.”
• Twój stack jest na liście SDK. Next.js, SvelteKit, Laravel, Sylius, Symfony, Django, Rails, Express, CakePHP, Go — wszystkie mają first-class adaptery z tymi samymi nazwami helperów. Wybierz swój, podążaj za quickstartem, gotowe.
• Chcesz jedno miejsce do comp-owania kont, suspendowania userów, refundów subskrypcji, mintowania test planów, debugowania claims klienta. Admin panel robi wszystko z tej listy. Bez bespoke “admin tools” sprintu na zbudowanie tego samego wewnątrz własnej apki.

Jeśli trzy lub więcej tych bullets opisują ciebie, WolfieAuth zwraca się sam w zaoszczędzonych engineering tygodniach zanim minie miesiąc.

Kiedy nie wybierać WolfieAuth

Uczciwa lista:

• Potrzebujesz self-hostingu z powodów compliance. Wybierz Keycloaka albo Authentik. WolfieAuth siedzi na infrze Wolfie; dane rezydują w EU ale to single-vendor dependency.
• Jesteś single-app SaaS bez planów multi-tier. Auth0/Stytch/better-auth są prostsze. Reseller features WolfieAuth są opt-in ale ogólny surface area jest szerszy bo to pełen IdP.
• Potrzebujesz workforce-IAM z SCIM provisioning do 30+ enterprise SaaS apek. To home turf Okty.
• Jesteś 100% w AWS i twoje “tenanty” to AWS account-y. Użyj IAM Identity Center + Control Tower.

Continue reading

• Tryb reseller — deep dive jak multi-tier działa w WolfieAuth.
• 3rd-party SSO — wpinanie WolfieAuth w Portainer, Grafana, Argo CD, Proxmox itd.
• SSO & Sesje — co siedzi na drucie podczas OIDC handshake.

Referencje

Źródłowa dokumentacja vendorów cytowana powyżej (sprawdzana kwiecień–maj 2026):

1. Auth0 — Organizations overview. https://auth0.com/docs/manage-users/organizations
2. Auth0 community — wieloletni thread feature-requestu parent-child organization. https://community.auth0.com/t/parent-child-organization-hierarchy/
3. Okta — Multi-org / Org Creator API concepts. https://developer.okta.com/docs/concepts/multi-org/
4. Okta — strona cennika (sales-gated dla Multi-Org SKU). https://www.okta.com/pricing/
5. WorkOS — Organizations API. https://workos.com/docs/user-management/organizations
6. WorkOS — FGA (Fine-Grained Authorization) docs. https://workos.com/docs/fga
7. Stytch — B2B Organizations guide. https://stytch.com/docs/b2b/guides/organizations
8. FrontEgg — Sub-Accounts / hierarchy docs. https://docs.frontegg.com/docs/sub-accounts
9. AWS — IAM Identity Center strona produktu. https://aws.amazon.com/iam/identity-center/
10. AWS — Control Tower (multi-account / MSP wzorzec). https://aws.amazon.com/controltower/
11. better-auth — root dokumentacji. https://www.better-auth.com/docs
12. better-auth — referencja plugina organization. https://www.better-auth.com/docs/plugins/organization
13. WolfieAuth — schema source of truth: apps/server/prisma/schema.prisma.
14. WolfieAuth — fee resolver: apps/server/src/billing/platform-fee-resolver.ts.
15. WolfieAuth — design doc trybu reseller: /sdks/reseller-mode/.

Dokument napisany: 2026-05-02. Vendor positioning zmienia się szybciej niż ta strona — jeśli wiersz matrycy jest zły bo konkurent wypuścił nowy feature, mailnij Wolfie i strona się zaktualizuje. Ostatnia weryfikacja przeciw żywym vendor docs w dniu pokazanym powyżej.

Ostatnia aktualizacja: 2026-05-03