WolfieAuth vs the IAM market

Auth0, Okta, WorkOS, Stytch, FrontEgg, AWS IAM Identity Center, better-auth — what they do, what they don't, and where WolfieAuth's reseller mode is genuinely different.

WolfieAuth vs the IAM market

Why this page exists: most “IAM comparison” articles are sponsored content thinly disguised as analysis. This one is honest engineering notes from building a product in the same space. Where the table says “yes” or “no,” it’s based on reading the vendor’s own docs (linked in each section). Where I wasn’t sure, the section says so explicitly.

TL;DR — the matrix

The columns that matter for B2B-of-B2B SaaS:

Legend: ✅ shipped & documented · ⚠️ partial / requires workarounds · 💰 gated to enterprise tier · ❌ not available

Auth0 — the incumbent that never grew B2B-of-B2B legs

Auth0 added the Organizations feature in 2021 and that’s where evolution stalled. Each organization is a flat tenant; you can put users in many orgs, but organizations cannot contain other organizations. The community has been asking for parent-child hierarchies since at least 2018 and the official answer is “use metadata + your own logic.”

What you get:

• Organization metadata, branded login per org, role assignments scoped per-org.
• Connections (the SAML/OIDC inbound bridges) can be enabled per-org — useful for “each customer has their own SAML IdP.”

What you don’t:

• Any concept of “this org owns those orgs.”
• Any billing primitive that recognises a reseller selling seat-packs to its sub-tenants.
• Any cascade-suspend or branding-inheritance that follows an org tree.

Pricing for the relevant B2B Essentials / Professional tiers starts in the high three figures USD/month and scales by Monthly Active Users. Reseller-of-reseller use cases require building the entire hierarchy layer yourself in your app DB.

Auth0 Organizations docs

Okta — has hierarchy, but as a separate paid SKU

Okta does have a “Org Creator API” (renamed in some materials to Multi-Org Deployment), explicitly designed for ISVs that want to spin up an Okta org per customer. This isn’t part of the regular Workforce / Customer Identity SKUs — it’s a separately negotiated add-on, and the price isn’t on the website. Public sales decks describe it as “for partners, MSPs, and ISVs.”

What you get:

• API to programmatically create child Okta orgs; each is a real, isolated tenant.
• Tooling to push users / apps from a “hub” org into child orgs.
• Each child gets its own subdomain on okta.com (e.g. <customer>.okta.com); custom domains require additional licensing.

What you don’t (out of the box):

• Any pre-built reseller billing model. The seat-pack accounting is your problem.
• A native UI in Okta for the reseller-tenant admin to provision their end-customers without admin API calls.

This is the closest mainstream IAM gets to true multi-tier, but the gating-by-SKU and the lack of a turn-key reseller billing layer mean most ISVs build something custom on top.

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

WorkOS — hierarchy via FGA, no first-class reseller concept

WorkOS positions itself as the “Stripe for B2B auth.” Their Organizations API is solid for flat multi-tenancy; for hierarchy they point you at FGA (Fine-Grained Authorization), a Zanzibar-style relationship engine.

What you can build with FGA:

• Define organization, workspace, user types and parent, member relations.
• Express “user X has access to all workspaces under org Y via inheritance.”
• Query “what can this user see” with permission-inheritance traversal.

What’s still on you:

• Modelling “this org is a reseller of acme-cloud-product” — there’s no opinionated primitive for it; you encode it in FGA tuples and reseller seat-limits in your own DB.
• Billing splits, cascade-suspend, branding cascade, custom domains per reseller — all greenfield work.

WorkOS’s strength is its developer ergonomics (clean APIs, generous free tier on connections), and FGA is genuinely useful for permission inheritance. But “we do reseller mode” is more accurately stated as “our primitives don’t get in your way when you build reseller mode.”

WorkOS Organizations · WorkOS FGA

Stytch — flat orgs only, no nested hierarchy

Stytch B2B has Organizations and Members. There is no native parent-child organization hierarchy, no MSP/reseller construct, no concept of one org seeing another’s data via inheritance. They optimise for the flat-tenant SaaS case and that’s it.

