Compare
FoxAuth compared with Ory Hydra
Ory Hydra is an OAuth 2.0 and OpenID Connect server that delegates login to an app you write. FoxAuth ships the login, consent and admin surfaces with it.
Last checked 2026-09-06 against the linked sources. Ory Hydra 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 Ory Hydra if you already have an identity system and want a hardened, Apache-licensed OAuth server sitting in front of it. Pick FoxAuth if you would rather not build a login and consent application before issuing your first token.
Choose Ory Hydra if…
- You already run your own user store and login UI, and want an OAuth server that stays out of it.
- You need a permissive Apache-2.0 licence with no source-available restriction.
- You want Go, or a relational database you already operate.
- You want the option of a commercially supported build from the vendor.
Choose FoxAuth if…
- You want users, login, consent, registration and an admin console shipped with the server instead of left for you to build.
- You need DPoP, PAR, CIBA, mTLS, RAR or JARM, none of which Ory documents for Hydra.
- 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 ·3Ory Hydra · 3 even ·2 different goals. A count is not a recommendation. The rows that matter to you are the ones that count.
| Dimension | FoxAuth | Ory Hydra | Verdict |
|---|---|---|---|
| What you get in the box | |||
| Scope | ●OAuth 2.1 and OIDC server, plus end users, login, consent, registration and an admin console. | ◐OAuth 2.0 and OIDC server. Login and consent are a separate application you provide. | FoxAuth Hydra stays out of identity by design; with FoxAuth there is no second application to build. What their docs sayThe quickstart runs Hydra alongside "an exemplary User Login & Consent App". |
| User storage | ●End users live in buckets, managed through the console or the management API. | ○No user store. Ory positions Kratos as the identity system to pair with Hydra. | Different goals If you already run an identity system, Hydra staying out of it is probably what you want. |
| 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. What their docs sayThe repository states Hydra is "Written in Go". |
| Storage | ●PostgreSQL or MongoDB in production, in-memory for tests, behind one adapter interface. | ●PostgreSQL, MySQL and SQLite. | Ory Hydra Both speak PostgreSQL; Hydra also speaks MySQL and SQLite. |
| Protocol coverage | |||
| Core OAuth and OIDC | ●OAuth 2.1 with PKCE mandatory for every client, OIDC Core and Discovery. | ●RFC 6749 with PKCE, OIDC Core, Discovery, and front- and back-channel logout. | Even Both are complete against the core specifications, and Hydra also documents front- and back-channel logout. |
| Device flow | ●RFC 8628, behind a feature flag. | ●RFC 8628, documented with a configuration guide. | Even Both implement it. What their docs sayOry documents the device authorization grant separately from the repository README. |
| Sender-constrained tokens | ●DPoP (RFC 9449) and mTLS (RFC 8705). | ?Not documented for Hydra. | FoxAuth This is the clearest protocol gap between the two, and the reason to weigh FoxAuth for a regulated deployment. |
| PAR, CIBA, RAR and JARM | ●PAR (RFC 9126), CIBA, RAR (RFC 9396) and JARM, each behind a flag. | ?Not documented for Hydra. | FoxAuth The banking-grade profiles are already implemented here; none of them is a roadmap item. |
| Dynamic client registration | ●RFC 7591 and RFC 7592. | ●RFC 7591, RFC 7592 and OIDC Dynamic Client Registration. | Even Both register clients dynamically. |
| Administration and licensing | |||
| Admin console | ●A server-rendered console for projects, clients, users, settings, keys and an append-only audit trail. | ◐Administration is through the API and CLI; Ory Network is the vendor-hosted console. | FoxAuth Self-hosted Hydra is administered by API; FoxAuth ships the console with the server. |
| Administration by an AI agent | ●MCP control plane over the console's own routes, audited and confirmation-gated. Off by default. | ?Not documented. | FoxAuth Hydra's documentation has nothing on agent administration. FoxAuth gives an agent the same audited console path a person uses, and keeps the whole surface off until you enable it. |
| Licence | ◐FSL-1.1-ALv2: source-available, converting to Apache 2.0 after two years. | ●Apache-2.0. | Ory Hydra Apache-2.0 carries no competing-service restriction; FSL does until each version converts. What their docs sayOry offers "support for self-hosted Ory software through the Ory Enterprise License (OEL)". |
| Maturity | ◐0.4.0. The HTTP surface and admin API may still change between minor releases. | ●Years of production deployment behind it. | Ory Hydra This is the strongest single argument for Hydra and this page will not soften it. |
Where the two genuinely differ
The comparison is not really about protocol coverage, though that is where the table shows the widest gaps. It is about how much of an identity system you already have.
Ory Hydra is an OAuth and OpenID Connect server built not to manage users. Its quickstart runs a separate login and consent application beside it, and Ory sells a second product, Kratos, as the identity system to pair with it. That split is usually a virtue when you already have a user store and a login page you trust: Hydra issues tokens against your authentication decisions and stays out of everything else.
FoxAuth makes the opposite bet. End users live in buckets on the server, the login, consent and registration screens are served by it, and the admin console manages all of it. The first token is issued before you have written any application at all.
What the protocol table does and does not say
Where this page records a capability as “not documented”, that is exactly what it means: Ory’s own
documentation for Hydra does not describe DPoP, PAR, CIBA, mTLS or FAPI support. There are community
issues and discussions about several of them, and the underlying fosite library has implemented
some. None of that is product documentation, and this page does not make claims a vendor has not
made about their own product.
If you need sender-constrained tokens or the banking-grade profiles today, that gap is the reason to look at FoxAuth. If you do not, it is not.
Questions
What people ask before they switch
What is the difference between FoxAuth and Ory Hydra?
Ory Hydra is an OAuth 2.0 and OpenID Connect server that does not manage identities: its quickstart has you run a separate login and consent application alongside it, and Ory sells Kratos as the identity system to pair with it. FoxAuth is both halves in one server: it stores end users in buckets, serves the login, consent and registration screens, and issues the tokens. If you already have an identity system, Hydra's split is an advantage; if you do not, it is a second project.
Does Ory Hydra support DPoP, PAR or FAPI?
Ory's own documentation for Hydra does not cover DPoP, PAR, CIBA, mTLS or FAPI, so this page records them as not documented and stops short of calling them absent. Community threads discuss them, but a claim that is missing from the product documentation is one this page will not make. FoxAuth implements DPoP (RFC 9449), PAR (RFC 9126), mTLS (RFC 8705), CIBA, RAR (RFC 9396) and JARM, each behind a feature flag on the instance you run.
Is Ory Hydra more production-ready than FoxAuth?
On the evidence of deployment history, Ory Hydra is the more production-ready of the two. It has been in production use for years, is Apache-2.0 licensed with no source-available restriction, and has a commercial support option from the vendor. FoxAuth is at a 0.4.0 release, which means its HTTP surface and admin API may still change between minor versions. That is a real difference and it is the strongest argument for choosing Hydra.
Can I migrate from Ory Hydra to FoxAuth?
OAuth clients port over. Both servers speak the same protocol, so a client changes its issuer URL and client id and keeps working. The larger piece of work is the opposite of a migration: the login and consent application you wrote for Hydra becomes unnecessary, because FoxAuth serves those screens itself, and the users it authenticated have to be moved into a FoxAuth user bucket.