Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Run your own OAuth2/OpenID Connect provider

github.com

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Show HN: Run your own OAuth2/OpenID Connect provider

#41

Post by arekkas »

jon-wood wrote: post #38
ClayM wrote: post #24

Would this or coreos/dex replace something like 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

Re: Show HN: Run your own OAuth2/OpenID Connect provider

#42

Post by arekkas »

welder wrote: post #39

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.

Re: Show HN: Run your own OAuth2/OpenID Connect provider

#43

Post by abritishguy »

welder wrote: post #39

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

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

Re: Show HN: Run your own OAuth2/OpenID Connect provider

#44

Post by StavrosK »

arekkas wrote: post #34
scrollaway wrote: post #18

Earlier quoted context omitted.

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

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

> something that compiles and runs well on all platforms

What would that be? :)

Re: Show HN: Run your own OAuth2/OpenID Connect provider

#46

Post by jon-wood »

arekkas wrote: post #41
jon-wood wrote: post #38

Earlier quoted context omitted.

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.

Re: Show HN: Run your own OAuth2/OpenID Connect provider

#47

Post by defiancedigital »

johns wrote: post #25
defiancedigital wrote: post #16

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

Re: Show HN: Run your own OAuth2/OpenID Connect provider

#48

Post by dalu »

arekkas wrote: post #13
olalonde wrote: post #8

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…

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.

Re: Show HN: Run your own OAuth2/OpenID Connect provider

#49

Post by neilellis »

defiancedigital wrote: post #47
johns wrote: post #25

Earlier quoted context omitted.

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!

Re: Show HN: Run your own OAuth2/OpenID Connect provider

#50

Post by Pyxl101 »

callahad wrote: post #21
xenophonf wrote: post #12

Earlier quoted context omitted.

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 a…

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

Post reply on HN