If you’re building a single-tier B2B SaaS Stytch is excellent — clean SDKs, good passwordless support, pricing scales sanely. The moment you need “agency owns these 50 sub-tenants and bills them per seat,” you’re building it on top of your own backend.

Stytch B2B Organizations

FrontEgg — closest competitor on B2B-of-B2B

This is the one product on the market that explicitly markets to MSPs and resellers. FrontEgg has shipped Sub-Accounts (parent-child tenant hierarchy), an admin UI with Table + Graph views of the tree, and dedicated APIs for creating sub-tenants on behalf of a parent.

What FrontEgg does well:

• Sub-account creation API with a “delegation” concept — parent admins can manage child tenants.
• Per-tenant branding inherited from parent unless overridden.
• Integrated entitlements layer that flows through sub-tenants.

What FrontEgg’s docs are quieter about:

• Per-reseller seat-pack billing primitives (their entitlement engine handles flat per-tenant; multi-tier seat allocation isn’t called out).
• Cascade-suspend across the sub-account tree.
• Reseller-specific custom domains as opposed to per-app custom domains.

Pricing is per-tenant and tiers up quickly once you go past the starter SKU. For MSP plays specifically, contact-sales territory.

FrontEgg is the platform you’d compare WolfieAuth to head-to-head if you were procuring. WolfieAuth’s edge: cheaper because it’s Wolfie’s hosted SaaS (no enterprise sales overhead), opinionated reseller billing baked into the same panel as the rest of the IAM, and the cascade-suspend / signup-token model is explicit and one-click.

FrontEgg Sub-Accounts

AWS IAM Identity Center — wrong shape for SaaS reseller

IAM = Identity and Access Management — Amazon’s umbrella term for everything around “who is this principal and what is it allowed to do” inside an AWS account. The base service (just called IAM) lets you create users, groups, roles, and policies that govern API access to AWS resources. IAM Identity Center (formerly AWS SSO) sits one layer above: instead of managing users per-AWS-account, it gives you a single sign-on dashboard across an entire AWS Organization (Amazon’s top-level container that groups multiple AWS accounts under one billing entity), federates a corporate IdP into all of them, and hands users role-based access to whichever accounts they’re entitled to.

AWS IAM Identity Center is built for AWS-account-internal identity federation. You federate corporate IdPs, you assign users to AWS accounts via permission sets, you run one Identity Center per AWS Organization.

Multi-tier in this world means:

• AWS Organizations → AWS accounts (the “tenant” boundary in cloud terms).
• An MSP reselling AWS to clients runs AWS Control Tower, which provisions a separate AWS account per client, with a separate Identity Center setup.
• Billing splits go through AWS consolidated billing — usage rolls up to the management account, MSP rebills clients out-of-band.

This works for “reseller of cloud infrastructure,” not for “reseller of a SaaS app I built on top of WolfieAuth.” If your end-product is “use my web app,” IAM Identity Center is the wrong tool. AWS would point you at Cognito User Pools + your own multi-tenancy layer — and Cognito’s hierarchy story is no better than Auth0’s.

AWS IAM Identity Center · AWS Control Tower

better-auth — beautiful TypeScript-native code, flat orgs

better-auth is a young, fast-growing TypeScript-first auth library with first-class passkeys, magic-link, and an organization plugin. It’s open-source, you self-host it inside your app process (no separate IdP service), and the code quality is genuinely good.

What it does:

• Email/password, passkey, magic link, OAuth providers (Google/GitHub/etc), 2FA — all clean.
• Organizations plugin: users belong to one or more orgs, role per org.
• Open SDK ecosystem; community plugins.

What it doesn’t:

• No nested organisations. From the official docs: organizations are flat; there is no parent-child hierarchy plugin.
• No reseller / MSP primitive of any kind.
• No multi-app SSO (because it lives inside your app, not as a separate IdP — a different shape entirely).

If your problem is “I want auth in my single Node.js app and I don’t want to run a separate IdP,” better-auth is excellent and free. If your problem is “I’m building a platform where 50 customers each resell my product to their own clients,” it’s the wrong layer to put that at.

better-auth docs

