Hacker News Reader

Comment by clickety_clack | Hacker News Reader

The thing about OAuth is that it’s really very simple. You just have to grasp a lot of very complicated details (that nobody explains) first before it becomes simple.

View on HN

For me, it really helped to read the Microsoft pages[1] on OAuth 2.0 which has some nice illustrative flow charts, and then go back to the RFCs.

That said, there's a lot of details that are non-trivial, especially since in many cases you actually have to deal with OIDC[2] which builds on OAuth 2.0, and so then you're suddenly dealing with JWKs and whatnot in addition.

[1]: https://learn.microsoft.com/en-us/entra/identity-platform/v2...

[2]: https://openid.net/developers/how-connect-works/

I remember building oauth logins back when “login with your twitter” was a brand new revolutionary idea, before there were libraries to handle the details.

Still have scars from building directly based off the blogposts Twitter and Facebook engineers wrote about how to integrate with this. Think it wasn’t even a standard yet.

I credit that painful experience with now feeling like OAuth is really quite simple. V2 cleaned it up a lot

OAuth 1a was simpler or at least straightforward.

It doesn’t seem that way on the surface. But once your finished with out of band callback validation, localhost, refresh tokens, and PKCE, you realize what a monster OAuth 2 actually is.

Ouch, reminds me of hours debugging OAuth2 implementation in my Surface 1 app for Twitter because the nonce or some other checksum was not calculated correctly.

I think the reason a lot of people struggle is because they start with OAuth from a consumer perspective, that is, they are the third party requesting data, and their OAuth implementation is imposed by the resource holder, so they have to jump through a lot of hoops that don't have a clear reason for being.

If you start with OAuth from the perspective of a Service Provider/resource holder, it will all come clear.

Web security is often like that as well, most people facing stuff like CORS or HTTPS, is usually not because they are trying to solve a security issue, but it's because an upstream provider is forcing them to increase their security standards in order to be trusted with their user's data.

For Oauth I'd like to borrow what I would describe humbly as a better analogy, and it comes from Douglas Crockford, and so adapting it from him commenting on Monads in Functional Programming, it goes something like this:

"OAuth is a simple idea, but with a curse: once you understand it, you lose the ability to explain it."

Are there any validation/test suites available that you can use to check that your implementation is correct?

I think https://oauch.io/ is quite useful to help you catch common implementation errors.

Reply on news.ycombinator.com