Show HN: Run your own OAuth2 and OpenID Connect Provider
1–10 of 14 posts
Re: Show HN: Run your own OAuth2 and OpenID Connect Provider
#2https://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.)
Re: Show HN: Run your own OAuth2 and OpenID Connect Provider
#3Is 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.)
Re: Show HN: Run your own OAuth2 and OpenID Connect Provider
#4Is 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.)
Re: Show HN: Run your own OAuth2 and OpenID Connect Provider
#5Is 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.)
* http://www.thread-safe.com/2012/07/the-oauth-2-sky-is-not-fa... * https://hueniverse.com/2012/07/30/on-leaving-oauth/
Re: Show HN: Run your own OAuth2 and OpenID Connect Provider
#6Well 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.
Re: Show HN: Run your own OAuth2 and OpenID Connect Provider
#7Is 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.)
Re: Show HN: Run your own OAuth2 and OpenID Connect Provider
#8One 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.
Re: Show HN: Run your own OAuth2 and OpenID Connect Provider
#9> 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 R…
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.