Ory Hydra 1.9: Open-source Golang OAuth2 provider
github.com
github.com
I started the project Ory Hydra back in 2015 as a side project, and it has now become a full time job with a dedicated team! Ory Hydra is used at a lot of companies and we have since started with some other projects such as ORY Kratos (https://github.com/ory/kratos).
If you have any questions regarding Hydra, Ory, Golang, or open source - I am more than happy to answer!
edit:// Signing off - if you have any questions for maintainers feel free to check out the ory slack channel or ask on the GitHub discussions board!
1. When would you use hydra as opposed to embedding auth flows yourself (with i.e. ory/fosite)?
2. Any idea when Kratos will 1.0?
1. Almost never - it's a lot of work to get from a library to a server that has a strong persistence layer, is scalable, has all the management around it (e.g. write and create clients). Also, upgrading a server is much easier than upgrading a library! 2. We plan to have ORY Kratos v0.6 out of alpha (what we call sandbox) and in "incubating" status. That means that we feel confident that APIs won't change as much an more but there is still risk that you have to deal with some breaking changes. For version 1.0 it is probably going to land in 2022, as we usually stay 1 year in sandbox, 1 year in incubating and if everything has stabilized go to stable. Having said that, you can still use this stuff in prod. For us, alpha/sandbox just means: "Careful, there will be breaking changes!". But we never release insecure, untested or half-baked stuff.
Also I have to say that about a year ago I wanted to teach myself about OAuth and I find almost every online guide and book to be terrible (and usually trying to sell me something). Two things finally put it all together for me: reading the OIDC spec and reading the Hydra & Kratos code and docs.
Thank you!!
> Also I have to say that about a year ago I wanted to teach myself about OAuth and I find almost every online guide and book to be terrible (and usually trying to sell me something). Two things finally put it all together for me: reading the OIDC spec and reading the Hydra & Kratos code and docs.
Awesome! I was in the exact same boat. Usually OAuth2 is a marketing thing for companies that are closed source, because it is the only "open" thing they can offer. Then they bend the protocol to fit the actual use case - which is sign in, registration, and so on. OAuth2 was never intended to be a protocol for "login". It's a protocol for Developer X to get access to your Facebook Fotos.
My personal goal with Ory is to educate people around security (good security is easy, not hard) and clean up the misconceptions. I hope this helps the developer ecosystem become more secure and better educated as a whole!
I dug into this space recently and Keycloak is really the best, most full-featured (open source) solution at the moment. But it's a hefty and can be difficult to work with at times (documentation can be lacking and confusing, customizations difficult). It doesn't seem to jive well with a modern containerized stack, either.
Ory and Supertokens are the two open source projects that I've been keeping an eye on and I think are making great progress and will be real viable alternatives to Keycloak soon. Last I checked they weren't _quite_ ready for real production usage (for various reasons, I'll have to revisit my notes), but they both seem to be moving quickly so looking forward to trying them again soon.
Yes, in terms of features, we're working quickly to add functionality while being cognizant of maintaining simplicity. If you have any questions or feedback, please reach out (advait at supertokens dot io)
* Harder to evaluate quickly locally
* Documentation split across multiple services
* Was looking for a more turnkey solution instead of having to assemble and configure multiple parts
* Red Hat as a user
I dont mind Keycloak's monolithic architecture at all so far
Ory does look interesting but I would recommend to market this as a suite, not the sum of its parts
From experience, can anyone make a recommendation for a system that can be rolled out to an organization with confidence (long-term support, security, performance)?
- Login, registration, mfa, user management, password change, account recovery, ... - Ory Kratos: http://github.com/ory/kratos
- Permission management, roles, who is allowed to do what - Ory Keto: http://github.com/ory/keto
- OAuth2, OpenID Connect Provider that you "connect" to your user management (e.g. Ory Kratos) - Ory Hydra: http://github.com/ory/hydra
- A "middleware" which checks if requests are authenticated (who is the caller?) and authorized (is the caller allowed to do that) - Ory Oathkeeper: http://github.com/ory/oathkeeper
It's a bit like lego where the other projects are more like the full car you buy. The car might use little fuel but it's slow and you can't change that. The lego parts you can combine any way you want.
Plus, Ory is written in Go and we aim for supporting planet-scale distributed data stores to support global deployments with low latency, and other cool stuff!
The last point, we are actually building out a cloud service (think CockroachCloud without the licensing issues), which means that you don't buy a support contract from IBM but instead get everything with a few clicks! Kinda like Auth0, Okta, or Firebase - but with everything open source (maybe like sentry.io?)
How stable is Ory? How often will breaking changes occur during the next months/years? Can you provide an ETA for the cloud service?
So basically Ory Hydra is the most stable and we did not have any big breaking changes (maybe a CLI command arg renamed) in the last 2 years iirc.
Cloud service is planned for a private beta in Q1 2021 (lmk if you are interested). Public release probably end of 2021 I think!
Hydra API is smaller and easier to use than the one from Keycloak. Because of how lightweight Hydra is, it is possible to spin it up in integration tests with docker using something like Ory dockertest.
What the Ory stack is missing is an implemetation of UMA2 and there is no out of the box support for LDAP auth and SAML federation. However, the way Hydra handles accepting an identity from an external authentication source via its admin API makes it fairly easy to add any auth mechanism, not limited to how it would be in Keycloak because of the Keycloak SPI design choices. Implementing the user federation SPI for Keycloak is actually pretty tricky.
What speaks for Keycloak is the completness: user and role management, permissions, resource servers and so on. However, if one wants just tokens and does not mind writing the glue code to Kratos and Keto, Ory stack is awesome. There is Oathkeeper serving as that glue layer and a sort of reverse proxy to all 3 of the components but it doesn’t always fulfil all requirements.
I will agree that the SPI interfaces for Keycloak could be better, but especially with the new Quarkus distribution it’s stupidly easy to setup and has 99% of what you need out of the box.
Yes, I know. I use Keycloak in production. All realms sit on one instance. As do all clients. It can get really heavy and really slow really fast, especially with resource servers. I am aware of replication but that is basically replicating the whole instance.
The other not so nice thing about the SPI is that custom providers are loaded into the main Java process and that comes with all the pitfalls of class loading, shading, uber jars. It’s a mess. Try building a log adapter to push data to Kafka or over grpc. Dragons.
Keycloak is nice for out of the box stuff but integration can get pretty messy.
We didn't use the other Ory offerings, instead opting to create our own user management and permissions suite. We already had LDAP as a competing source of truth, so this colored the picture. In 2021, I'd probably advocate for buying all-in to Ory tools.
If you're a shop that employs capable engineers, Ory is a strong recommendation. If you want something with a wide product surface area, you might want to look elsewhere.
To make a doubtlessly crude analogy, Hydra is kind of like the Kubernetes to the other options' OpenShift.
https://github.com/oauth2-proxy/oauth2-proxy
It allows me to put different services behind oauth-logins, with confidence. Not too heavyweight or complex, and has a decent history of good support.
I had a hacky simplesamlphp instance that work well but no OAUTH :/
So that was definitely not my experience.
One time when I needed more consulting for a greenfield project, my company paid for one hour with him which was well spent as well.
I don't see how you can be productive and giving support for free with such a small team at the same time.
* I am not affiliated / not a paying customer. Just a happy user of the open source version.
Keycloak won’t have a similar issue, it’s already the upstream project for Red Hat SSO.
If John criticizes Heinz in the usual english "irrelevant positive, important negative, irrelevant positive" structure, Heinz's takeaway will be "mostly positive with minor problems". All the while John meant the negative to be a major problem and just wanted to cushion the blow. If Heinz wants to convey criticism, he will give you just the negative, nothing else. Whatever isn't mentioned is OK. John will understand this as devastating criticism, because absolutely nothing positive was mentioned. But actually Heinz liked everything and just has this minor nit to pick... If Heinz likes everything he'll say "it's fine". John might be wondering why he didn't mention anything Heinz liked explicitly and if this is Heinz being passive aggressive.
There is a lot more to it, and of course there are nuances to it, e.g. Heinz might come from various German regions that differ in their usual behaviour and may even seem overly rude or overly friendly to other Germans.
I think calling open source "greedy" is an antithesis and a sentiment that if repeated enough burns out the best maintainers. They do not work for the software's adopters and it is their fair right to ask for money if they spend time on doing work that only benefits others.
I recommend reading a bit about open source and expectation management: https://mikemcquaid.com/2018/03/19/open-source-maintainers-o...
In any case, it is unfortunate that the interaction did not meet your expectations. Keycloak is a great project, with a great community, and if it solves your needs you have made the correct choice!