Security: designing systems that are hard to misuse

Security isn't a box you add at the end; it's a property of how the boxes are connected. Most real breaches aren't clever cryptography attacks. They're an endpoint that forgot to check who owns a record, a secret in a repository, an over-privileged service account, or one customer's data reachable from another's. This module gives you the design-level toolkit: identity, permissions, secrets, encryption and isolation.

1. The idea

• Authentication (AuthN): proving who you are: passwords, passkeys, one-time codes, a service's certificate.
• Authorization (AuthZ): deciding what you may do: "can user 7 cancel booking 9?". Checked on every request, for the specific resource.
• Least privilege: every user, service and key gets only the permissions it needs, for only as long as it needs them.
• Defence in depth: several independent layers (network, identity, authorization, encryption, monitoring), so one mistake isn't a breach.
• Threat modelling: before building, ask what you're protecting, from whom, and how it could go wrong. A simple prompt list is STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege.

2. How it works

Sessions and tokens

• Server-side session: after login, the server stores a session record and gives the browser a random session ID in a cookie (HttpOnly, Secure, SameSite). Easy to revoke (delete the record); needs a shared session store when you have many servers.
• Signed token (JWT): the server signs a small JSON document of claims (user ID, roles, expiry). Any service with the key (or the public key) can verify it without a database lookup. Hard to revoke before it expires, so keep access tokens short-lived (minutes) and pair them with a refresh token. Try tampering with one in section 3.

Logging in with OAuth 2.0 and OpenID Connect

OAuth 2.0 lets an app get limited access on a user's behalf without seeing their password. OpenID Connect (OIDC) adds identity on top ("Sign in with Google", corporate single sign-on). The recommended flow for web and mobile apps is the authorization code flow with PKCE. Press Play.

Authorization models

Services, secrets and encryption

• Service identity: services authenticate to each other with short-lived credentials, not shared passwords: cloud workload identities (IAM roles), or certificates for mutual TLS issued by a mesh or SPIFFE-based system. Authorize service calls too: the billing service may call payments; the recommendations service may not.
• Secrets (API keys, database passwords) live in a secrets manager (HashiCorp Vault, AWS Secrets Manager, Google Secret Manager, Azure Key Vault), are fetched at run time, rotated regularly, and never committed to code or logged.
• Encryption in transit: TLS everywhere, including inside the data centre. At rest: disks, databases and backups encrypted, with keys in a key management service (KMS); envelope encryption encrypts data with a data key, and the data key with a master key that never leaves the KMS.

Multi-tenant isolation

In a SaaS product, one customer must never see another's data. Options, from cheapest to strongest: a tenant_id on every row with every query filtered by it (enforce it with PostgreSQL row-level security rather than trusting every query to remember); a schema per tenant; a database per tenant; or a whole deployment (a cell) per tenant or group of tenants for the largest or most regulated customers. Isolation also means performance: rate limits and quotas per tenant stop a noisy neighbour from degrading everyone.

3. Try it yourself

Tamper with a signed token

This token is really signed in your browser with HMAC-SHA256 and a secret only the "server" knows. Edit the claims (make yourself an admin, extend the expiry) and verify it.

Signed tokens are readable by anyone (the payload is just base64): never put secrets in them. They're tamper-evident, not secret.

Who may do what?

Alice and Bob are customers; Sam is support staff. The endpoint is GET /invoices/{id}. Turn the checks on and see which requests are wrongly allowed.

4. Trade-offs

5. In real systems

• The OWASP Top 10:2025 lists the most common web application risks. Broken access control is A01, followed by security misconfiguration and software supply chain failures; injection, insecure design and authentication failures are still on the list.
• Identity providers (Okta, Auth0, Microsoft Entra ID, Google Identity, AWS Cognito, Keycloak) implement OAuth 2.0 and OIDC so you don't have to. OAuth 2.1, which folds in today's best practices such as mandatory PKCE, is still an IETF draft in October 2026.
• Passkeys (FIDO2/WebAuthn) replace passwords with device-held keys that can't be phished or reused, and are supported across major platforms and browsers.
• Edge protection: a web application firewall, bot detection and DDoS protection at the CDN or load balancer; rate limits per user and per IP (Module 24).
• Supply chain: pin and scan dependencies, sign build artifacts, and grant CI pipelines the least privilege they need.
• Audit logs record who did what to which resource, are append-only, and are kept separately from application logs so an attacker can't quietly edit them.

In an interview, security is usually one or two sentences unless it's the focus: "users sign in through an OIDC provider; the API gateway verifies short-lived JWTs; every endpoint checks the caller owns the resource; services use workload identity and mTLS; secrets in a secrets manager; data encrypted at rest with KMS." For multi-tenant SaaS, add the isolation model.

The technologies up close

6. Remember it

7. Common mistakes

8. Design exercise (30 minutes)

1. Threat-model a ride-hailing app with STRIDE: one realistic threat per letter, and the control that addresses it.
2. Design authorization for a document editor with owners, editors, viewers, shared folders and public links. Which model, and what does the check for "edit document 42" look like?
3. Isolate tenants for a B2B SaaS app with 10,000 small customers and 20 enterprise customers who demand isolation. Draw the data layout.
4. Remove secrets: list every credential in a typical web app (database, payment API, email API, signing keys) and where each should live and how it rotates.
5. Write it down: AuthN vs AuthZ, and "check every door".

9. Self-check quiz

10. Go deeper

11. Under the hood (optional)

How the cryptography and browser mechanics behind authentication and authorization really work. Not needed for most interviews; open it when you want to know how the products really do it. All the deep dives are listed on the Under the hood page.