Where WolfieAuth lands

WolfieAuth is built and operated by @wolfie as a hosted SaaS — auth.wolfieguard.com runs on Wolfie’s VPS infrastructure, you don’t self-host. The product opinion that drove the reseller work:

The auth layer is the right place for hierarchy, branding cascade, and seat-pack billing — because it’s the only layer that sees every tenant, every login, every payment. Pushing that work into each downstream app means rebuilding it five times.

What you get on top of OIDC basics that nobody else (except FrontEgg, partially) ships:

1. OidcClient.resellerMode = true opt-in per app — your existing flat-tenant apps stay flat unless you want hierarchy.
2. AppReseller table with seat-limit, signup-token, custom-domain-per-reseller, fee-bps overrides.
3. 3-level fee policy (PlatformConfig → OidcClient override → AppReseller override) — Wolfie bills the platform-fee on reseller subscriptions, owner-org gets seat-pack revenue, reseller bills end-customers out-of-band.
4. Branding cascade — client.theme ← OidcClient.defaultChildTheme ← AppReseller.childTheme.
5. OIDC claims — wolfieauth_org_parentId, wolfieauth_reseller_apps[] so SDKs in any framework gate UI on isResellerOf(claims, clientId).
6. Cascade-suspend — flip AppReseller.status = "SUSPENDED" and a cron flips LinkedAccount.suspendedAt for every child-org member of that app.

Things WolfieAuth doesn’t try to be:

• Self-hostable like Keycloak / better-auth. It’s a hosted SaaS — that’s deliberate; the cost trade-off is that you get an actively maintained, KSeF-aware, EU-resident IdP without running it.
• A workforce-IAM (corporate SSO for your employees). The flow is consumer-IAM and B2B SaaS auth — not “federate Okta from my AD.”
• A first-class FGA / ReBAC engine like WorkOS FGA. Permissions are role-based with a permissions[] claim; for relationship-based gates your app does the modelling.

Honest sources & verification status

Each section above is based on the linked vendor doc and the WolfieAuth source code in the wolfieauth repo. Verified vs inferred:

• Verified by reading current docs (April 2026): Auth0 Organizations, WorkOS FGA, Stytch B2B Organizations, FrontEgg Sub-Accounts, better-auth Organization plugin.
• Inferred from public materials but not deeply tested: Okta Multi-Org pricing/SKU specifics (sales-gated, no public price), AWS Control Tower MSP billing flow at scale.
• WolfieAuth side: directly from the source — schema in apps/server/prisma/schema.prisma, fee resolver in apps/server/src/billing/platform-fee-resolver.ts, SDK helpers in packages/wolfieauth-sdk-*.

If you spot a factual error in a competitor section, mail Wolfie and the page gets fixed — vendor positioning shifts faster than this doc, and getting the facts right matters more than scoring rhetorical points.

When to pick WolfieAuth

WolfieAuth is the right call when you want to ship a SaaS or PaaS at light speed and treat identity, membership, billing, branding, and usage metering as solved problems instead of months of plumbing. Specifically:

