We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
This idea carries a full system design question on its own. Each walks through the full answer.
System Design Masterclass · Security Architecture
Free preview: the first 2 parts of this 9-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Security Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Before OAuth, "Sign in with Twitter" meant typing your Twitter password into a third-party app's login form. The app stored your actual password. If the app was hacked, the attacker got your Twitter credentials. If you wanted to revoke the app's access, you had to change your Twitter password, which broke every other app that had it.
OAuth 2.0 replaces password sharing with delegated authorization. You click "Sign in with Google." Your browser goes to Google's login page, where you authenticate directly with Google. Google asks: "This app wants to read your email and profile. Allow?" You click Allow. Google gives the app a limited-scope, time-limited token. The app never sees your Google password. If you later want to revoke access, you go to Google's settings and remove the app. No password change needed.
OAuth 2.0 is the protocol behind every "Sign in with [Provider]" button on the internet. It powers GitHub integrations, Slack apps, Spotify connected devices, Figma plugins, and the login flow of millions of applications. The specification (RFC 6749, published in 2012) has become one of the most implemented standards in web development.
An important clarification: OAuth 2.0 is an authorization framework, not an authentication protocol. It tells your app what the user ALLOWED (read email, read profile), not who the user IS. OpenID Connect (OIDC) adds an authentication layer on top of OAuth 2.0 by including an ID token (a containing the user's identity). In practice, when people say "OAuth login," they almost always mean "OAuth 2.0 + OIDC."
| Role | Who | Example |
|---|---|---|
| Resource Owner | The user who owns the data | You (the person with a Google account) |
| Client | The application requesting access | Your web app |
| Authorization Server | Issues tokens after user consent | Google's OAuth server (accounts.google.com) |
| Resource Server | Holds the protected data/API | Google's API (www.googleapis.com) |
In simple setups, the Authorization Server and Resource Server are the same system. In Google's case, they are separate: accounts.google.com handles authentication and consent, while www.googleapis.com serves the actual API data.
Scopes define the boundaries. When your app requests access, it specifies scopes: email, profile, calendar.read, drive.files. The user sees these scopes on the consent screen and can approve or deny. Your app gets a token limited to those specific scopes.
Stripe's OAuth implementation uses scopes like read_write and read_only. GitHub uses scopes like repo, user:email, admin:org. Slack uses scopes like chat:write, channels:read, files:upload.
The principle of least privilege applies to scopes. Request only what your app actually needs. Asking for drive.files when you only need email scares users into abandoning sign-up. Google's research shows that apps requesting 3+ sensitive scopes have 38% lower OAuth completion rates than apps requesting 1 scope.