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.
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?
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?
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.
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.
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.)
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.
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.
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 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.
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.
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.
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?
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.
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.
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
[1] https://github.com/doorkeeper-gem/doorkeeper