Show HN: Run your own OAuth2/OpenID Connect provider | Hacker News Reader

Show HN: Run your own OAuth2/OpenID Connect provider

github.com

161 pointsaeneasr49 comments

If you're interested in this sort of thing, Doorkeeper[1] is a robust, open source OAuth 2 provider that's been around for about 5 years. We use it as a standalone app, and have many other node.js apps that sign in using it.

[1] https://github.com/doorkeeper-gem/doorkeeper

Thanks, however Doorkeeper is an SDK, right? With Hydra, you simply boot the docker image and are done.

If you're interested in OAuth2 frameworks, check out [fosite](https://github.com/ory-am/fosite), which is like Doorkeeper for Go.

Doorkeeper is closer to a full-package with customizable features, including a basic frontend. I'm not too familiar with hydra, but it seems Doorkeeper is best when you want to get the full OAuth app & user interface running (and customize later), whereas Hydra is best when you want to get a quick OAuth API app and build your own frontend. Would you say this is accurate?

Yeah I think that is valid. Hydra can also be put on top of existing infrastructures. Not sure how well that is possible with Doorkeeper.

Doesn't the nature of an OAuth server imply that it can be added to existing infrastructures? Or is there an issue you foresee with non-Hydra libraries?

No, Hydra works with every existing solution :) You can read more on this topic in the guide: https://ory-am.gitbooks.io/hydra/content/oauth2.html

You didn't answer my question. I think you may have misread it.

Also similar: https://github.com/coreos/dex

Ask HN: Is "hydra" the most used open source project name ?

Unicorn

hydra vs unicorn dixit github :

