Compare
FoxAuth compared with Zitadel
Zitadel is a multi-tenant identity platform with SAML, SCIM and a managed cloud. FoxAuth is a smaller OAuth 2.1 server with the banking-grade profiles built in.
Last checked 2026-09-18 against the linked sources. Zitadel changes. Where its documentation did not say, this page says so instead of guessing. Found something out of date? Tell us at hello@foxauth.dev.
The short answer
Pick Zitadel if you need SAML, SCIM provisioning or a managed cloud with an enterprise contract behind it. Pick FoxAuth for OAuth 2.1 behaviour by default, the banking-grade profiles without a plan tier, and a licence other than AGPL.
Choose Zitadel if…
- You need SAML 2.0 or SCIM 2.0 provisioning as well as OpenID Connect.
- You want a managed cloud option and an enterprise support contract from the vendor.
- You want a mature multi-tenant model with organisations built into the product.
- AGPL-3.0 is acceptable to you, or you will buy the commercial licence that replaces it.
Choose FoxAuth if…
- AGPL-3.0 is a problem for your distribution model and you want a licence that converts to Apache 2.0.
- You need DPoP, PAR, CIBA, mTLS, RAR or JARM, none of which Zitadel documents.
- Your team writes TypeScript and would rather extend named seams than run a Go service.
- You want an AI agent administering the instance through the same audited path a human uses.
Side by side
Every row has a verdict and the reason for it
- Built in
- Behind a flag, preview or add-on
- Not available
- Not documented
- Not applicable
Row verdicts: 3 FoxAuth ·6Zitadel · 2 even ·2 different goals. A count is not a recommendation. The rows that matter to you are the ones that count.
| Dimension | FoxAuth | Zitadel | Verdict |
|---|---|---|---|
| Scope and stack | |||
| Protocols beyond OAuth and OIDC | ○OAuth 2.1 and OpenID Connect only. No SAML, and none planned. | ●SAML 2.0 and SCIM 2.0 alongside OIDC. | Zitadel A single SAML-only application in your estate decides this comparison on its own. What their docs sayThe repository lists "SAML 2.0" and "SCIM 2.0 Server" among its features. |
| Runtime and stack | ●TypeScript on Bun; the HTTP layer is Elysia. | ●Go. | Different goals Pick the one your team can read and debug under pressure. |
| Storage | ●PostgreSQL or MongoDB in production, in-memory for tests, behind one adapter interface. | ●PostgreSQL 14 or newer. | Even Both run on the database most teams already operate; we also run on MongoDB. What their docs sayThe repository states "PostgreSQL (≥ 14)". |
| Multi-tenancy | ●User buckets, each its own issuer, addressed by a path or by a hostname of its own — group ownership decides who administers what. | ●Organisations, presented as a core part of the product. | Zitadel Zitadel has built its product around multi-tenancy for longer, and that experience probably shows. |
| Protocol coverage | |||
| Core OAuth and OIDC | ●OAuth 2.1 with PKCE mandatory for every client, OIDC Core and Discovery. | ●OpenID Connect certified. | Zitadel Certification is third-party evidence; FoxAuth has none yet. |
| Device flow | ●RFC 8628, behind a feature flag. | ●Device authorization, listed as a product feature. | Even Both implement it. |
| Sender-constrained tokens | ●DPoP (RFC 9449) and mTLS (RFC 8705). | ?Not documented. | FoxAuth If a regulator asks for sender-constrained tokens, this row is the answer. |
| PAR, CIBA, RAR and JARM | ●PAR (RFC 9126), CIBA, RAR (RFC 9396) and JARM, each behind a flag. | ?Not documented. | FoxAuth The banking-grade profiles ship here today; Zitadel's documentation does not mention them. |
| Machine-to-machine | ●Client credentials, with JWT client authentication. | ●JWT Profile, personal access tokens and client credentials. | Zitadel Zitadel also offers personal access tokens, and FoxAuth has no equivalent. |
| Administration and licensing | |||
| Administration by an AI agent | ●MCP control plane over the console's own routes, audited and confirmation-gated. Off by default. | ?Not documented. | FoxAuth The agent path here runs through the console's own code, so there is no second privileged API to secure. |
| Managed hosting | ◐A managed instance is on a waitlist; self-hosting is the only option today. | ●A vendor-operated cloud, alongside self-hosting. | Zitadel If you would rather not run it at all, Zitadel can take it off you today. |
| Licence | ◐FSL-1.1-ALv2: source-available, converting to Apache 2.0 after two years. | ◐AGPL-3.0, with Apache 2.0 and MIT exceptions for specific directories. | Different goals Neither is permissive. AGPL's network copyleft and FSL's competing-service restriction rule out different things. What their docs sayZitadel sells an enterprise contract whose commercial licence replaces the AGPL. |
| Maturity | ◐0.4.0. The HTTP surface and admin API may still change between minor releases. | ●Years of production deployment, a vendor cloud and enterprise contracts. | Zitadel The maturity gap is real, and it is probably the strongest argument for Zitadel. |
The row that usually decides it
If anything in your estate speaks SAML and only SAML, this comparison is over: Zitadel documents SAML 2.0 and SCIM 2.0, FoxAuth implements neither and has no plans to. That is not a gap waiting to be filled. It is a scope boundary we chose, and it is the honest reason to choose Zitadel.
Where FoxAuth is genuinely ahead
Two places, and both are narrow.
The first is the banking-grade profiles. DPoP, PAR, CIBA, mTLS, RAR and JARM are implemented and flag-controlled on the instance you run. Zitadel’s documentation does not describe them, so this page says “not documented” instead of “absent”. The distinction matters: a claim their own documentation does not make is not one we will make for them.
The second is the licence, and only for some readers. AGPL-3.0 is a genuine obstacle if you distribute software or offer a network service built on it, and the enterprise contract that replaces it is a commercial conversation. FSL-1.1-ALv2 has a narrower restriction: you may do anything except offer FoxAuth as a competing hosted service. It also expires on a schedule, with each version converting to Apache 2.0 two years after it ships.
Neither licence is permissive. If that is what you need, neither of these is your answer.
Questions
What people ask before they switch
Does FoxAuth support SAML like Zitadel does?
FoxAuth does not support SAML. It implements OAuth 2.1 and OpenID Connect only, and there is no SAML support planned. Zitadel documents SAML 2.0 and SCIM 2.0 alongside OIDC. If any application in your estate can only speak SAML, that settles it in Zitadel's favour and no other row on this page matters.
How do the licences differ?
Zitadel is AGPL-3.0 with Apache 2.0 and MIT exceptions for specific directories, and sells an enterprise contract whose commercial licence replaces the AGPL. FoxAuth is FSL-1.1-ALv2: you may read, modify, self-host and redistribute it and build a business around it, but not offer it as a competing hosted service. Each version converts to Apache 2.0 two years after it ships. AGPL's network-copyleft and FSL's competing-service restriction rule out different things, so which is the problem depends on what you are building.
Can I migrate from Zitadel to FoxAuth?
OIDC clients port over with an issuer and client id change. What does not port is anything relying on Zitadel's SAML or SCIM support, its organisation model, or its management API. FoxAuth models tenancy as user buckets: each is its own issuer, addressed either by a path beneath the server's URL or by a hostname of its own, so a client integrates with one exactly as it would with any authorization server. Assess the migration by how much of your estate is OIDC-only, because that part is usually straightforward and the rest is not.
Which is more production-ready?
Zitadel is the more mature of the two, on deployment history and on having a vendor-operated cloud and enterprise contracts behind it. FoxAuth is at a 0.4.0 release, so its HTTP surface and admin API may still change between minor versions. FoxAuth's advantage lies in specific protocol coverage and licence terms; it has none in maturity, and this page will not pretend otherwise.