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.
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.
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
It doesn’t seem that way on the surface. But once your finished with out of band redirect validation, localhost, refresh tokens, and PKCE, you realize what a monster OAuth 2 actually is.
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've been meaning to set up some nginx-level oauth. I have some self-hosted apps I want to share with friends / family but forcing them to remember a user / pass (basic auth) or run a vpn is a bit too much friction.
OAuth has always been quite hard to grasp, even though I use it every day. One day I'll write an implementation to properly understand how it works from the bottom up and go through each of the standards that have evolved over time.
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.
The title of the post, which the submitter dutifully copied, is IMHO unfortunate since the post seeks to answer the following question:
What I need is to understand why it is designed this way, and to see concrete examples of use cases that motivate the design
It's not "just another" explanation for how OAuth does, which was my immediate guess when reading the title.
However glad I opted to give it a chance, and likely especially illuminating for the younger crowd who didn't get to experience the joys of the early web 2.0 days.
If you go to most Fortune 500 companies they will have a whole team of people dedicated to running an IdP and doing integrations. Most people on these teams cannot explain oauth, oidc, or saml even though they work with it every single day. It’s that bad.
that is because oauth, oidc, and saml fall under the category "webshit" that doesn't matter, there are also thousands of C++ programmers who cannot explain the latest reactular .js and other bullshit the script kiddies continue to pump from their collective anus
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/
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
It doesn’t seem that way on the surface. But once your finished with out of band redirect validation, localhost, refresh tokens, and PKCE, you realize what a monster OAuth 2 actually is.
"OAuth is a simple idea, but with a curse: once you understand it, you lose the ability to explain it."
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.
What I need is to understand why it is designed this way, and to see concrete examples of use cases that motivate the design
It's not "just another" explanation for how OAuth does, which was my immediate guess when reading the title.
However glad I opted to give it a chance, and likely especially illuminating for the younger crowd who didn't get to experience the joys of the early web 2.0 days.