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 5-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”
2.0 solved authorization: "this app can access your Google Drive files." But it was never designed for authentication: "this user is alice@gmail.com." Developers hacked OAuth into an authentication protocol anyway, each implementing it differently, creating security vulnerabilities in the process. Facebook's OAuth implementation differed from Twitter's, which differed from GitHub's. An app that "logged in with OAuth" was actually abusing an authorization protocol for identity.
OpenID Connect (OIDC) adds a standardized identity layer on top of OAuth 2.0. When you click "Sign in with Google," OIDC handles it. OAuth provides the access token (authorization). OIDC adds an ID token (authentication), a signed that contains the user's identity claims: who they are, how they authenticated, and when.
Every major identity provider supports OIDC: Google, Microsoft, Apple, GitHub, Auth0, Okta, Keycloak. It is the modern standard for web and mobile authentication, and the correct choice for any new application that needs "sign in with" functionality.
Authorization Code with PKCE is the recommended flow for all clients: web apps, mobile apps, and SPAs. The Implicit flow is deprecated.
The flow starts when the user clicks "Sign in with Google." Your app generates a random code_verifier and computes its SHA-256 hash (code_challenge). It redirects the browser to Google's authorization endpoint with scope=openid email profile, the code_challenge, and your client_id.
Google shows a consent screen. The user approves. Google redirects the browser back to your app with a short-lived authorization code in the URL. Your backend sends the authorization code plus the original code_verifier to Google's token endpoint. Google verifies the code_verifier matches the original code_challenge, then returns two tokens: an ID token ( with identity claims) and an access token (for calling Google APIs).
Your backend verifies the ID token: check the signature against Google's public keys (published at jwks_uri), verify iss is https://accounts.google.com, verify aud matches your client_id, and verify exp is in the future. Then read sub (stable user ID) and email to find or create the local user.
PKCE (Proof Key for Code Exchange) prevents authorization code interception. Without PKCE, an attacker who intercepts the authorization code (via a malicious browser extension or redirect) can exchange it for tokens. With PKCE, the code is useless without the code_verifier that only your app knows.