Hydra is being developed by german-based company Ory. Join our newsletter to stay on top of new developments.
We respond on Google Groups and Gitter. Our timezone is CET.
Hydra uses the security first OAuth2 and OpenID Connect SDK Fosite and Ladon for policy-based access control.
🔥 Don't want to worry about security updates, backups, migration and scaling? Do you need enterprise support? Become an managed Hydra early adopter! Contact us now for more information. 🔥
Table of Contents
At first, there was the monolith. The monolith worked well with the bespoke authentication module. Then, the web evolved into an elastic cloud that serves thousands of different user agents in every part of the world.
Hydra is driven by the need for a scalable, low-latency, in memory Access Control, OAuth2, and OpenID Connect layer that integrates with every identity provider you can imagine.
Hydra is available through Docker and relies on RethinkDB for persistence. Database drivers are extensible, in case you want to use RabbitMQ, MySQL, MongoDB, or some other database instead.
- Availability: Hydra uses pub/sub to have the latest data available in memory. The in-memory architecture allows for heavy duty workloads.
- Scalability: Hydra scales effortlessly on every platform you can imagine, including Heroku, Cloud Foundry, Docker, Google Container Engine and many more.
- Integration: Hydra wraps your existing stack like a blanket and keeps it safe. Hydra uses cryptographic tokens for authenticate users and request their consent, no APIs required. The deprecated php-3.0 authentication service your intern wrote? It works with that too, don't worry. We wrote an example with React to show you what this could look like: React.js Identity Provider Example App.
- Security: Hydra leverages the security first OAuth2 framework Fosite, encrypts important data at rest, and supports HTTP over TLS (https) out of the box.
- Ease of use: Developers and Operators are human. Therefore, Hydra is easy to install and manage. Hydra does not care if you use React, Angular, or Cocoa for your user interface. To support you even further, there are APIs available for cryptographic key management, social log on, policy based access control, policy management, and two factor authentication (tbd) Hydra is packaged using Docker.
- Open Source: Hydra is licensed Apache Version 2.0
- Professional: Hydra implements peer reviewed open standards published by The Internet Engineering Task Force (IETF®) and the OpenID Foundation and under supervision of the LMU Teaching and Research Unit Programming and Modelling Languages. No funny business.
- Real Time: Operation is a lot easier with real time monitoring. Because Hydra leverages RethinkDB, you get real time monitoring for free:
OAuth2 and OpenID Connect are tricky to understand. It is important to understand that OAuth2 is a delegation protocol. It makes sense to use Hydra in new and existing projects. A use case covering an existing project explains how one would use Hydra in a new one as well. So let's look at a use case!
Let's assume we are running a ToDo List App (todo24.com). ToDo24 has a login endpoint (todo24.com/login). The login endpoint written in node and uses MongoDB to store user information (email + password + settings). Of course, todo24 has other services as well: list management (todo24.com/lists/manage: close, create, move), item management (todo24.com/lists/items/manage: mark solved, add), and so on. You are using cookies to see which user is doing the request.
Now you decide to use OAuth2 on top of your current infrastructure. Reasons could be:
- You want to open up your APIs to third-party developers. Their apps will be using OAuth2 Access Tokens to access a user's to do list.
- You want a mobile client. Because you can not store secrets on devices (they can be reverse engineered and stolen), you use OAuth2 Access Tokens instead.
- You have Cross Origin Requests. Making cookies work with Cross Origin Requests weakens or even disables important anti-CSRF measures.
- You want to write an in-browser client. This is the same case as in a mobile client (you can't store secrets in a browser).
These are only a couple of reasons to use OAuth2. You might decide to use OAuth2 as your single source of authorization, thus maintaining only one authorization protocol and being able to open up to third party devs in no-time. With OpenID Connect, you are able to delegate authentication as well as authorization!
Your decision is final. You want to use OAuth2 and you want Hydra to do the job. You install Hydra in your cluster using docker. Next, you set up some exemplary OAuth2 clients. Clients can act on their own, but most of the times they need to access to a user's todo lists. To do so, the client initiates an OAuth2 request. This is where Hydra's authentication flow comes in to play. Before Hydra can issue an access token, we needs to know WHICH user is giving consent. To do so, Hydra redirects the user agent (e.g. browser, mobile device) to the login endpoint alongside with a challenge that contains an expiry time and other information. The login endpoint (todo24.com/login) authenticates the user as usual, e.g. by username & password, session cookie or other means. Upon successful authentication, the login endpoint asks for the user's consent: "Do you want to grant MyCoolAnalyticsApp read & write access to all your todo lists? [Yes] [No]". Once the user clicked Yes and gave consent), the login endpoint redirects back to hydra and appends something called a consent token. The consent token is a cryptographically signed string that contains information about the user, specifically the user's unique id. Hydra validates the signature's trustworthiness and issues an OAuth2 access token and optionally a refresh or open id token.
Every time a request containing an access token hits a resource server (todo24.com/lists/manage), you make a request to Hydra asking who the token's subject (the user who authorized the client to create a token on his behalf) is and weather or not the token is valid. You may optionally ask if the token has permission to perform a certain action.
Why should I use Hydra? It's not that hard to implement two OAuth2 endpoints and there are numerous SDKs out there!
OAuth2 and OAuth2 related specifications are over 200 written pages. Implementing OAuth2 is easy, getting it right is hard. Even if you use a secure SDK (there are numerous SDKs not secure by design in the wild), messing up the implementation is a real threat - no matter how good you or your team is. To err is human.
Let's take a look at security in Hydra:
- Hydra uses Fosite, a secure-by-design OAuth2 SDK. Fosite implements
best practices proposed by the IETF:
- No Cleartext Storage of Credentials
- Encryption of Credentials
- Use Short Expiration Time
- Limit Number of Usages or One-Time Usage
- Bind Token to Client id
- Automatic Revocation of Derived Tokens If Abuse Is Detected
- Binding of Refresh Token to "client_id"
- Refresh Token Rotation
- Revocation of Refresh Tokens
- Validate Pre-Registered "redirect_uri"
- Binding of Authorization "code" to "client_id"
- Binding of Authorization "code" to "redirect_uri"
- Opaque access tokens
- Opaque refresh tokens
- Ensure Confidentiality of Requests
- Use of Asymmetric Cryptography
- Enforcing random states: Without a random-looking state or OpenID Connect nonce the request will fail.
- Advanced Token Validation: Tokens are layouted as
<key>.<signature>where<signature>is created using HMAC-SHA256 and a global secret. This is what a token can look like:/tgBeUhWlAT8tM8Bhmnx+Amf8rOYOUhrDi3pGzmjP7c=.BiV/Yhma+5moTP46anxMT6cWW8gz5R5vpC9RbpwSDdM= - Enforcing scopes: By default, you always need to include the
corescope or Hydra will not execute the request.
- Hydra uses Ladon for policy management and access control. Ladon's API is minimalistic and well tested.
- Hydra encrypts symmetric and asymmetric keys at rest using AES-GCM 256bit.
- Hydra does not store tokens, only their signatures. An attacker gaining database access is neither able to steal tokens nor to issue new ones.
- Hydra has automated unit and integration tests.
- Hydra does not use hacks. We would rather rewrite the whole thing instead of introducing a hack.
- APIs are uniform, well documented and secured using the warden's access control infrastructure.
- Hydra is open source and can be reviewed by anyone.
- Hydra is designed by a security enthusiast, who has written and participated in numerous auth* projects.
Additionally to the claims above, Hydra has received a lot of positive feedback. Let's see what the community is saying:
Nice! Lowering barriers to the use of technologies like these is important.
OAuth is a framework not a protocol. The security it provides can vary greatly between implementations. Fosite (which is what this is based on) is a very good implementation from a security perspective: https://github.com/ory-am/fosite#a-word-on-security
[...] Thanks for releasing this by the way, looks really well engineered. [...]
This section is a quickstart guide to working with Hydra. In-depth docs are available as well:
Starting the host is easiest with docker. The host process handles HTTP requests and is backed by a database. Read how to install docker on Linux, OSX or Windows. Hydra is available on Docker Hub.
The easiest way to start docker is without a database. Hydra will keep all changes in memory. But be aware! Restarting, scaling or stopping the container will make you lose all data:
$ docker run -d -p 4444:4444 oryam/hydra --name my-hydra
ec91228cb105db315553499c81918258f52cee9636ea2a4821bdb8226872f54b
The CLI client is available at gobuild.io.
There is currently no installer which adds the CLI to your path automatically. You have to set up the path yourself. If you do not understand what that means, ask on our Gitter channel.
If you wish to compile the CLI yourself, you need to install and set up Go and add $GOPATH/bin
to your $PATH. Here is a comprehensive Go installation guide with screenshots.
To install the CLI from source, execute:
go get github.com/ory-am/hydra
go get github.com/Masterminds/glide
cd $GOPATH/src/github.com/ory-am/hydra
glide install
go install github.com/ory-am/hydra
hydra
Alternatively, you can use the CLI in Docker (not recommended):
$ docker exec -i -t <hydra-container-id> /bin/bash
# e.g. docker exec -i -t ec12 /bin/bash
root@ec91228cb105:/go/src/github.com/ory-am/hydra# hydra
Hydra is a twelve factor OAuth2 and OpenID Connect provider
Usage:
hydra [command]
[...]
Install the CLI and Docker Toolbox. Make sure you install Docker Compose. On OSX and Windows, open the Docker Quickstart Terminal. On Linux open any terminal.
We will use a dummy password as system secret: SYSTEM_SECRET=passwordtutorialpasswordtutorial. Use a very secure secret in production.
On OSX and Windows using the Docker Quickstart Terminal.
$ go get github.com/ory-am/hydra
$ cd $GOPATH/src/github.com/ory-am/hydra
$ DOCKER_IP=$(docker-machine ip default) docker-compose build
WARNING: The SYSTEM_SECRET variable is not set. Defaulting to a blank string.
rethinkdb uses an image, skipping
Building hydra
[...]
$ SYSTEM_SECRET=passwordtutorialpasswordtutorial DOCKER_IP=$(docker-machine ip default) docker-compose up
Starting hydra_rethinkdb_1
Recreating hydra_hydra_1
Recreating hydra_consent_1
Attaching to hydra_rethinkdb_1, hydra_hydra_1, hydra_consent_1
[...]
On Linux.
$ go get github.com/ory-am/hydra
$ cd $GOPATH/src/github.com/ory-am/hydra
$ DOCKER_IP=localhost docker-compose build
WARNING: The SYSTEM_SECRET variable is not set. Defaulting to a blank string.
rethinkdb uses an image, skipping
Building hydra
[...]
$ SYSTEM_SECRET=passwordtutorialpasswordtutorial DOCKER_IP=tutorialpassword docker-compose up
Starting hydra_rethinkdb_1
Recreating hydra_hydra_1
Recreating hydra_consent_1
Attaching to hydra_rethinkdb_1, hydra_hydra_1, hydra_consent_1
[...]
mhydra | mtime="2016-05-17T18:09:28Z" level=warning msg="Generated system secret: MnjFP5eLIr60h?hLI1h-!<4(TlWjAHX7"
[...]
mhydra | mtime="2016-05-17T18:09:29Z" level=warning msg="Temporary root client created."
mhydra | mtime="2016-05-17T18:09:29Z" level=warning msg="client_id: d9227bd5-5d47-4557-957d-2fd3bee11035"
mhydra | mtime="2016-05-17T18:09:29Z" level=warning msg="client_secret: ,IvxGt02uNjv1ur9"
[...]
You have now a running hydra docker container! Additionally, a RethinkDB image was deployed and a consent app.
Hydra can be managed with the hydra cli client. The client hast to log on before it is allowed to do anything.
When hydra detects a new installation, a new temporary root client is created. The client credentials are printed by
docker compose up:
mhydra | mtime="2016-05-17T18:09:29Z" level=warning msg="client_id: d9227bd5-5d47-4557-957d-2fd3bee11035"
mhydra | mtime="2016-05-17T18:09:29Z" level=warning msg="client_secret: ,IvxGt02uNjv1ur9"
The system secret is a global secret assigned to every hydra instance. It is used to encrypt data at rest. You can
set the system secret through the $SYSTEM_SECRET environment variable. When no secret is set, hydra generates one:
time="2016-05-15T14:56:34Z" level=warning msg="Generated system secret: (.UL_&77zy8/v9<sUsWLKxLwuld?.82B"
Important note: Please be aware that logging passwords should never be done on a production server. Either prune the logs, set the required parameters, or replace the credentials with other ones.
Now you know which credentials you need to use. Next, we log in.
Note: If you are using docker toolbox, please use the ip address provided by docker-machine ip default as cluster url host.
$ hydra connect
Cluster URL: https://localhost:4444
Client ID: d9227bd5-5d47-4557-957d-2fd3bee11035
Client Secret: ,IvxGt02uNjv1ur9
Done.
Great! You are now connected to Hydra and can start by creating a new client:
$ hydra clients create --skip-tls-verify
Warning: Skipping TLS Certificate Verification.
Client ID: c003830f-a090-4721-9463-92424270ce91
Client Secret: Z2pJ0>Tp7.ggn>EE&rhnOzdt1
Important note: Hydra is using self signed TLS certificates for HTTPS, if no certificate was provided. This should
never be done in production. To skip the TLS verification step on the client, provide the --skip-tls-verify flag.
Why not issue an access token for your client?
$ hydra token client --skip-tls-verify
Warning: Skipping TLS Certificate Verification.
JLbnRS9GQmzUBT4x7ESNw0kj2wc0ffbMwOv3QQZW4eI.qkP-IQXn6guoFew8TvaMFUD-SnAyT8GmWuqGi3wuWXg
Let's try this with the authorize code grant!
$ hydra token user --skip-tls-verify
Warning: Skipping TLS Certificate Verification.
If your browser does not open automatically, navigate to: https://192.168.99.100:4444/oauth2/auth?client_id=d9227bd5-5d47-4557-957d-2fd3bee11035&response_type=code&scope=core+hydra&state=sbnwdelqzxyedwtqinxnolbr&nonce=sffievieeesltbjkwxyhycyq
Setting up callback listener on http://localhost:4445/callback
Press ctrl + c on Linux / Windows or cmd + c on OSX to end the process.
Great! You installed hydra, connected the CLI, created a client and completed two authentication flows! Your next stop should be the Guide.
The Guide is available on GitBook.
The REST API is documented at Apiary.
The CLI help is verbose. To see it, run hydra -h or hydra [command] -h.
Unless you want to test Hydra against a database, developing with Hydra is as easy as:
go get github.com/ory-am/hydra
go get github.com/Masterminds/glide
cd $GOPATH/src/github.com/ory-am/hydra
glide install
go test ./...
go run main.go
If you want to run Hydra against RethinkDB, you can do so by using docker:
docker run --name some-rethink -d -p 8080:8080 -p 28015:28015 rethinkdb
# Linux
DATABASE_URL=rethinkdb://localhost:28015/hydra go run main.go
# Docker Terminal
DATABASE_URL=rethinkdb://$(docker-machine ip default):28015/hydra go run main.go
A list of extraordinary contributors and bug hunters.
- Alexander Widerberg (leetal) for implementing the prototype RethinkDB adapters.