How OAuth 2.0 Actually Works — A Developer's Guide

You click "Sign In with Google" and two seconds later you're logged in. Behind that button is a protocol handling billions of authentications daily — and most developers who implement it don't fully understand what's happening. The Problem OAuth Solved Before OAuth, if a third-party app wanted access to your Google data, you'd hand over your actual Google password. The app stored it, used it to log in as you, and had full access to everything. If that app got breached, your Google account was compromised. If you wanted to revoke access, you had to change your password — which broke every other app you'd given it to. This was the norm until around 2007. Twitter engineers and developers at other companies started sketching an alternative: what if apps could get limited access without ever seeing your password? That became OAuth. The Four Players Every OAuth flow has four roles: Resource Owner — that's you. The human who owns the data. Client — the application requesting access. Could be