Hacker News new | comments | show | ask | jobs | submitlogin
Ory Hydra 1.9: Open-source Golang OAuth2 provider (github.com)
137 points by vinckr 8 days ago | hide | past | web | 33 comments | favorite

Hi HN community, maintainer here (http://github.com/aeneasr)!

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!

Thank you so much for your work on Ory suite. The documentation is top notch and I love the 12-factor principles. Two questions:

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?

Thank you, appreciate it a lot! Regarding your questions:

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.

What was your mentality around choosing the license (Apache) in regards to the business you hope(d) to build around the Ory offerings?

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!!

Thank you for the question! There are not many licenses to choose from that people accept. For example GPL and AGPL are generally frowned upon. I think Apache 2.0 offers the greatest freedom, while being more nuanced than MIT. It helps with borad community contribution and adoption which was the initial goal (never intended for this to become a business, it just so happened).

> 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!

Thank you. OAuth is hard. Your code makes a big difference in the lives of some of us.

I'm working on a Keycloak deployment and also had a look at Ory What pushed me away from it:

* 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

Congrats on the latest release! I'm really excited to see this space getting a lot of attention and traction lately. I think it's one of those things that basically every app has to "reinvent" to some extent, and I would love to just be able to spin up a container that handles a lot of this stuff. Especially considering the security implications.

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.

I am the cofounder of SuperTokens. Thank you for the shoutout.

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)

How does Ory compare to alternatives like e.g. Keycloak and Authelia?

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)?

Keycloak and Authelia try to solve everything at once. So you get user management, but you also need to use their template and plugin system (so Java for Keycloak) and you can't use a different OAuth2 provider because well - you use Keycloak. I really love the projects and they have their use cases - with Ory however, you simply pick what you need:

- 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?)

Thank you for the explanations and your hard work!

How stable is Ory? How often will breaking changes occur during the next months/years? Can you provide an ETA for the cloud service?

Any time! You can learn more about software maturity here: https://www.ory.sh/docs/ecosystem/versioning

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!

We've been using Hydra as part of our single-sign-on stack for almost 3 years now. It's something that most application developers have no idea exists. I'd say it's been very successful.

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.

Keycloak is much heavier than Hydra. With Hydra, it is much easier to spin up thin OpenID clients. If one has a need to spin up dozens or hundreds of OpenID clients, Hydra will be definitely a better choice purely because one can have multiple Hydra servers running with only a handful of clients each. Think multi tenant environments. With Hydra, there is no reason not to have many Hydra instances with as low as a single OpenID client.

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.

Keycloak supports multi-tenancy natively with realms. There is a fixed memory cost for each, but it’s not like you have to spin up an entirely new instance for each.

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.

> Keycloak supports multi-tenancy natively with realms. There is a fixed memory cost for each, but it’s not like you have to spin up an entirely new instance for each.

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.

I currently use Keycloak with vouch-proxy[0] to secure services on my personal self-hosting server. It seems to be quite slow, and much more heavyweight and complex than I need . Is this something Ory can solve for me? Is there any documentation similar to this situation?

[0] https://github.com/vouch/vouch-proxy

Of course! There is probably some work involved because every system works a bit differently. I have never really worked with Keycloak and also never with vouch-proxy, so I can't state any definitive answers, but asking on our slack or the GitHub discussion forums could help. And then of course, the docs :)

This. I find keycloak to heavy. Though I have yet to find something as good that does LDAP, Kerberos and x509 all together.

I had a hacky simplesamlphp instance that work well but no OAUTH :/

For a similar use-case I found the oauth-proxy a decent standalone solution:


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.

Oh and you can downvote me all you like. It only confirms that you're an asshole. So fuck you too

I don't like the ae... guy there. Some arrogant German youngster. When I asked him a question about a workflow he told me that there's commercial support. Yeah screw you too. Mostly happy with keycloak, don't need no hydra and greedy pseudo open source disguised payware

Keep in mind that maintainers of large projects are often burned or stressed out. On top of that, the "German" guy's first language is probably not English, it's German. You can't expect for every non-native speaker to always hit the "right" tone not because they are rude, but because they translate it from another language.

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!

"the guy" is usually very helpful in the community forum. He has also answered my questions a couple of times in the chat as well even though he has probably heard then 100 times already.

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.

His responses sometimes come across as abrasive, but he means no offcence I believe. Maybe it's a cultural, German, thing, don't know. Don't give up, just continue calm and polite discussion and conversation will go back to the right track.

Yes, my cultural sensitivity training and experience says Germans (let's call him Heinz) are abrasive to Brits and Americans (John). Germans are very direct and mean what they say far more literally than John. Indirect questions and suggestions, that might sound like a very straightforward thing to you are nothing Heinz will understand. John: "Should we talk about this some more?" G: "No, I don't think that is necessary". If John takes up the topic again, Heinz will be annoyed with him, because John asked for his decision, heard his decision and ignored it.

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.

That's very interesting observation and well put summary. Do you have similar insights about other nations? :)

Not really, my language skills are not sufficient beyond German and English.

I use Hydra and have had nothing but good experiences when asking questions.

Let's hope Red Hat doesn't pull the rug from under Keycloak, like they did not so long ago with CentOS.

Ever since the acquisition CentOS has been the odd one out with Red Hat’s open source strategy - being downstream from the commercial product.

Keycloak won’t have a similar issue, it’s already the upstream project for Red Hat SSO.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact