
Show HN: Hydra – Open-Source OAuth2 Server - vwpolo3
https://gethydra.sh/hydra-1.0-stable-release
======
Ken_Adler
In my research, Hydra is the only OSS OIDC server implementation that is built
from the start in a modern, containerized manner.

~~~
manigandham
[https://identityserver.io/](https://identityserver.io/)

[https://fusionauth.io/](https://fusionauth.io/)

[https://www.keycloak.org/](https://www.keycloak.org/)

[https://www.gluu.org/](https://www.gluu.org/)

Basically all of them can run in a container, it's just hosting a few
endpoints and generating tokens. The complexity is in the protocols and not
the app. Some of them offer a user database as well and might require a SQL DB
connection.

~~~
unscaled
The difference is probably between "can be made to run in a container" (which
is true for almost every app) and "designed from day 1 to be containerized" \-
which is obviously not true for solutions like Keycloak.

That being said, I'm not quite sure to which feature OP was referring in
particular. Perhaps to the modular approach taken by Hydra when compared to
Keycloak. Hydra has a much smaller scope than Keycloak, so it would be really
hard to compare them. Keycloak does identity management, consent, access
control and a lot of UI.

Hydra is not even a self-contained identity provider - it's basically just the
shell of an OpenID Connect provider that provides tokens, sessions and
security (hopefully avoiding implementing OIDC correctly yourself, which could
be very tricky as the spec is downright massive). You have to provide in turn
separate services which take care of login and consent.

I don't think Hydra is the only Open ID Connect implementation which follows
this model of breaking down the IdP. Dex is another shell IdP that does that,
and also built from the grounds up to be containerized (being started by
CoreOS and all). The main difference is that is that Dex provides a more easy
to use set of built-in connectors to popular identity management systems (and
other identity provider protocols, such as SAML or even another OIDC
provider). It's not as extensible and flexible as the Hydra model, but
probably easier to use if you just want to quickly provide OIDC on top of an
existing LDAP.

~~~
segmondy
Ugh, I run Keycloak in a cluster of containers. Didn't have a bespoke
solution, used Redhat's solution.

------
quelltext
I'm not too familiar with this space, so please excuse my question. What is
OAuth2 server is?

I was under the impression that for a given service/API typically OAuth2 is
implemented by the provider on their servers, either from scratch or using
some sort of library.

With an OAuth2 server are you running a separate server or is it an internal
service that your application code connects to (and forwards requests?) when
OAuth related requests come in?

A diagram of how an OAuth2 server fits into an application architecture and a
visualization of an OAuth flow in it would greatly help here.

~~~
manigandham
Authentication = who are you. Authorization = what are you allowed to do.

OAuth 1.0/2.0 are a set of protocols and standards allowing applications to
identify users and get access to their data using existing profiles. OAuth is
mostly focused around authorization with claims (which are just key-value
pairs) and authentication was an afterthought.

OpenID is another standard designed to let people authenticate across the web,
launched with a lot of hype in the early web 2.0 days but never took off.
OpenID Connect (OIDC) is a new standard based on OAuth 2 + OpenID to provide
both authentication and authorization in a single flow.

OIDC/OAuth is all based on tokens, which are usually JWTs containing a bunch
of claims that can be validated against the server that issued them. There are
ID tokens (for the user info) and Access tokens (for accessing an API on
behalf of that user), but some services like social logins don't provide any
access tokens. Other providers might have rate limits, or dont have fine-
grained permissions, or you maybe you have completely internal APIs that you
need tokens for.

A token/identity server like Hydra can take care of creating and managing all
the tokens and grants, and all the OAuth token flows, in a central location
between internal and external APIs and user providers.

It's really just a webapp with endpoints that implement all the protocols so
you can run it as a service somewhere. Once you do, your apps can then just
call the token endpoint to recognize users and your APIs can use it to
validate incoming requests which have JWTs. You still need the logic in your
code to use OIDC sign-in and/or JWT validation but this is standard
functionality and easily available in every stack.

~~~
quelltext
Thanks for taking the time to write this up.

------
manigandham
The Ory suite is missing the user database component. Is this still on the
roadmap? The Hive project looks empty:
[https://github.com/ory/hive](https://github.com/ory/hive)

~~~
vwpolo3
Yes, not only on a roadmap but in high priority and under active development
(not in the public eye yet)

~~~
KitDuncan
Very exciting. Definitely will give it a try then!

------
jolmg
I wonder how many open source projects use this name. There's also Hydra[1], a
Nix-based continuous build system.

[1] [https://nixos.org/hydra/](https://nixos.org/hydra/)

~~~
flowcont
There is also the Hydra[1] parallel Scala compiler.

[1] [https://www.triplequote.com/hydra/](https://www.triplequote.com/hydra/)

~~~
sattoshi
My first thought was THC Hydra [1]

[1] [https://sectools.org/tool/hydra/](https://sectools.org/tool/hydra/)

~~~
gravypod
My first thought was NZB Hydra 2 [0]

[0]
[https://github.com/theotherp/nzbhydra2](https://github.com/theotherp/nzbhydra2)

~~~
anamexis
My first thought was the thread executor of Typhoeus [0]

[0]
[https://github.com/typhoeus/typhoeus](https://github.com/typhoeus/typhoeus)

------
webhamster
Does Hydra follow the OAuth Security BCP ([https://tools.ietf.org/html/draft-
ietf-oauth-security-topics...](https://tools.ietf.org/html/draft-ietf-oauth-
security-topics-12))? I do not see PKCE or mix-up mitigation mentioned, for
example.

~~~
vwpolo3
While not explicitly mentioned, PKCE is supported! And yes, that draft was an
important guide during implementation.

~~~
unscaled
How do you deal with IdP/AS mix-up?

The BCP recommends either sending back client_id and iss (but that draft[1] is
long expired, and nobody seems to support that implementation), or asking the
client to provider a separate exact-match return URI for each AS. The second
solution is what I'm doing when implementing multi-AS/IdP OAuth clients, but
this requires the clients to be aware of this vulnerability, and that's a
rather tall requirement.

[1] [https://tools.ietf.org/html/draft-ietf-oauth-mix-up-
mitigati...](https://tools.ietf.org/html/draft-ietf-oauth-mix-up-
mitigation-01)

~~~
webhamster
There is no issuer in OAuth. Therefore, the distinct-redirect-URI solution is
the most universal.

------
cookiecaper
I was just researching OAuth servers last week and came across Hydra several
times. Congrats all on a big release!

Ran across some unexpected drama while poking around: apparently, one of the
main authors of OAuth2 spec withdrew his name from the publication and has
repeatedly publicly derided the standard.
[https://vimeo.com/52882780](https://vimeo.com/52882780). Parts I heard were
good.

I'd just like to make a small request that developers on tiny internal-only
APIs not make a big ordeal out of OAuth and require a big honking session
store anchored against the "user's" OAuth creds on every _internal_ ,
_service-to-service_ request, thanks.

~~~
vwpolo3
The blog posts and discussion was long ago (the video is 6 years old). Since
then, that particular author acknowledged that (iirc) OpenID Connect solves
many of the things he criticized. I have to look up the source, it’s been a
while.

However, OIDC and OAuth2 are complex protocols which is also why we encourage
most greenfield and small projects to avoid it unless explicitly required.

It’s also important to note that that particular person voiced criticism, but
most of the biggest names in tech (GCP, AWS, ...) heavily rely on those
protocols (+ extensions). His proposed alternative protocol Oz never got to
real world adoption (to my knowledge) and has recently been archived. The
prediction that we would see major OAuth2 security wholes within 3 years (so
2015j never came true. It doesn’t mean that he was wrong, but that there are
opinions that contradict him, and that those opinions and voices have
established themselves in the industry.

~~~
webhamster
Also, we now have formal proofs for the security of the OAuth and OIDC
protocols.

------
asjo
A looong time ago, when OpenID was sort-of new, I implemented my own OpenID
provider, because I wanted to log into StackOverflow and other places, but I
didn't want to use a third party service.

That worked swimmingly in the few places that supported OpenID, but eventually
even StackOverflow dropped support.

I must admit I haven't kept up with what has happened since in this area, so
stupid question:

Could I install this server and have my own OAuth2/OIDC provider that would
allow me to login to websites using my own provider (instead of "Login with
Microsoft Github", "Login with Facebook", "Login with Google", "Login with
Twitter"), or is this something else/the reverse?

~~~
manigandham
No, OIDC providers can only be accessed by registered clients so those sites
cant use your provider unless they specifically add it. Otherwise you would be
able to login with any of those accounts on any site already.

~~~
asjo
Ok, so there really isn't anything like OpenID any more?

~~~
manigandham
OpenID still required sites to implement that standard as a relying party so
it couldn't be used arbitrarily. It gave you the ability to choose a specific
OpenID identity provider to store your account info (including your own), but
it didnt get adoption so now it's obsolete.

OpenID Connect is the latest version of OpenID, and it uses OAuth to federate
access to other identity providers but sites now have to implement a separate
registration for each provider (google, facebook, etc) so what they choose to
implement is what you get, and there's no realistic option to use your own.

~~~
asjo
Thanks, the TL;DR is "Yes" then. Too bad.

------
praseodym
How does Hydra compare to other OIDC server implementations like Dex and
Keycloak?

~~~
vwpolo3
It leaves the implementation of the login (enter /password, ...) and consent
(may application X have access to your pictures?) flows up to the developers
using HTTP Redirection flows. You can therefore integrate it much easier in
existing applications.

Also, you have complete control over the ui and user experience and must not
learn a template language (Keycloak) or fork (Dex) the project to customize
it.

Compared to Keycloak, Hydra is much more lightweight (no JVM/JBoss). However,
you need to implement the user database yourself and/or write your own
connector for it.

~~~
atonse
If we have to implement all those things, is there really much of a remaining
lift in implementing OIDC, apart from bringing in a library into a web app?

~~~
vwpolo3
Yes, implementing both OAuth2 as well as OIDC according to spec is a
significant development effort and countless teams and companies fail at
pushing through, shipping incomplete or insecure implementations. If you’re
greenfield, OAuth2/OIDC is with 99% certainty not the right fit for you
anyways.

~~~
manigandham
Bringing in a library is different from building it from scratch. Pretty much
every language has solid OIDC frameworks now.

OIDC is great for greenfield and much better than writing user signin flow
every time.

~~~
vwpolo3
Username + Password with a cookie store is much better understood and harder
to get wrong than implementing a full OIDC suite (server + client). If you're
talking federated login, that's what OIDC is for. If you're talking "login",
your opinion is misguided.

~~~
manigandham
We might not be talking about the same thing. The thread was comparing to
other OAuth servers, and then libraries, but nobody is talking about
implementing it from scratch.

That being said, if you're working on a greenfield app where you need auth,
using an OAuth/OIDC server is much better and faster than creating yet another
membership system for that app. That's a major advantage of identity
federation.

------
zild3d
Site doesn't seem to give a simple high level explanation. How does this
compare to a service like auth0? Seems like a subset of a cognito/auth0/okta?

------
argd678
Are there any load test reports? How well does it scale?

------
RocketSyntax
Glad to see OpenAPI codegen being used for the SDKs!

