@geoffreylitt.com recently asked a question about OAuth on dead-Twitter:
I desperately need a Matt Levine style explanation of how OAuth works. What is the historical cascade of requirements that got us to this place?
There are plenty of explanations of the inner mechanical workings of OAuth, and lots of explanations about how various flows etc work, but Geoffrey is asking a different 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
In the 19 years (!) since I wrote the first sketch of an OAuth specification, there has been a lot of minutiae and cruft added, but the core idea remains the same. Thankfully, it's a very simple core. Geoffrey's a very smart guy, and the fact that he's asking this question made me think it's time to write down an answer to this.
It's maybe easiest to start with the Sign-In use-case, which is a much more complicated specification (OpenID Connect) than core OAuth. OIDC uses OAuth under the hood, but helps us get to the heart of what's actually happening.
OIDC is functionally equivalent to "magic link" authentication.
We send a secret to a place that only the person trying to identify themselves can access, and they prove that they can access that place by showing us the secret.
That's it.
The rest is just accumulated consensus, in part bikeshedding (agreeing on vocabulary, etc), part UX, and part making sure that all the specific mechanisms are secure.
... continue reading