Authentication vs. Authorization

Authentication (AuthN) answers one question: Who are you? You claim an identity — a username, email address, employee ID, device certificate, or service account name — then prove that claim with one or more factors. Proof can be a password, a one-time code from an authenticator, a hardware security key, a biometric unlock, or a cryptographic assertion from a trusted identity provider. Until proof succeeds, the system should treat you as a stranger.

A successful login means the system accepts the identity for this session. It does not mean you may do anything interesting yet. Think of AuthN as issuing a nametag. The nametag says "Alice." It does not say "Alice may approve wire transfers." That second decision is Authorization, and it must be checked again on every sensitive action — not only at the front door.

Authorization (AuthZ) answers: What are you allowed to do? After login, every read, write, delete, transfer, export, or admin action should be checked against a policy. Policies may be role-based (RBAC: "professors may grade"), attribute-based (ABAC: "only owners of this record"), or a mix. The important idea for learners: the server — not the UI — must enforce the rule.

Greyed-out buttons are helpful UX, not security. A determined user can still call the API, change a URL, or replay a request. Secure systems authorize on the server for every sensitive object and every sensitive verb. "Can this session read object 1002?" is a different question from "Did this session log in successfully?"

Healthy access control is a pipeline. First the identity provider authenticates you and issues a session token or cookie. Then each application request presents that session. Then the app (or API gateway, or policy engine) looks up who the session represents and asks whether that identity may perform this action on this resource. Fail any step → deny by default.

This pipeline is why "I logged in, so I should see everything" is a dangerous mental model. Login proves identity. Policies decide scope. When organizations skip the second step — or implement it only in the frontend — they create Broken Access Control, consistently ranked among the most damaging web application risks. Conceptual awareness only: never probe live systems you do not own or have written permission to test.

Use this checklist on any app you already use (email, school portal, bank, cloud drive). You are observing your own access boundaries — not attacking anything, not fuzzing IDs, not testing neighbors' accounts. The goal is vocabulary that sticks when you later design or review systems.

# Fill for ONE app you already use — observation only
App name: ____________________

AUTHENTICATION (who am I?)
- What proves identity?  password / MFA / biometric / passkey / other: _______
- What happens if proof fails?  locked out / retry / reset flow
- Session clue: cookie, "signed in as", device trust prompt?

AUTHORIZATION (what may I do?)
- Actions I CAN do: ________________________________
- Actions blocked (Access Denied / greyed out / admin-only): ______
- Different roles you know exist (student vs teacher, member vs admin): ______

# Mental rule (memorize)
AuthN first  →  then AuthZ on EVERY sensitive action
Nametag ≠ wristband
UI grey-out ≠ server enforcement

# HARD STOP — ethical boundary
Do NOT change account numbers, user IDs, or document IDs in URLs
to see if another person's data appears. That is unauthorized testing
on systems you do not own. Learn the failure mode from this lesson —
do not reproduce it against live services.

You now separate "prove who you are" from "decide what you may do," including why object-level checks matter after login and why broken access control is so dangerous. Next — Password Security — we harden the most common AuthN factor humans still get wrong: length, uniqueness, and the password manager vault.