Authentication, Authorization, and Identity

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: Two questions sit at the entrance of every application: “Who are you?” and “What are you allowed to do?” The first is authentication, the second is authorization. They sound similar, they’re constantly confused, and that confusion is itself a major source of vulnerabilities. Get these two concepts crisply separated and you’ve understood the machinery attackers target most.

Part 1: The Problem

Almost every application has users, and therefore must answer two distinct questions:

1. Authentication (authn): Are you who you claim to be?
2. Authorization (authz): Now that we know who you are — what may you access and do?

These are different questions, handled by different mechanisms, and failing at either is catastrophic. Yet beginners blur them, and even production systems get the boundary wrong — proving identity correctly but then failing to properly check permissions, or vice versa. Two whole categories of the OWASP Top 10 you’ll study in Phase 2 come straight from failures here. This section makes the distinction permanent.

Part 2: The Concept — Authentication vs Authorization

The cleanest way to lock in the difference:

   AUTHENTICATION                AUTHORIZATION
   "Who are you?"                "What are you allowed to do?"
   Proving identity              Checking permissions
   Happens first                Happens after
   ──────────────────────────────────────────────────────
   Airport analogy:
   Showing your passport         Your boarding pass deciding
   to prove who you are     →    which flight/seat you may board

You authenticate once (prove identity), then the system authorizes every subsequent action (checks whether this identity may do this thing). Authentication without authorization means anyone who logs in can do anything. Authorization without authentication means permissions attached to an unverified identity. Both halves are mandatory.

Part 3: How Authentication Works — The Three Factors

Authentication relies on proving you possess one or more factors — categories of evidence:

Passwords (a knowledge factor) are the weakest common method — guessable, reusable across sites, phishable, leaked in breaches. They persist only because they’re cheap and familiar.

Multi-Factor Authentication (MFA) dramatically strengthens the door by requiring factors from two or more different categories — e.g. a password (knowledge) plus a code from your phone (possession). An attacker who steals the password still can’t get in without the phone. MFA is one of the single highest-value security controls in existence; recommending it is something you’ll do constantly.

Part 4: Sessions and Tokens — Staying Logged In

Section 0.3 established that HTTP is stateless — it forgets you between requests — and that cookies carry a session value so the server remembers you’re logged in. Now we look at what gets carried, because there are two dominant approaches.

Session-based (server remembers). On login, the server creates a session record on its side and hands the browser a session ID (in a cookie). Each request sends the ID; the server looks it up. The server holds the real state and can instantly revoke a session.

Token-based (the token carries the info). On login, the server issues a token — commonly a JWT (JSON Web Token) — that itself contains the user info, signed by the server. The browser sends the token each request; the server verifies the signature and trusts the contents. No server-side lookup needed, which scales well — but revoking a token before it expires is harder.

   SESSION-BASED                   TOKEN-BASED (JWT)
   server stores the state         the token carries the state
   cookie holds only an ID         token holds signed user data
   easy to revoke instantly        revocation is harder
   server does a lookup each time  server just verifies a signature

The security point either way: whatever the browser holds — session ID or token — is the user’s identity to the server. Steal it and you are that user. This is why a JWT must be properly signed and verified (an unverified or weakly-signed token can be forged), why tokens carry expiry times, and why session IDs must be long, random, and sent only over HTTPS.

Part 5: OAuth and “Log in with…” — Delegated Access

You’ve clicked “Log in with Google.” That’s OAuth (specifically, the family of delegated-authorization standards), and its core idea is worth understanding plainly.

The problem OAuth solves: a third-party app wants limited access to your data on another service (say, your Google profile) — without you handing that app your Google password.

The valet-key analogy. A valet key starts the car and drives it a short distance but won’t open the glovebox or trunk. OAuth is a valet key for your data: the app gets a limited-scope token to do specific things, never your actual password, and you can revoke it anytime.

   You → "Log in with Google" on AppX
   You authenticate WITH GOOGLE (AppX never sees your password)
   Google asks: "Allow AppX to see your basic profile?"
   You approve → Google gives AppX a limited-scope TOKEN
   AppX uses that token for exactly what you approved — no more.

