Security basics

Think of it like this

Analogy

An office building. At the front desk you show ID and get a badge: that's authentication. The badge opens some doors (your floor, the kitchen) but not others (the server room): that's authorization. Confidential papers travel between offices in sealed envelopes (encryption in transit) and are stored in locked cabinets (encryption at rest). The keys are kept in a key safe, not taped under the desk (secrets management).

The problem it solves

Security failures are rarely clever hacks. They're usually missing basics: an API that doesn't check who owns a record, a password database stored badly, a storage bucket left public, an API key committed to a repository, traffic sent unencrypted inside the network. Each one can expose every user's data at once, and the damage can't be undone.

A real example

Example

A clinic’s appointment app

A small clinic lets patients book appointments and read test results online.

Everything goes over HTTPS. Passwords are stored as bcrypt hashes, never as plain text. Every request for a result checks that the record belongs to the logged-in patient, not just that someone is logged in. Database queries use parameters, so a name like '; DROP TABLE is just a strange name.

The app's database user can read and write appointments but can't drop tables. API keys for the SMS provider live in a secrets manager, not in the code. Staff accounts need multi-factor login, because one stolen staff password would expose every patient.

How it works

Authentication (authN): who are you?

Authentication verifies identity.

• Passwords must be stored as slow, salted hashes (Argon2id, scrypt or bcrypt), never encrypted or plain.
• Multi-factor authentication and passkeys (WebAuthn) stop most account takeovers.
• Don't build it yourself if you can avoid it: use an identity provider for sign-up, sign-in, password resets and MFA.

After sign-in, the server issues a session cookie (lesson 7) or tokens.

Tokens, OAuth and JWT

OAuth 2.0 is a standard for granting an app limited access on a user's behalf; OpenID Connect adds sign-in on top (“Sign in with Google”). The result is usually a short-lived access token and a longer-lived refresh token.

A JWT is a signed token containing claims like user ID, roles and expiry. Any server with the public key can verify it without a database lookup. Keep access tokens short-lived (minutes), because they can't easily be revoked before they expire, and always verify the signature, expiry, issuer and audience.

Authorization (authZ): what may you do?

Authorization is checked on the server for every request, never trusted from the client.

• Role-based (RBAC): admins can delete, editors can edit, viewers can read.
• Attribute- or relationship-based: “you can edit this document because you're its owner or it's shared with you”.
• Object-level checks: always confirm the record belongs to the caller. Broken object-level authorization (changing an ID in the URL) is the most common API vulnerability.
• Least privilege: give users, services and machines only the permissions they need, including cloud IAM roles.

Encryption

• In transit: TLS (HTTPS) for everything public, and increasingly between internal services too (mutual TLS, often through a service mesh). Redirect HTTP to HTTPS and use HSTS.
• At rest: encrypt databases, disks, backups and object storage. Cloud services do this by default with provider-managed keys; use customer-managed keys in a key management service for stricter control.
• Secrets: keep API keys, database passwords and certificates in a secrets manager, inject them at runtime, rotate them, and never commit them to code.

Other everyday defenses

• Validate input and use parameterized queries to prevent SQL injection; escape output to prevent cross-site scripting.
• Rate-limit sign-in and sensitive endpoints (lesson 16).
• Put a web application firewall and DDoS protection at the edge.
• Log security events (sign-ins, permission changes) and alert on unusual patterns.
• Keep dependencies patched.

Trade-offs

What you gain

• Managed identity providers give strong sign-in, MFA and standards support without writing crypto code.
• Signed tokens let many services verify users without a central lookup.
• Default encryption protects against stolen disks, backups and network snooping.

What it costs you

• Tokens are hard to revoke instantly; short lifetimes add refresh complexity.
• Fine-grained authorization logic gets complicated and must be tested carefully.
• Key management and rotation add operational work.

When not to use it

• Don't invent your own crypto, token format or password hashing.
• Don't put sensitive data in JWT claims; they're signed, not encrypted, and anyone holding the token can read them.

In the cloud

Identity and sign-inEvery major cloud sells this as a managed service, so you configure it rather than build it.

AWS2

• AWS IAM (opens vendor docs)

  Who and what can call which AWS APIs, through users, roles and policies.

• Amazon Cognito (opens vendor docs)

  Sign-up, sign-in and tokens (OAuth 2.0 / OpenID Connect) for your app's users.

Azure2

