Compare
FoxAuth compared with authentik
authentik is a self-hosted identity provider covering SAML, LDAP and RADIUS as well as OIDC. FoxAuth does OAuth 2.1 only, with the banking-grade profiles.
Last checked 2026-11-02 against the linked sources. authentik 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 authentik if you are replacing an SSO estate that speaks SAML, LDAP or RADIUS as well as OIDC. If the applications are your own and what you need is an OAuth 2.1 authorization server with the banking-grade profiles and no enterprise tier to buy, pick FoxAuth.
Choose authentik if…
- Your estate has applications that speak SAML, LDAP or RADIUS alongside OpenID Connect.
- You want a broad SSO product, with flows, policies and outposts, more than you want a protocol server.
- You want an MIT-licensed core with no source-available restriction.
- You are consolidating logins across bought software instead of issuing tokens to your own.
Choose FoxAuth if…
- You are securing your own applications and every one of them speaks OAuth or OIDC.
- You need DPoP, PAR, CIBA, mTLS, RAR or JARM, none of which authentik documents.
- You want a smaller operational surface than a Python, Go and Rust stack with PostgreSQL behind it.
- 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: 7 FoxAuth ·4authentik · 1 even ·2 different goals. A count is not a recommendation: weigh the rows that matter to you.
| Dimension | FoxAuth | authentik | Verdict |
|---|---|---|---|
| Scope and stack | |||
| Protocols | ○For sign-in, OAuth 2.1 and OpenID Connect only; SCIM 2.0 provisioning behind scim.enabled. No SAML, LDAP or RADIUS. | ●SAML, OAuth2/OIDC, LDAP and RADIUS. | authentik authentik covers an estate; FoxAuth covers applications that speak OAuth. What their docs sayThe repository describes authentik as supporting "SAML, OAuth2/OIDC, LDAP, RADIUS, and more". |
| What it is for | ●An authorization server issuing tokens to applications you build. | ●An identity provider for single sign-on across applications you run. | Different goals These are adjacent products, each built for a different job. |
| 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. | ●Sources: social and OAuth providers, SAML, LDAP and more, with flows deciding what happens next. | authentik Both let people sign in with an account they already have; authentik's sources reach further, into SAML and LDAP. |
| Runtime and stack | ●TypeScript on Bun; the HTTP layer is Elysia. | ●Python, Go, Rust and TypeScript components. | Different goals authentik has the broader stack because it does more; a smaller stack tends to be easier to reason about. |
| Deployment footprint | ●One process and a database. | ●Documented minimum of 2 CPU cores and 2 GB of RAM, with PostgreSQL. | FoxAuth A smaller footprint, for a smaller job. What their docs sayThe install guide requires "A host with at least 2 CPU cores and 2 GB of RAM". |
| Protocol coverage | |||
| Core OAuth and OIDC | ●OAuth 2.1 with PKCE mandatory for every client by default, OIDC Core and Discovery. | ●OAuth2 and OIDC as one of several supported protocols. | FoxAuth Mandatory PKCE, exact redirect matching and no implicit grant are the OAuth 2.1 defaults, and in FoxAuth OAuth is the entire product. In authentik, OAuth is one protocol among four. |
| Sender-constrained tokens | ◐DPoP (RFC 9449) and mTLS (RFC 8705), each behind a flag. | ?Not documented. | FoxAuth Sender-constrained tokens matter mainly in regulated deployments, where they are likely to be decisive. |
| PAR, CIBA, RAR and JARM | ◐PAR (RFC 9126), CIBA, RAR (RFC 9396) and JARM, each behind a flag. | ?Not documented. | FoxAuth FoxAuth implements all four of these banking-grade profiles; authentik does not document them. |
| Device flow | ◐RFC 8628, behind a feature flag. | ●RFC 8628, once a device code flow is configured on the brand. | Even Both implement it. |
| 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 authentik’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 authentik's documentation describes no agent surface. Here an agent goes through the console's own routes and lands in the same audit trail a person does. |
| 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. An OAuth source passes the tokens of a sign-in to its property mappings during that sign-in. Storing them for applications, refreshing them, or handing them to an agent is not documented. | FoxAuth authentik documents the upstream tokens only while a sign-in runs. FoxAuth keeps them, refreshes them, and hands them to the agents that an administrator and the person both allowed. What their docs sayThe OAuth source page describes `token` as "A Python dictionary containing the OAuth tokens for this login." |
| Licence | ◐FSL-1.1-ALv2: source-available, converting to Apache 2.0 after two years. | ●MIT for the core, with a separate enterprise licence for enterprise features. | authentik An MIT core carries no competing-service restriction; FSL does until each version converts. What their docs sayThe repository lists an "MIT License" for the code and an "EE License" for enterprise features. |
| Maturity | ◐1.4.0. The HTTP surface and admin API change incompatibly only in a major release. | ●An established project with a large self-hosting community. | authentik authentik has the larger community and years more production deployment. |
authentik is an SSO identity provider; FoxAuth is an OAuth server
Most comparisons on this site weigh two implementations of the same thing. This one does not.
authentik is an identity provider for single sign-on. Its value is that it speaks SAML, LDAP and RADIUS as well as OIDC, which is what you need when the things logging in are appliances and bought software you cannot change. FoxAuth is an OAuth 2.1 authorization server: it issues tokens to applications you build, and for sign-in it speaks nothing but OAuth and OpenID Connect.
Anyone consolidating logins across an estate wants authentik’s category of product, and FoxAuth is not in it. If you are securing your own applications and every one of them speaks OIDC, the extra protocols are surface you would have to operate, and would probably never use.
Where authentik and FoxAuth overlap: issuing OIDC tokens
Both issue OIDC tokens, and for that job the differences are narrow but specific. FoxAuth defaults to OAuth 2.1 behaviour: PKCE is mandatory for every client by default, public or confidential, redirect URIs must match exactly, and there is no implicit grant. FoxAuth can hold those defaults because OAuth is its entire product, where for authentik OAuth is one protocol among four. FoxAuth also implements the banking-grade profiles (DPoP, mTLS, PAR, CIBA, RAR and JARM), and authentik does not document them.
The table gives authentik the rows on protocols, sign-in sources, licence and maturity: a broader protocol surface, an MIT-licensed core, and years more production deployment.
Questions
What people ask before they switch
What is the difference between FoxAuth and authentik?
authentik is an identity provider for single sign-on across an estate: it describes itself as supporting "SAML, OAuth2/OIDC, LDAP, RADIUS, and more", which is usually what you want when the things logging in are bought software you do not control. FoxAuth is an OAuth 2.1 and OpenID Connect authorization server for applications you do control, and it speaks nothing else. They overlap on OIDC and diverge everywhere else.
Does FoxAuth support LDAP or RADIUS?
FoxAuth supports neither LDAP nor RADIUS, and neither is planned. For sign-in it implements OAuth 2.1 and OpenID Connect only; SCIM 2.0, which it also serves, provisions users and signs no one in. authentik supports LDAP and RADIUS as well as SAML, so if you need to put a login in front of an appliance or a legacy application that speaks one of those, FoxAuth cannot do it and authentik can.
Is FoxAuth lighter to run than authentik?
FoxAuth is a single Bun process and one database, PostgreSQL or MongoDB. authentik's install guide asks for a host with at least 2 CPU cores and 2 GB of RAM, and its repository contains Python, Go, Rust and TypeScript components with PostgreSQL behind them. authentik's surface is broader because authentik does considerably more. Whether the extra weight is worth carrying depends on whether you need the protocols it adds.
Can I migrate from authentik to FoxAuth?
Only if everything you have connected to authentik speaks OIDC. Those clients port over with an issuer and client id change. Anything connected over SAML, LDAP or RADIUS has no path, because FoxAuth does not implement those protocols. That part of the estate would have to be re-integrated over OIDC first, and in most cases the re-integration is a larger project than the migration itself.