• You’re building a new B2B SaaS and want auth/orgs/roles/plans/billing on day one. Most “auth providers” stop at sign-in; you’d still wire up Stripe, plan picker UI, seat-based billing, invoice issuance, organisation management, member invites, role assignments, plan gating in your code. WolfieAuth ships that whole stack as one drop-in. From git init to a paying customer in days, not months.
• You want a hosted IdP but your apps stay on your own infrastructure. WolfieAuth runs at auth.wolfieguard.com. Your apps run wherever you want — your VPS, your Kubernetes, your Vercel, your Cloudflare Workers. WolfieAuth handles the IdP, you keep operational ownership of the product. Best of both worlds versus “all-in on Auth0/Okta where the vendor sees every product request.”
• Multi-app suite. If you’re building several apps that share a customer base (a CRM, a mail tool, a billing tool, a portfolio of micro-SaaS), WolfieAuth means ONE identity per customer across all of them, ONE place to define plans, ONE place to manage orgs and members. The cross-app SSO + linked_accounts claim is exactly this scenario.
• B2B-of-B2B / reseller model. This is the killer feature that nobody else (except FrontEgg, partially) ships first-class. Want agencies to resell your hosting? Network operators to spawn an org per practice on your dental CRM? Corporate trainers to buy seat-packs for their internal “students”? Opt-in OidcClient.resellerMode and the multi-tier hierarchy is yours, including custom domains per reseller, branding cascade, and 3-level fee policy.
• You want plan gating that works without thinking about it. Read wolfieauth_plans from the OIDC token, call hasActiveFeature(claims, 'wolfie-yourapp', 'ksef_enabled'), render the feature or don’t. No DB join with a subscriptions table you’d otherwise have to maintain. Adding a new feature flag is one row in the admin UI.
• You want pay-per-use metering without writing a metering pipeline. Submit usage events through the SDK; WolfieAuth aggregates, applies free tiers, charges overages, and bills on your customer’s next invoice. No Kafka, no Redis counters, no cron-job invoicing logic on your end.
• EU residency and KSeF. Data sits in the EU. Polish KSeF e-invoicing is integrated through the wolfiecrm bridge — relevant for any vendor selling to Polish businesses where the 2026 KSeF mandate applies.
• You don’t want to be the one who screws up auth security. Passkeys, TOTP, magic-links, RP-initiated logout, JWKS rotation, session sealing, replay-resistant webhooks, RFC 7662 introspection, RFC 7009 revocation — all already there, all already audited by people who do nothing else. Your job becomes “drop in the SDK” rather than “read the OIDC spec at midnight.”
• Your stack is on the SDK list. Next.js, SvelteKit, Laravel, Sylius, Symfony, Django, Rails, Express, CakePHP, Go — all have first-class adapters with the same helper names. Pick the one for your stack, follow the quickstart, you’re done.
• You want a single place to comp accounts, suspend users, refund subscriptions, mint test plans, debug a customer’s claims. The admin panel does all of that. No bespoke “admin tools” sprint to build the same thing inside your own app.

If three or more of those bullets describe you, WolfieAuth pays for itself in saved engineering weeks before you’re a month in.

When not to pick WolfieAuth

The honest list:

• You need self-hosting because of compliance. Pick Keycloak or Authentik. WolfieAuth runs on Wolfie’s infra; data resides EU but it’s a single-vendor dependency.
• You’re a single-app SaaS with no plans for multi-tier. Auth0/Stytch/better-auth are simpler. WolfieAuth’s reseller features are opt-in but the overall surface area is broader because it’s a full IdP.
• You need workforce-IAM with SCIM provisioning into 30+ enterprise SaaS apps. That’s Okta’s home turf.
• You’re 100% in AWS and your “tenants” are AWS accounts. Use IAM Identity Center + Control Tower.

Continue reading

• Reseller mode — the deep dive on how the multi-tier features actually work in WolfieAuth.
• 3rd-party app SSO — wiring WolfieAuth into Portainer, Grafana, Argo CD, Proxmox, etc.
• SSO & Sessions — what’s on the wire during the OIDC handshake.

References

Primary vendor documentation cited above (consulted April–May 2026):

1. Auth0 — Organizations overview. https://auth0.com/docs/manage-users/organizations
2. Auth0 community — long-running parent-child organization request thread. 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 — pricing page (sales-gated for 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 product page. https://aws.amazon.com/iam/identity-center/
10. AWS — Control Tower (multi-account / MSP pattern). https://aws.amazon.com/controltower/
11. better-auth — official documentation root. https://www.better-auth.com/docs
12. better-auth — organization plugin reference. https://www.better-auth.com/docs/plugins/organization
13. WolfieAuth — schema source of truth: apps/server/prisma/schema.prisma.
14. WolfieAuth — fee resolver source: apps/server/src/billing/platform-fee-resolver.ts.
15. WolfieAuth — reseller-mode design doc: /sdks/reseller-mode/.

Document written: 2026-05-02. Vendor positioning shifts faster than this page — if a row in the matrix is wrong because a competitor shipped a new feature, please email Wolfie and the page gets updated. Last verified against live vendor docs on the date shown above.

Last updated: 2026-05-03