Compare
FoxAuth compared with Zitadel
Zitadel is a multi-tenant identity platform with SAML and a managed cloud. FoxAuth is a smaller OAuth 2.1 server with the banking-grade profiles built in.
Last checked 2026-11-02 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 or a managed cloud with an enterprise contract behind it. Pick FoxAuth for OAuth 2.1 behaviour by default, the banking-grade profiles that Zitadel does not document, and a licence other than AGPL.
Choose Zitadel if…
- You need SAML 2.0 as well as OpenID Connect.
- You want a managed cloud with an SLA 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: 5 FoxAuth ·7Zitadel · 2 even ·2 different goals. A count is not a recommendation: weigh the rows that matter to you.
| Dimension | FoxAuth | Zitadel | Verdict |
|---|---|---|---|
| Scope and stack | |||
| Protocols beyond OAuth and OIDC | ◐SCIM 2.0 provisioning of users and groups, behind scim.enabled. No SAML, and none planned. | ●SAML 2.0 and SCIM 2.0 alongside OIDC. | Zitadel Both serve SCIM; 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 PostgreSQL; we also run on MongoDB. What their docs sayThe repository states "PostgreSQL (≥ 14)". |
| Multi-tenancy | ●Projects (FoxAuth's tenants), each its own issuer, addressed by a path, a subdomain of the instance or a hostname of its own. Team ownership decides who administers what. A project moves between teams with its applications and APIs and counts its own monthly active users. | ●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. |
| Sign-in through other providers | ◐Google, Microsoft, Apple and GitHub by name, and any other OIDC provider by hand, per project and behind federation.enabled. A TOTP second factor can be required per project. | ●Social and enterprise identity providers, including generic OIDC, SAML and LDAP. | Zitadel Both let people sign in with an account they already have; Zitadel also connects SAML and LDAP directories. |
| Protocol coverage | |||
| Core OAuth and OIDC | ●OAuth 2.1 with PKCE mandatory for every client by default, 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), each behind a flag. | ?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, behind a flag. | ●JWT Profile, personal access tokens and client credentials. | Zitadel Zitadel also offers personal access tokens, and FoxAuth has no equivalent. |
| IPSIE SL1 profile | ◐The provider side of the draft behind ipsieSl1.enabled, with a readiness check before you switch. Some requirements are still open, such as prompting for a second factor when an application asks for one. | ?Not documented. | FoxAuth SL1 is an OpenID Foundation working-group draft for enterprise sign-in. FoxAuth implements SL1 provider rules behind a flag, and Zitadel’s documentation does not mention IPSIE. |
| 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. |
| Token vault for AI agents | ●A person's token at Google, GitHub, Slack, Microsoft or any OIDC or OAuth 2.0 provider, through a standard RFC 8693 token exchange. An administrator lists the applications allowed per service, and the person allows each agent per account and can withdraw it. One refresh at a time, idle accounts kept alive, and a mail to the person when an account breaks. When the person must connect, allow or reconnect an account, the refusal carries a link the agent hands them, ready for an MCP URL elicitation, and the link works only for that person after their own sign-in. Free to self-host; 10 connected services per project on the FoxAuth Cloud Free plan. | ?Not documented. A custom login UI can read the access token an external identity provider returned for one sign-in or account link. Storing it for applications, refreshing it, or exchanging it for an agent is not documented. Zitadel’s RFC 8693 token exchange covers its own tokens: narrowing scope and audience, impersonation and delegation. | FoxAuth Zitadel documents the upstream token only inside a sign-in. FoxAuth keeps it, refreshes it, and hands it to the agents that an administrator and the person both allowed. What their docs sayThe external login guide shows the provider’s accessToken in the answer to retrieving an identity provider intent, and its use there is creating a session or linking a user. |
| Managed hosting | ◐A free plan on FoxAuth Cloud, with limits and no SLA yet; paid plans are in development. Self-hosting has no limits. | ●A vendor-operated cloud, alongside self-hosting. | Zitadel Both can be used without running anything. Zitadel can also put a contract and an SLA behind its cloud today; FoxAuth Cloud cannot yet. |
| 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 | ◐1.4.0. The HTTP surface and admin API change incompatibly only in a major release. | ●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. |
SAML usually decides it: Zitadel has it, FoxAuth has no plans for it
If anything in your estate speaks SAML and only SAML, this comparison is over: Zitadel documents SAML 2.0, and FoxAuth does not implement it and has no plans to. Both serve SCIM 2.0 for provisioning, so SCIM does not separate them. We left SAML out of scope by choice, so that gap will not be filled, and it is the honest reason to choose Zitadel.
FoxAuth is ahead in two narrow places: protocol profiles and licence
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”: we will not make a claim about Zitadel that its own documentation does not make.
The second is the licence, and only for some readers. AGPL-3.0 is an 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 you need a permissive licence, 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, and none is planned. Besides OAuth 2.1 and OpenID Connect it serves SCIM 2.0, so a directory can provision users and groups into it, but it never speaks SAML. 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 support, its organisation model, or its management API; a directory that provisions over SCIM can be pointed at a FoxAuth project's `/scim/v2` instead. FoxAuth models tenancy as projects. A FoxAuth project is a tenant, not to be confused with a Zitadel project. Each one is its own issuer, addressed by a path beneath the server's URL, a subdomain of the instance or 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 because its cloud has an SLA and enterprise contracts behind it. FoxAuth Cloud has a free plan but no SLA yet. FoxAuth reached its first stable release, 1.0.0, in October 2026, and has no deployment history to match. FoxAuth's advantage lies in specific protocol coverage and licence terms; it has none in maturity, and this page will not pretend otherwise.