# Authentication, Authorization & Encryption — System Design: Architecture, Scale and Trade-offs

Source: https://www.skillbyai.com/en/system-design/sd-security-basics

> Separate authentication from authorization, use signed tokens such as JWT, and protect data in transit and at rest.

## AuthN vs AuthZ

**Authentication** confirms identity ('you are Priya') — passwords, tokens, OAuth. **Authorization** decides what that identity can do ('Priya can read but not delete this order') — roles, scopes, ACLs. Keep them as separate checks; conflating them causes both security bugs and confusing errors.

## Auth at scale

Verifying identity on every service with a shared database doesn't scale. **Signed tokens (JWT)** carry identity and claims that any service can verify locally with a public key — no per-request call to an auth service. Trade-off: revoking a token before it expires is hard.

## A wristband at a festival

A JWT is like a festival wristband stamped by the entrance: any staff member can glance at it and know you're allowed in (authentication) and which zones your color permits (authorization), without radioing back to the ticket booth every time.

**Quiz:** What does 'encryption in transit' protect against, that 'encryption at rest' does not?

- [ ] Someone stealing the physical disk
- [ ] A compromised database backup
- [ ] A weak password policy
- [x] Someone intercepting data as it travels over the network

*Answer:* Someone intercepting data as it travels over the network. TLS protects data moving between client and server or between services; at-rest encryption protects stored data on disk. You need both.