The key insight: your password stays with the provider you trust; the third-party app only ever receives a scoped, revocable token. Note also a common precision point — OAuth is fundamentally about authorization (delegated access); layered on top of it, OpenID Connect handles the authentication (“who is this user”) part. You’ll see both names; now you know which does which.

Part 6: Where Identity Systems Get Attacked

Tie this section to the attacker mindset — here’s where authn/authz machinery actually fails, each a preview of Phase 2:

Authentication failures:

• Weak passwords — guessed via brute force or credential stuffing (trying username/password pairs leaked from other breaches, exploiting reuse).
• No MFA — one stolen password is total access.
• Broken password reset — the reset flow is often weaker than the login itself; a poorly designed “forgot password” can hand over accounts.
• Session/token theft — steal the cookie or token (e.g. via XSS) and skip authentication entirely.
• Forgeable tokens — a JWT that’s unsigned, or signed weakly, can be crafted by the attacker.

Authorization failures:

• Broken access control — the system authenticates you correctly, then fails to check permissions properly: you change an ID in a request and view another user’s data (an IDOR), or you reach an admin function as a normal user (privilege escalation).
• Trusting the client — relying on the browser to enforce permissions (“we hid the admin button”). Authorization must be enforced on the server; the client can be fully manipulated by the attacker.

🔑 The recurring lesson: authentication and authorization are both mandatory, and both must be enforced server-side. A system that proves identity flawlessly but checks permissions sloppily is wide open — and that exact mistake is one of the most common serious bugs in the entire industry.

📓 Key Terms

🧪 Hands-On Lab

Task 1 — Sort authn from authz. Label each as authentication or authorization:

• Entering your password. → Authentication.
• The app checking you’re an admin before showing the admin panel. → Authorization.
• Scanning your fingerprint to unlock your phone. → Authentication.
• A document service deciding you can view but not edit a file. → Authorization.

Task 2 — Audit your own MFA. List the important accounts you use (email, banking, etc.). For each, note whether MFA is on. Turn it on wherever it isn’t. Identify, for each, which two factor types it combines.

Task 3 — Decode a JWT (safely). A JWT is three base64 sections separated by dots. Use a JWT decoder (offline or a trusted site) on a test token — many tutorials provide sample ones. Observe that the header and payload are merely encoded, not encrypted — fully readable. Only the signature protects it from tampering. Internalize: never put secrets in a JWT payload, and the signature is everything.

Task 4 — Walk through an OAuth flow. Next time you click “Log in with Google/GitHub,” slow down and read each screen. Notice: you authenticate on the provider’s site; the app shows you a scope of what it’s requesting; you approve. Map each screen to the diagram in Part 5.

Task 5 — Find the authorization flaw. A photo app shows your album at /album?id=5042. You change the URL to /album?id=5041 and another user’s album loads. Which concept failed — authentication or authorization? What’s this bug class called? (Authorization — the app authenticated you but didn’t check you own album 5041. It’s broken access control / IDOR — a Phase 2.7 topic.)

⚠️ Common Mistakes

• Conflating authn and authz. They answer different questions with different mechanisms. The blur is itself a source of bugs — always know which one you’re reasoning about.
• Enforcing authorization on the client. Hiding a button is not access control. The browser is fully attacker-controlled; permission checks must live on the server.
• Treating login as the only door. The password-reset flow, “remember me,” API authentication, and session handling are all entrances — and often weaker than the main login.
• Putting secrets in a JWT. A JWT payload is encoded, not encrypted — anyone holding the token can read it. The signature prevents tampering, not reading.
• Skipping MFA. Passwords leak constantly. Without a second factor, one leak is a full compromise. MFA is among the highest-value, lowest-effort controls there is.

✅ Recap & What’s Next

• Authentication (“who are you?”) and authorization (“what may you do?”) are distinct, sequential, and both mandatory — confusing them creates real vulnerabilities.
• Authentication uses factors (knowledge, possession, inherence); combining types gives MFA; staying logged in uses server sessions or self-contained tokens like JWTs — and whatever the browser holds is the user’s identity.
• Identity systems fail through weak/stolen credentials, forgeable tokens, and especially broken access control — and authorization must always be enforced server-side.

Next (1.5): You now have the core security framework. The last page of Phase 1 maps the field itself — the roles, the teams, and where a developer switching into security best fits — so you can aim your specialization deliberately.