5 ms·
> 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
by merb 10y ago
> 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.
- kough 10y agoI 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 https://tools.ietf.org/html/rfc6749 (oauth) and https://tools.ietf.org/html/rfc6750 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.
- arekkas 10y agoI agree 100% on number (3), especially because almost nobody knows https://tools.ietf.org/html/rfc6819 https://tools.ietf.org/html/rfc6819 (OAuth 2.0 Threat Model and Security Considerations)