Hydra = 1,934 results (https://github.com/search?utf8=&q=hydra)

Unicorn = 1,878 results (https://github.com/search?utf8=&q=unicorn)

Winner Hyra !!!

Hail Hydra!

Nice! Lowering barriers to the use of technologies like these is important.

Would anyone else be interested in hosting Mozilla Persona? https://developer.mozilla.org/en-US/Persona

Thanks! I didn't know about Mozilla Persona but I think it is possible to use Hydra + Persona.

I thought Persona had kind of withered on the vine no?

I wonder what it's operational requirements are... and whether Mozilla is willing to hand persona.org et al over to a motivated group of volunteers.

We never got Persona past the point of needing an external script on websites pointing to the Persona domain. We really don't want to risk anyone getting XSS'd or assume transitive trust in whomever would follow Mozilla in custodianship of the domain, so we plan to kill the service, destroy all user data, and maintain ownership of the domain for many years.

Also, Persona was pretty explicitly designed in a way that assumed eventual, native integration into browsers. IMHO, any successor without the backing of a browser vendor would be better served by starting from scratch with a different set of assumptions. :)

What about a browser plugin? Perhaps support could be added through browser plugin, without explicit support of browser vendors. Then when adoption is significant enough, perhaps browser vendors will get on board.

(Hypothetical future in which Persona takes off. I think it's a great idea.)

I think it's a real shame about Mozilla Persona... Anyone know why it was dropped, it was always going to be one of those things that the people/organisation running it had to be in for the long term.

Check out Let's Auth:

https://github.com/letsauth/letsauth.github.io

It's a successor to Mozilla Persona in development.

Details in the readme and on freenode #letsauth (mirrored to gitter.im/letsauth/letsauth).

Some context: we just finished proving out OpenID Connect as a reasonable protocol for websites (seriously, there's good stuff hiding in there) and are now working on rewriting the prototypes so that they're stable and worthy of trusting. Expect an announcement in the next month, along with better documentation and on-ramps for contributors.

why is it written in python? why not something that compiles and runs well on all platforms?

From the readme:

> Let's Auth 1.0 will ship as a single, statically compiled binary. Pre-1.0, we will use a variety of dynamic languages for prototyping.

nice :)

> something that compiles and runs well on all platforms

What would that be? :)

How do you integrate this with your existing API? Do you need to proxy requests through Hydra or do you just need to read and trust Hydra-signed tokens on every request? Is there any overlap with https://getkong.org/?

Currently hydra issues opaque tokens but has the capabilities to switch to JWT in the future. There is a warden HTTP API endpoint that you can use to inspect tokens and use hydra's access control. I will probably add a more common token info endpoint or a OAuth2 Token Introspection endpoint ( https://tools.ietf.org/html/rfc7662 ) later on.

I haven't used kong yet but from my first impression it should be possible to use hydra together with kong.

Ok, thanks. So let's say I wanted to use Hydra for authenticating requests made to my REST API, I'd have to make an API call to Hydra on each request, right? Would be interesting to have some integration examples with popular web frameworks (e.g. Express.js, Rails, Django, etc.).

Thanks for releasing this by the way, looks really well engineered. I'm sure you've considered it already, but you could probably sell a hosted version (a la https://auth0.com) to make money and finance development.

Depends, if you use JWT you can cryptographically verify that the token and the token claims are valid. Right now, Hydra does not issue JWTs but it would be easy as pie to add that functionality.

Writing an integration guide for this is a very good idea. Hydra's APIs are validating all requests using that technique, but it's not documented.

Auth0.com is pretty cool, they have done some cool projects that help OAuth developers. However, they are overpriced imho. Hosting hydra is definitely something I will consider. Thanks! :)

You're doing OIDC but OIDC requires JWT. Well sorry but if you're not using JWT then this isn't OIDC. The whole point of OIDC is token verification, you provide an identity and that identity can be verified.

You have to query token validation endpoint to have your reference token validated. That's how oauth2 works. With OpenId connect you get JWT which can be validated without a call to the identity provider.

One thing I've not quite got my head around with JWT is not authenticating tokens with the server on each request - am I really just meant to assume a token is trusted until it's expiry time? What if a user signs out all their sessions in the meantime, or an employee is fired and needs access revoking? As far as I can tell I do just have to use short-lived tokens and renew them frequently but that comes with its own set of problems when doing JavaScript based applications and implicit auth.

That's the trade off. Either you have "real-time" data but need a database roundtrip or you save latency but must accept the downside. However, you can use short token times to mitigate that, something like 10 minutes for example.

Technically JWTs cannot be revoked once they're issued (they just expire). You have to make sure that you delete the JWT from your preferred storage when you sign a user out and issue JWTs for a short period.

You other option is to allow blacklisting of JWTs per client. However, this will add additional overhead of making an HTTP request to check if a token is blacklisted. That's how Auth0 does it in their commercial OpenId Connect provider.

For anyone interested the Go client library is: https://github.com/ory-am/fosite

OAuth is super simple, you only need two endpoints for an OAuth provider. It only took a few hours to write the WakaTime OAuth provider implementation[1]. No offense and serious question: why would you need a library for this? Isn't it more trouble to integrate an external OAuth provider with an existing api than to just write two api endpoints yourself?

[1] https://wakatime.com/api

The libraries (SDK) I used for my first project for had security flaws. OAuth2 is super simple to implement, but hard to get right. It's not just two endpoints, it's multiple specs with ~200 written pages. Some people for example don't even know that [rfc6819](https://tools.ietf.org/html/rfc6819) even exists. Most SDKs are also very limited or hard to extend (e.g. adding OpenID Connect).

I believe that adding a docker container to your deployment and creating a consent token (JWT) is even less work than integrating with an SDK and implementing the missing parts every time you hit that new edge case. On top of that, you can be sure that it is backed by an open source community.

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

I know it's in the title but I don't see any OpenID capabilities here. Looks like Oauth2 spec implementation. Am i missing something?

It implements OpenID Connect, which basically an opinionated OAuth2 implementation, and a different thing to OpenID.

OpenID has been deprecated in favor of OpenID Connect:

* http://openid.net/specs/openid-connect-core-1_0.html * http://openid.net/connect/faq/

This looks very nice, but isn't it overkill to use RethinkDB when SQLite would do (and probably be about as fast)?

It'd be really neat to see an amazon lambda serverless version of this.

Integrating that in lambda should not be hard. If you want, create an issue on GitHub and I will try my best.

Would this or coreos/dex replace something like Auth0?

Auth0 has a lot of integrations and features that dex/hydra do not have. Auth0 have their own Identity Provider, which hydra does not. But in general you can say that dex/hydra have a very similar featureset to Auth0

Auth0's big feature that isn't provided by open source platforms at the moment is being able to request an OAuth token for third party services the user has authenticated with, so for example you can trade in an auth token that was issued when you logged in the user for a Facebook token.

Not true. Dex and Hydra both support it, although you need to implement a little bit more stuff when using Hydra. Read it in the docs: https://ory-am.gitbooks.io/hydra/content/connection.html

I stand corrected. In that case Auth0 is even more overpriced than I originally thought.

Reply on news.ycombinator.com