Identity is the security perimeter of the modern internet. With users, services, and APIs distributed across many clouds, "is the request coming from someone we trust?" is more important than "is it coming from inside our network?" This lesson covers the building blocks.
Authentication Factors
| Factor | Examples |
|---|---|
| Something you know | Password, PIN, security question |
| Something you have | Hardware token (YubiKey), TOTP app (Authenticator), smartphone, smart card |
| Something you are | Fingerprint, face, iris, voice |
| Somewhere you are | Location / IP-based (rarely a primary factor) |
| Something you do | Behavioural biometrics — typing rhythm, gait |
Multi-factor authentication (MFA) requires factors from different categories. A password + a security question is not MFA — both are "something you know". A password + a TOTP code is MFA.
Passwords (and Why They're a Mess)
Passwords have known problems: they get reused, phished, and brute-forced. Modern guidance (NIST SP 800-63B):
- Length matters more than complexity — 12+ characters, no forced symbol/digit rules
- No periodic rotation requirements (they encourage weak patterns like
Spring2024!) - Block known-breached passwords (HaveIBeenPwned API)
- Always store as a salted hash with a slow algorithm (bcrypt, scrypt, Argon2)
- Rate-limit and lock accounts after repeated failures
Stronger Than Passwords
- TOTP (RFC 6238): time-based one-time codes. Better than nothing, but phishable.
- Push notifications (Microsoft Authenticator, Duo): convenient, vulnerable to MFA fatigue attacks unless number-matching is enforced.
- FIDO2 / WebAuthn (passkeys, YubiKeys): phishing-resistant by design — the credential is bound to the origin. The strongest practical option.
- SMS / voice OTP: do not use as a primary factor for high-value accounts. Vulnerable to SIM swap.
Single Sign-On (SSO)
Without SSO, every app maintains its own user database — meaning every app is its own attack surface and every offboarding requires hunting through dozens of accounts. SSO centralises identity in an identity provider (IdP) like Okta, Microsoft Entra ID, Google Workspace, or Auth0. Apps trust the IdP and accept its assertions about who the user is.
Two protocols dominate:
SAML 2.0
XML-based, primarily for enterprise web SSO. The IdP issues a signed XML assertion to the application. Older but extremely common in B2B.
OpenID Connect (OIDC)
An identity layer on top of OAuth 2.0. Uses JSON Web Tokens (JWTs). Modern default for new applications, especially mobile and SPA.
OAuth 2.0 vs OIDC — The Confusion
| OAuth 2.0 | OpenID Connect | |
|---|---|---|
| Purpose | Delegated authorization | Authentication + identity |
| "Who is the user?" | Doesn't tell you | Tells you, in an ID token |
| Token | Access token (opaque or JWT) | ID token (always JWT) + access token |
| Use case | "Allow this app to read my Google Drive" | "Sign in with Google" |
One way to remember it: OAuth answers what can this app do, OIDC answers who is using it. Most modern flows use both — log in with OIDC and receive an OAuth access token to call APIs on the user's behalf.
Authorization Models
Role-Based Access Control (RBAC)
Users are assigned roles; roles have permissions. Simple, predictable, the default in most systems. Trade-off: gets rigid as you accumulate edge cases ("admin but not for this team", "auditor read-only except for that one operation").
Attribute-Based Access Control (ABAC)
Decisions are made by evaluating attributes of the subject, the resource, and the environment against a policy. Example: "users in the finance department can read invoices for their own region during business hours". More flexible, more complex. AWS IAM policies, Azure conditional access, and OPA/Rego are ABAC engines.
Other models
- Mandatory Access Control (MAC): classifications (Top Secret > Secret > Confidential), used in government/military.
- Discretionary Access Control (DAC): resource owner decides who has access (Unix file permissions).
- Relationship-Based Access Control (ReBAC): Google Zanzibar–style — decisions follow graph relationships ("alice is editor of doc X because she's owner of folder Y that contains it"). Tools: SpiceDB, OpenFGA.
Privileged Access Management (PAM)
Admin accounts are the crown jewels. PAM systems add controls specifically for them:
- Just-in-time (JIT) access — request elevation, get it for 1 hour, then it's revoked
- Session recording for forensic review
- Vaulted credentials — passwords are checked out, automatically rotated
- Break-glass accounts — emergency credentials stored offline, alerting on use
Identity Lifecycle
The often-overlooked part:
- Joiner — provision accounts, assign role-based access, MFA enrolment
- Mover — re-evaluate access on role changes
- Leaver — disable access immediately, transfer ownership of artefacts
Orphaned accounts after departures are a leading cause of insider breaches. SCIM (System for Cross-domain Identity Management) automates these flows from HR to your apps.