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 screens itself.
Last checked 2026-11-02 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 a server written in Go, or MySQL or SQLite as the database.
- 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: 8 FoxAuth ·4Ory Hydra · 3 even ·2 different goals. A count is not a recommendation: weigh the rows that matter to you.
| Dimension | FoxAuth | Ory Hydra | Verdict |
|---|---|---|---|
| What you get in the box | |||
| Scope | ●OAuth 2.1 and OIDC server, plus end users, login, consent, registration, sign-in through other providers, a second factor 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 projects, managed through the console or the management API, or provisioned by a directory over SCIM 2.0. An administrator can invite people, sign them out of one application, or act on up to 100 at once. | ○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. |
| 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. | ○Delegated to the login application you provide. | FoxAuth With Hydra, upstream sign-in and a second factor are part of the login application you build. |
| 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 by default, OIDC Core and Discovery, RP-initiated and back-channel logout. | ●RFC 6749 with PKCE, OIDC Core, Discovery, and front- and back-channel logout. | Even Both are complete against the core specifications and both do back-channel logout; Hydra also documents front-channel logout, which FoxAuth does not implement. |
| 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), each behind a flag. | ?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, behind a flag. | ●RFC 7591, RFC 7592 and OIDC Dynamic Client Registration. | Even Both register clients dynamically. |
| 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 for Hydra. | FoxAuth SL1 is an OpenID Foundation working-group draft for enterprise sign-in. FoxAuth implements SL1 provider rules behind a flag, and Hydra’s documentation does not mention IPSIE. |
| Administration and licensing | |||
| Admin console | ●A server-rendered console for projects, applications, users, SCIM connections, usage, 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. |
| Managed hosting | ◐A free plan on FoxAuth Cloud, with limits and no SLA yet; paid plans are in development. Self-hosting has no limits. | ●Ory Network, the vendor-hosted service, alongside self-hosting. | Ory Hydra Both can be used without running anything. Ory can put a commercial agreement behind its hosted service today; FoxAuth Cloud cannot yet. |
| 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. |
| 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 for Hydra, which leaves sign-in to your login application. Ory Kratos, the identity system Ory pairs with it, stores the first tokens of a social sign-in encrypted, and its admin API returns them. Refreshing them, or handing them to an agent with the person’s consent, is not documented. | FoxAuth With Hydra, keeping and handing out upstream tokens is code you write around Kratos or your own store. FoxAuth ships the store, both consents and the refresh. What their docs sayKratos returns them as "initial_access_token", "initial_refresh_token" and "initial_id_token", only from the sign-up or the linking of a provider. |
| 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 | ◐1.4.0. The HTTP surface and admin API change incompatibly only in a major release. | ●Years of production deployment behind it. | Ory Hydra This is the strongest single argument for Hydra and this page will not soften it. |
Choose by how much of an identity system you already have
The table shows its widest gaps in protocol coverage, but the choice turns on 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 projects on the server, the server serves the login, consent and registration screens, and the admin console manages the users and their projects. The first token is issued before you have written a login or consent application.
Why the table says “not documented” for Hydra’s DPoP, PAR and CIBA
“Not documented” means exactly that: Ory’s own documentation for Hydra does not describe DPoP, PAR,
CIBA, mTLS or FAPI support. Community issues and discussions cover several of them, and fosite,
the library Hydra is built on, has implemented some. None of that is product documentation, and
this page does not make claims a vendor has not made about its 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, that gap is no reason to choose FoxAuth.
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 projects, 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 system to build and run.
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 reached its first stable release, 1.0.0, in October 2026: its HTTP surface and admin API now change incompatibly only in a major release, but it has no deployment history to set beside that of Hydra. 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 login and consent application you wrote for Hydra. FoxAuth serves those screens itself, so that application is no longer needed, but the users it authenticated have to be moved into a FoxAuth project.