Show HN: Run your own OAuth2 and OpenID Connect Provider | Hacker News Reader

Show HN: Run your own OAuth2 and OpenID Connect Provider

github.com

88 pointskdyx0r12 comments

Is OAuth2 back in the good graces of the dev community? I thought one of its creators considered it a dead standard?

https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-...

(Genuinely asking because I've been thinking I might use a centralized auth store in a project recently and I wondered what the state of the art was.)

That post is very popular, but there is a follow up posting on OpenID Connect and that it can makes sense. I have to dig that out though, couldn't find the link in my bookmarks.

also noteworthy that the blog post is 4 years old and OAuth2 is basically everywhere :)

Also noteworthy that adoption doesn't change any of the points made.

adoption doesn't change the points semantically, but it shows that a large part of the (corporate) secrutiy community weighs those arguments (much) less than the author does.

ok, I finally found it. Note that it's still from 2012 and we've moved along from that dispute.

* http://www.thread-safe.com/2012/07/the-oauth-2-sky-is-not-fa... * https://hueniverse.com/2012/07/30/on-leaving-oauth/

Good graces? It's not perfect, mostly people over-granting permissions.. but in most cases you can't run into an API or other rights sharing tool without OAuth2.

I'm a recent and big fan of Hydra.

One of my biggest issues with OAuth provider libraries is how tied you usually are to specific authentication implementations and if you want to go outside that, things get complex, fast.

They've concentrated just on the backend parts of being a provider, passing responsibility for authentication, signup, password resets, etc to a challenge app you write yourself.

> OAuth2 and OAuth2 related specifications are over 200 written pages. Implementing OAuth2 is easy, getting it right is hard.

Well that is not true or to tell it differently it's true and false. This sentence implies that somebody will want to implement everything from OAuth2 which basically doesn't need to happen in your own Application. I mean most people should probably never built their own, however the OAauth2 RFC is pretty good. Compared to the http / http2 spec it's also pretty much detailed and even handle's most edge cases. Basically it's definitv worth trying to built your own (at least one part of it), just for the sake of learning since the core mechanism is actually pretty straight forward.

I think I agree, although I'd like to point out a few things.

1) Just like any other authentication/security system, probably not a good idea to write your own for production. As a learning experience, definitely.

2) The spec is pretty good, although it's a little confusing that it's more or less split across https://tools.ietf.org/html/rfc6749 (oauth) and https://tools.ietf.org/html/rfc6750 (bearer tokens)

3) The hardest part about "getting it right" is that the spec allows for broken/insecure behavior. You don't have to enforce https; you don't have to use expiring token; you can even allow password-based grants. Making these choices would be stupid, but you'd technically be OAuth 2.0 compliant.

I agree 100% on number (3), especially because almost nobody knows https://tools.ietf.org/html/rfc6819 (OAuth 2.0 Threat Model and Security Considerations)

For the .Net inclined, there is already IdentityServer--very good and great documentation: https://github.com/IdentityServer/IdentityServer3

Reply on news.ycombinator.com