[HN Gopher] Ory Hydra 1.9: Open-source Golang OAuth2 provider
___________________________________________________________________
Ory Hydra 1.9: Open-source Golang OAuth2 provider
Author : vinckr
Score : 102 points
Date : 2021-01-13 15:08 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| lukeramsden wrote:
| 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
| stevekemp wrote:
| For a similar use-case I found the oauth-proxy a decent
| standalone solution:
|
| 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.
| amaccuish wrote:
| 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 :/
| _hackerman wrote:
| 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 :)
| joekrill wrote:
| 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.
| _hackerman wrote:
| 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!
| mauflows wrote:
| 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?
| _hackerman wrote:
| 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.
| skrtskrt wrote:
| 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!!
| _hackerman wrote:
| 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!
| [deleted]
| dalu wrote:
| 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
| rad_gruchalski wrote:
| Let's hope Red Hat doesn't pull the rug from under Keycloak,
| like they did not so long ago with CentOS.
| _hackerman wrote:
| 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 a telling sentiment
| that burns out the best maintainers. They do not work for you
| and it is their fair right to ask for money if they spend time
| on doing work for you that only benefits you and noone else. It
| is even justified to ask for support if they work on features
| that benefit everybody! I recommend reading a bit about open
| source and expectation management:
| https://mikemcquaid.com/2018/03/19/open-source-maintainers-o...
|
| You probably get paid to do your job, so why should people
| dedicating their lifetime to solve your problems with open
| source software not get the same treatment?
| mderazon wrote:
| "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.
| rossmohax wrote:
| 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.
| dang wrote:
| If curious see also
|
| 2016 https://news.ycombinator.com/item?id=12789720
|
| 2016 https://news.ycombinator.com/item?id=11798045
| bauerd wrote:
| 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
| ralala wrote:
| 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)?
| gen220 wrote:
| 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.
| _hackerman wrote:
| 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?)
| ralala wrote:
| 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?
| _hackerman wrote:
| 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!
| rad_gruchalski wrote:
| 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.
___________________________________________________________________
(page generated 2021-01-13 23:01 UTC)