Ory Hydra: a headless OAuth2 and OpenID Connect server for your own login UI

The problem Ory Hydra solves: token issuance without owning the user table

Most OAuth2 servers arrive bundled with a user database, a registration form and a password reset flow. That bundle is convenient until the day you already have users somewhere else and now run two sources of truth for identity. Ory Hydra takes the opposite position. The README describes it as a standalone OAuth 2.0 and OpenID Connect server without user management, which connects to your existing identity provider through a login and consent app. Hydra knows about clients, scopes, consent grants, tokens and JWKS keys. It does not know who your users are.

The intended audience is therefore narrow and specific. You are building a platform where authentication already happens, whether through Ory Kratos, authboss, User Frosting or a proprietary system, and you now need to hand out OAuth2 access tokens and OIDC identity tokens to third-party applications, first-party mobile clients or machine-to-machine callers. The repository topics list oauth2-provider, openid-connect-provider and sso, which matches that framing. If you have no identity system yet, Hydra is the wrong starting point: it will not create one for you.

How the login and consent app splits Hydra's data flow

The mechanism is a redirect handoff. A client application sends a user to Hydra's authorization endpoint. Hydra does not render a login form. Instead it redirects the browser to a login URL and a consent URL that you configure, and your application decides what to show and what to collect. When the user finishes, your app calls back into Hydra's admin API to accept or reject the login and consent requests. Only then does Hydra mint the authorization code and, on exchange, the tokens.

That split is the whole design. The README states that Hydra gives you absolute control over the user interface and experience flows. The cost is that you must build the endpoints Hydra redirects to. The OpenID certification section of the README notes that certification was obtained by deploying the reference user login and consent app unmodified alongside Ory Hydra v1.0.0, so a working reference implementation exists to copy from.

Around that core, the repository carries the pieces you would expect from a token server: a jwk directory for key material, an aead directory for encryption primitives, a persistence directory for storage backends, and an hsm directory that pairs with the ThalesGroup/crypto11 and miekg/pkcs11 dependencies in go.mod for hardware security module key storage. Token revocation and introspection are implemented per RFC 7009 and RFC 7662, and dynamic client registration per RFC 7591 and RFC 7592, all listed in the README's standards section.

Installing Ory Hydra and pointing it at a login and consent app

The repository ships an install.sh at the top level, and the README's Quickstart section points to the Ory Hydra introduction docs for the full walkthrough. The README's deployment section frames self-hosting as one of the two ways to run Hydra, alongside the managed Ory Network. The Makefile shows how the project itself brings up dependencies for testing, which is a reasonable way to see what a working setup needs.

The Makefile's test-resetdb target removes any previous test containers and starts fresh ones. Note the port mappings: MySQL on 3444, PostgreSQL on 3445, CockroachDB on a third port.

docker rm --force --volumes hydra_test_database_mysql || true
docker rm --force --volumes hydra_test_database_postgres || true
docker rm --force --volumes hydra_test_database_cockroach || true
docker run --rm --name hydra_test_database_mysql  -p 3444:3306 -e MYSQL_ROOT_PASSWORD=secret -d mysql:8.0
docker run --rm --name hydra_test_database_postgres -p 3445:5432 -e POSTGRES_PASSWORD=secret -e POSTGRES_DB=postgres -d postgres:16

Building from source follows the Makefile's own dependency chain. The golangci-lint target fetches a pinned linter version into .bin, and the node_modules target installs the JavaScript tooling used for the Cypress test suite.

make lint
make test

The test target resets the databases, sources scripts/test-env.sh and runs go test with a 20 minute timeout, then removes the three database containers. That sequence is the closest thing in the repository to a documented end-to-end run. For a production deployment you also need the login and consent app reachable from Hydra; until it is, an authorization request redirects the browser to a URL that answers nothing, which is the most common first-run confusion with this project.

Where Ory Hydra is the wrong tool