• Microsoft Entra ID (opens vendor docs)

  Microsoft's identity service for employees and Azure access (formerly Azure Active Directory).

• Microsoft Entra External ID (opens vendor docs)

  Sign-in for your app's customers; the successor to Azure AD B2C for new projects.

Google Cloud2

• Cloud IAM (opens vendor docs)

  Roles and permissions for who can do what on Google Cloud resources.

• Identity Platform (opens vendor docs)

  Customer sign-in with email, phone and social providers, built on Firebase Authentication.

Users sign in with the identity service, which issues a token; the API checks the token on every call.

AWSAzureGoogle Cloud

1. User signs in
2. Amazon Cognito issues JWT
3. API Gateway authorizer checks it
4. Backend

Encryption keys, secrets and certificatesEvery major cloud sells this as a managed service, so you configure it rather than build it.

AWS3

• AWS KMS (opens vendor docs)

  Create and control encryption keys used to encrypt data at rest.

• AWS Secrets Manager (opens vendor docs)

  Store and rotate database passwords, API keys and other secrets.

• AWS Certificate Manager (opens vendor docs)

  Free public TLS certificates for AWS load balancers and CloudFront, renewed automatically.

Azure1

• Azure Key Vault (opens vendor docs)

  Keys, secrets and certificates in one managed vault.

Google Cloud3

• Cloud KMS (opens vendor docs)

  Managed encryption keys, including hardware-backed keys.

• Secret Manager (opens vendor docs)

  Store and version API keys, passwords and certificates.

• Certificate Manager (opens vendor docs)

  Provision and renew TLS certificates for Google Cloud load balancers.

Interview questions

Try answering out loud first, then open the model answer.

What's the difference between authentication and authorization?+

Model answer

Authentication establishes who the caller is, by checking a password, passkey, token or certificate. Authorization decides what that identity is allowed to do with a specific resource, such as whether user 7 may read order 42. Authentication happens once per session or token; authorization is checked on every request, on the server.

Sessions or JWTs for a web app's login?+

Model answer

For a browser-based app, a server-side session with a secure, HTTP-only, SameSite cookie is simple and easy to revoke. JWTs shine when many services or third parties must verify identity without a shared session store, or for mobile and API clients. Then I'd use short-lived access tokens with refresh tokens that can be revoked server-side. I'd avoid long-lived JWTs stored in local storage.

How would you secure service-to-service communication inside your system?+

Model answer

Encrypt and authenticate every connection with mutual TLS, often provided by a service mesh, so services prove their identity to each other. Authorize calls with service identities and least-privilege policies (service A may call only these endpoints of service B). Use the platform's workload identity instead of long-lived keys, keep any remaining secrets in a secrets manager, and restrict network paths so a compromised service can't reach everything.

Quiz

Pick an answer to see whether it’s right and why.

1. 01A logged-in user changes the URL from /orders/41 to /orders/42 and sees someone else's order. What failed?

   AuthenticationAuthorizationEncryption
2. 02How should a server store user passwords?

   Encrypted with a key the server keepsHashed with a slow, salted password-hashing algorithm such as Argon2 or bcryptIn plain text in a protected table
3. 03What does OAuth 2.0 let a user do?

   Encrypt their hard driveLet an app access some of their data in another service without giving the app their passwordReset their password
4. 04Where should database passwords and API keys live?

   In the code repositoryIn a secrets manager, injected at runtime, with access controlled and loggedIn a shared spreadsheet
5. 05How do you prevent SQL injection?

   Hide the login pageUse parameterized queriesRequire longer passwords
6. 06What does “least privilege” mean?

   Each user and service gets only the access it needsAdmins get every permissionNobody gets any access
7. 07What's the difference between authentication and authorization?

   They are the sameAuthorization checks passwordsAuthentication checks who you are; authorization checks what you're allowed to do

0 of 7 answered

Key terms

Authentication (authN)

Proving who you are, for example with a password or a passkey.

Authorization (authZ)

Deciding what an authenticated user is allowed to do.

OAuth 2.0

A standard for letting an app act on your behalf with limited access, without sharing your password.

JWT

JSON Web Token. A signed token that carries claims like user ID and expiry, which servers can check without a lookup.

TLS / HTTPS

Encryption for data travelling over the network. HTTPS is HTTP sent over TLS.

Encryption at rest

Encrypting stored data so a stolen disk or backup is unreadable without the key.