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 6-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”
Every request is anonymous by default. The server has no idea who sent it. It could be a legitimate user, a bot, or an attacker replaying a stolen token. Without authentication, your application serves private data to anyone who asks, lets anyone modify anyone else's account, and has zero audit trail for who did what.
Authentication answers one question: "Who are you?" Not "What are you allowed to do?" (that is authorization, the next lesson), just identity verification. You claim to be alice@example.com. Authentication is the process of proving it.
This sounds simple. It is not. Authentication systems must handle password storage (never plaintext, never even encrypted, only hashed with a slow algorithm), session management (how do you stay logged in across requests?), token formats ( vs opaque tokens vs cookies), multi-factor verification, OAuth flows for third-party login, and protection against brute force, credential stuffing, and session hijacking.
Every breach that makes headlines, every "10 million passwords leaked" story, is a failure at this layer. In 2022, Uber was breached through a compromised MFA push notification. In 2023, Okta's support system was compromised because an employee's personal Google account reused a corporate password. Get authentication wrong, and nothing else in your security architecture matters.
There are four major approaches to authentication in production systems. Each trades off security, user experience, and implementation complexity differently.
Passwords are the oldest method. The user types a secret string. Your server hashes it with bcrypt (cost factor 12+) or Argon2id and compares the hash to what is stored. Passwords are simple to implement but dangerous to operate: users reuse them across sites, they can be phished, and a database breach exposes hashes that attackers will try to crack offline. Dropbox switched from SHA-1 to bcrypt in 2012 after exactly this kind of breach.
2.0 delegates authentication to a trusted third party. When a user clicks "Sign in with Google," your app never sees their Google password. Google authenticates them, and your app receives a time-limited access token. This is how most consumer apps handle login today. The tricky part is implementing the authorization code flow correctly: validate the state parameter (prevents CSRF), exchange the code server-side (never in the browser), and handle token refresh.
SAML is the enterprise equivalent. Corporations use identity providers like Okta and Azure AD. SAML uses signed XML assertions instead of JSON tokens. It is older and more complex than OAuth/OIDC, but still the standard in corporate IT because every enterprise app supports it.
Passkeys (WebAuthn/FIDO2) are the newest and most secure option. The browser generates a cryptographic key pair, stores the private key in a hardware enclave or cloud keychain, and sends only the public key to your server. Authentication means signing a challenge with the private key. There is no shared secret. The credential is bound to the domain, so phishing is structurally impossible. Apple, Google, and Microsoft all support passkeys natively as of 2024.