The absence of user management is a feature until it is a gap. If your requirement is a login page, password storage, email verification, account recovery or social sign-in out of the box, Hydra supplies none of it, and the README is explicit that it connects to an existing identity provider instead. Teams that pick Hydra expecting a turnkey identity server routinely end up writing the login and consent application themselves, which is real engineering work, not configuration.

The second constraint is operational. Hydra is stateful: it persists clients, consent records and tokens in a database, and it holds signing keys. The persistence and jwk directories exist because those are first-class concerns. Running it means running a database with a migration story. The repository includes UPGRADE.md, which is the file to read before moving between major versions, and the version numbering in the release list (v2.3.0, then v25.4.0, then v26.2.0) shows the project has changed its scheme, so upgrade notes are not optional reading.

Third, the README's telemetry section exists because Hydra reports usage data by default. That is a deployment decision you have to make explicitly rather than inherit.

Finally, if your only need is signing JWTs for internal service-to-service calls with a fixed set of callers, a full OAuth2 authorization server with consent screens and dynamic client registration is more machinery than the problem requires.

Ory Hydra compared with a bundled identity server or an embedded library

The obvious alternative is a bundled identity and access management server such as Keycloak, which combines the user store, the admin console and the OAuth2 and OIDC provider in one deployment. The difference in approach is where identity lives. Keycloak owns your users and gives you a UI to manage them. Hydra refuses to own them and gives you an API. If you already have users in an application database and no appetite for synchronising them into a second system, Hydra's split is the reason to choose it. If you have no user store and want one, Keycloak or Ory's own Kratos plus Hydra combination removes work rather than adding it.

The second alternative is embedding an OAuth2 library directly into your application. The repository itself contains a fosite directory, and the README's ecosystem section links to the wider Ory stack: Kratos for identity management, Oathkeeper as an identity and access proxy, and Keto for access control policies. Building on fosite gives you the protocol logic as a Go library and lets you keep everything in one process, at the cost of implementing the operational surface (key rotation, persistence, admin endpoints) yourself. Hydra is the packaged version of that work.

The README also notes that Ory OAuth2 and OpenID Connect on the Ory Network is powered by the open source Hydra server and is API compatible. That gives you a migration path in either direction without changing client code, which is unusual and worth knowing before you commit to self-hosting.

Licence, maintenance and upgrade cost

The repository is licensed Apache-2.0, which permits commercial use, modification and redistribution provided you preserve the licence and notices. The README mentions a self-hosted deployment with or without the Ory Enterprise License, so some capabilities sit outside the open source build; the README does not enumerate which ones, and you should check the docs before assuming a feature is available in the Apache-2.0 edition. This is a description of the licence terms, not legal advice.

On maintenance: the repository is not archived, and the last push was on 2026-07-29. The most recent release listed is v26.2.0 from 2026-03-20, following v25.4.0 in November 2025 and v2.3.0 in January 2025. The gap between v2.3.0 and v25.4.0 reflects the versioning change mentioned earlier, so an upgrade from a v2.x deployment crosses that boundary.

The upgrade cost is dominated by two things: database migrations and the login and consent contract. Because Hydra stores clients and consent in your database, a major version bump is a migration you schedule. Because your application implements the login and consent endpoints, any change to that contract touches your code. UPGRADE.md is the file that tells you which releases require what, and it should be read before pinning a new tag.

Editorial conclusion

Adopt Ory Hydra if you already run an identity store and need a certified OpenID Provider that leaves the login and consent screens entirely to you. Do not adopt it if you want a system that registers users, stores passwords or ships a ready-made login page, because the README states Hydra is a standalone OAuth 2.0 and OpenID Connect server without user management. Before committing, verify which database you will run against, since the Makefile's test targets exercise MySQL, PostgreSQL and CockroachDB, and read UPGRADE.md for the migration path from your current release.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. ory/hydra on GitHub
3. Project website
4. README
5. Releases