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

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

I did this for OAuth and OAuth2 in Unison. It was a headache to be sure I did everything procedurally correct. The hash token is based off using certain KVPs from a dictionary of various bits of data, and you sort it in a certain order before hashing, and certain steps require certain bits of data, and sometimes it's URL encoded and sometimes it's not, and all of this dramatically changes the hash.

I remember how stoked I was to finally get it working. It was a massive pain, but luckily there were websites that would walk through the process procedurally, showing how everything worked, one step at a time.

Maybe worth mention: its author wrote the first sketch of an OAuth specification, while working at Twitter.