05 — Identity, Authentication and Authorisation
Level: Intermediate · Time: ~18 min · Prerequisites: Lesson 4 — Cryptography Essentials
Why this matters
Credentials are what attackers actually go after, because a stolen login bypasses almost every network control you own. A valid account is not an intrusion attempt — it is a successful one, and it generates almost no alerts. That is why the majority of breaches start with a credential (phishing, spraying, stuffing, re-use) rather than with an exploit. Identity is therefore the highest-value place to put effort: MFA on the accounts that matter, least privilege behind them, and logs that show what was done afterwards. Get identity wrong and every other control is decoration.
Four words people confuse
| Term | The question | A concrete example |
|---|---|---|
| Identification | who do you claim to be? | typing paul@example.com into a login form |
| Authentication | prove it | the password, plus the code from a hardware key |
| Authorisation | what are you allowed to do? | this account may read the finance share but not write to it |
| Accounting / audit | what did you actually do? | the log line showing that account deleted 400 files at 03:12 |
They fail separately, and the failures look different. A wrong claim is identity confusion. A weak proof is an authentication failure. Missing checks are an authorisation failure — and they are the hardest to see, because the user is perfectly legitimate.
Factors: what you know, have, are — and where you are
| Factor | Examples | Strength | Notes |
|---|---|---|---|
| Something you know | password, PIN, security answer | weakest alone | reusable, phishable, shared |
| Something you have | hardware key, passkey, smartcard, phone app | strong | can be stolen physically, but not phished remotely |
| Something you are | fingerprint, face, iris | strong for presence | irrevocable if compromised; a local unlock, rarely a solo remote factor |
| Somewhere you are | corporate network, managed device posture | context | spoofable in isolation, excellent as an additional signal |
| Something you do | typing rhythm, behavioural analytics | detection, not gate | useful for spotting account takeover after the fact |
Single-factor authentication means one of these. Multi-factor means two different kinds — a password plus a one-time code is multi-factor; a password plus a security question is not, because both are "something you know". MFA is the single highest-value control available to you: it defeats password spraying, credential stuffing and most phishing of passwords outright, at almost no cost.
| Second factor | Phishing resistance |
|---|---|
| SMS one-time code | weakest — SIM swapping, SS7 interception, and the code can simply be typed into the attacker's page |
| Authenticator app TOTP | better — but a real-time phishing proxy can relay it |
| Push notification | convenient, but trains users to approve prompts (MFA fatigue) |
| Hardware key (FIDO2/WebAuthn) | strongest — the credential is bound to the origin, so a lookalike domain gets no valid signature |
| Passkey (synced FIDO2 credential) | strongest, with better usability — the sync service becomes the residual risk |
Number-matching push (where the user confirms a number shown on the login page, not the phone) removes most of the "approve by reflex" problem. It is a small change with a large effect.
Password reality
- Length beats complexity. Every extra character multiplies the search space; a symbol substitution rule does not. Long passphrases are both stronger and more memorable.
- Breach lists are the practical attack. Attackers try known leaked credentials first — that is credential stuffing. Check your accounts against a breach corpus and force a change on any hit.
- Re-use is the real vulnerability. One breach at a low-value site becomes access to your email, which becomes everything else.
- Password managers fix the human problem: unique, long, random passwords per site, with one strong master secret that must be protected by MFA.
- Forced periodic rotation no longer recommended. Modern NIST guidance is to drop arbitrary expiry and instead force changes on evidence of compromise — because rotation produces
Summer2026!patterns and does nothing about a credential that is already stolen. - Never truncate, never store reversibly, never email a password. And block the top few thousand leaked passwords outright.
Sessions and tokens
After authentication, the server must recognise you on the next request. Two broad approaches:
Server-side sessions. The browser holds an opaque random identifier in a cookie; the server holds the state. Revocation is immediate — delete the server record and the session is gone.
| Cookie attribute | What it does |
|---|---|
Secure |
never send it over plain HTTP |
HttpOnly |
JavaScript cannot read it (blunts XSS session theft) |
SameSite=Lax or Strict |
not sent on cross-site requests (blunts CSRF) |
Domain / Path |
scope; keep it as narrow as the application allows |
Max-Age / Expires |
lifetime; shorter is safer for sensitive applications |
Token-based authentication. The client presents a bearer token — whoever holds it is treated as the user. That is the essential property and its essential weakness: a token is a password in a header.
JWT structure — three base64url segments separated by dots
eyJhbGciOiJFUzI1NiJ9 . eyJzdWIiOiIxMjMiLCJyb2xlIjoidXNlciJ9 . MEUCIQ...
header payload (readable!) signature
| JWT mistake | What it enables |
|---|---|
alg: none accepted |
anyone can mint a token by deleting the signature |
| Token's own header picks the algorithm | algorithm confusion: verify RS256 tokens as HS256 using the public key as the secret |
| Signature never verified | payload is trusted, so identity and roles are attacker-chosen |
| Secrets, internal IDs or excessive claims in the payload | information disclosure; the payload is encoded, not encrypted |
| No expiry, or hours-long expiry | stolen tokens work indefinitely |
| No revocation path | a logged-out or fired employee keeps working |
Refresh tokens exist to fix the lifetime problem: a short-lived access token (minutes) plus a long-lived refresh token that can be revoked, rotated and bound to a device. The refresh token is the valuable one — it should be stored as carefully as a password.
Delegated identity: OAuth 2.0, OIDC and SAML
- OAuth 2.0 is an authorisation framework, not an authentication protocol. It answers "may this application access this resource on my behalf?" — delegating a scoped permission without sharing the password. It says nothing about who the user is.
- OpenID Connect (OIDC) adds authentication on top of OAuth 2.0: an ID token (a JWT) with the identity claims, standardised userinfo, and discovery. This is the layer that answers "who is this".
- SAML is the enterprise equivalent: XML assertions, signed and exchanged through the browser, still widespread in large organisations. Different packaging, same idea — a trusted identity provider vouches for the user to a service provider.
- The authorisation-code flow is the standard: the browser is redirected to the identity provider, the user authenticates there (so the application never sees the password), the provider returns a short-lived code, and the application exchanges that code for tokens on a back channel. PKCE binds the code to the original client so an intercepted code is useless.
- The implicit flow was removed because it returned tokens directly in the URL fragment where they leak into history, logs and referrers. If you find it in a codebase, it is a finding.
Directories: LDAP, Active Directory and Kerberos
LDAP is the protocol for reading and writing a directory — a tree of objects (users, groups, computers) with attributes. An anonymous or unencrypted bind leaks the directory and the credentials, which is why 389 should be replaced by LDAPS on 636 everywhere possible.
Active Directory is Microsoft's implementation: LDAP for queries, Kerberos for authentication, DNS for locating services, plus Group Policy for centralised configuration. In one paragraph, Kerberos works like this: you authenticate once to the KDC (the domain controller) and receive a ticket-granting ticket (TGT). When you need a service, you present the TGT and receive a service ticket for that specific service. The service trusts the ticket because it is encrypted with a key the KDC and that service share. Consequences worth remembering: a stolen TGT can be replayed while it is valid, service accounts with weak passwords are crackable offline (Kerberoasting), and a forged TGT signed with a stolen domain key is a golden ticket — Lesson 13 covers all three.
SSO and federation extend this across organisations: authenticate once at an identity provider, and each application trusts that assertion. The benefit is fewer passwords and one place to enforce MFA. The risk is concentration — a compromised identity provider compromises everything it fronts — and MFA fatigue, where an attacker with a valid password generates login prompts until the user approves one to make it stop.
Authorisation models
| Model | How it decides | Use it when |
|---|---|---|
| RBAC (role-based) | the user's role grants a set of permissions | the default for most organisations: roles map to jobs |
| ABAC (attribute-based) | attributes of user, resource and context — department, data classification, time, device state | fine-grained rules are genuinely needed; powerful but harder to audit |
| Least privilege | grant the minimum needed, for the minimum time | always — this is the principle behind everything else |
| Separation of duties | no single person can complete a sensitive action alone | payments, production changes, key custody |
| Privileged access management (PAM) | admin access goes through a vault, a jump host, with session recording and just-in-time elevation | any environment with standing administrator accounts |
| Break-glass accounts | one documented emergency account, heavily protected and monitored | so nobody keeps a permanent admin account "in case" |
| Joiner–mover–leaver | a defined process for access at hire, on role change, and on exit | every organisation with employees |
The one-line definition of authorisation failure: the system checks that you are logged in, and forgets to check whether you may do this. That omission is broken access control, and it is consistently at the top of the list of web application risks — see Lesson 10.
Identity control → what it stops
| Control | What it stops |
|---|---|
| MFA with hardware keys or passkeys | credential stuffing, password spraying, most phishing, MFA fatigue |
| Password manager with unique passwords | re-use fall-out from third-party breaches, weak password choices |
| Breach-list checking at login | login attempts with known-leaked credentials |
| Short-lived sessions and tokens with revocation | account takeover persisting after it is discovered |
HttpOnly + Secure + SameSite cookies |
session theft by XSS, and cookie-borne CSRF |
| SSO with central MFA | password sprawl, orphaned accounts, inconsistent MFA coverage |
| RBAC with least privilege | lateral movement using an over-privileged account |
| Separation of duties | fraud and destructive actions by a single insider or a single compromised account |
| PAM with jump hosts and session recording | standing admin rights, unlogged privileged activity, credential dumping from admin workstations |
| Joiner–mover–leaver with access reviews | stale accounts that nobody owns but everybody can use |
Attack it / Defend it
| The attack | How it works | The control that stops it |
|---|---|---|
| Password spraying | one common password against many accounts to stay under lockout thresholds | MFA, breached-password blocking, monitoring for many-source low-volume failures |
| Credential stuffing | leaked username/password pairs replayed across services | unique passwords via a manager, MFA, breach-list checks |
| Phishing with a reverse proxy | a real-time proxy relays the victim's login and their one-time code | phishing-resistant factors: FIDO2 hardware keys and passkeys |
| MFA fatigue (push bombing) | flood the user with approval prompts until one is accepted | number-matching push, rate limiting, alerting on repeated prompts |
| Session fixation | attacker sets or knows the session ID before login, then keeps using it | re-issue the session on authentication, never trust a client-supplied ID |
| Session/token theft | XSS reads the cookie, or a token is exposed in a URL and logged | HttpOnly and Secure cookies, tokens only in headers, short lifetimes |
| JWT tampering | edit the payload and rely on the signature not being verified, or use alg: none |
pin the algorithm, verify the signature on every request, keep claims minimal |
| Kerberoasting | request service tickets for accounts with weak passwords and crack them offline | long, managed service-account passwords, managed service accounts, monitoring for unusual ticket requests |
| Over-privileged account abuse | use a legitimate account with far more rights than the task needs | least privilege, RBAC with review, just-in-time elevation |
| Orphaned accounts | a leaver's or contractor's account is never disabled | joiner–mover–leaver process, periodic access reviews, disable on exit the same day |
Key takeaways
- Identification, authentication, authorisation and audit are four different jobs. Most breaches succeed because one of the last two was assumed rather than implemented.
- MFA is the best return on effort in security, and hardware-backed phishing-resistant factors are the only ones that stop a proxy-based phishing page.
- A bearer token is a password in a header. Treat tokens, refresh tokens and session cookies as credentials, because that is what they are.
- Authorisation must be checked on every request, at the object level — not in the UI, not at the edge, not once per session.
- Access you do not remove is access an attacker will use. Review quarterly, disable the same day, and keep one documented break-glass path.
Check yourself
- Give the four identity terms, each with one sentence describing what it does.
- Why is SMS one-time code a weak second factor, and what makes a hardware key different?
- A JWT arrives with
"alg": "none". What has the attacker achieved if your code accepts it? - What does OAuth 2.0 authorise, and why is OIDC needed on top of it?
- An employee moves from marketing to finance. Name two access problems this creates and the process that should handle them.