OAuth 2.0 & OpenID Connect
OAuth delegates authorization (can App X access resource Y); OIDC adds authentication on top.
In 2008, an app that wanted to import your contacts asked you for your email password. The big social networks did exactly this, and millions of people typed it in.
Think about what that handed over. Not the contacts. The account that can reset every other password you own, with no way to grant less, no way to see which apps held it, and no way to revoke one without changing the password and breaking all of them.
OAuth exists so that never has to happen again. Your credentials go to one place, and the app gets a narrow, revocable token instead.
It is also routinely misused as a login system, which it is not, and that particular confusion has shipped real account-takeover bugs at companies you have heard of.
Lessons
4 in this chapter- The Delegation ProblemBefore OAuth, apps asked for your email password. Four roles replaced that with scoped, revocable grants.2 min
- The Authorization Code FlowRedirect out, code back, exchange server-to-server: the one OAuth sequence to know cold.2 min
- The Tokens InvolvedAccess, refresh, and ID tokens each have exactly one job, and mixing them up is the classic trap.2 min
- OIDC: Authentication on TopOAuth says what the holder may do; the OIDC ID token says who logged in, verifiably.3 min