Understanding Authentication vs Authorization
1. Defining Authentication
Authentication (AuthN) verifies who a principal claims to be by validating credentials against a trusted identity store.
| Aspect | Description | Example |
|---|---|---|
| Purpose | Identity verification | Login, SSO |
| Question | Who are you? | Username + password |
| Output | Authenticated principal | User object, JWT subject |
| Factors | Knowledge / Possession / Inherence | Password / Token / Biometric |
| Failure Code | 401 Unauthorized | Missing/invalid credentials |
2. Defining Authorization
Authorization (AuthZ) determines what an authenticated principal can do based on policies, roles, or attributes.
| Aspect | Description | Example |
|---|---|---|
| Purpose | Permission evaluation | RBAC, ABAC, ACL |
| Question | What can you do? | Can user.read? |
| Input | Principal + Resource + Action | (alice, /orders/42, DELETE) |
| Models | RBAC, ABAC, ReBAC, PBAC | Roles, attributes, relationships |
| Failure Code | 403 Forbidden | Authenticated but denied |
3. Understanding Authentication Flow
Client → [Credentials] → Auth Service → Identity Store
↓
Verify + Issue Token
↓
Client ← [Session/Token] ← Auth Service
| Step | Action | Artifact |
|---|---|---|
| 1 | Submit credentials | POST /login |
| 2 | Lookup user | DB / LDAP query |
| 3 | Verify secret | bcrypt compare |
| 4 | Issue session/token | Cookie / JWT |
| 5 | Subsequent requests | Bearer / Cookie |
4. Understanding Authorization Flow
Request + Token → PEP (Policy Enforcement Point)
↓
PDP (Policy Decision Point)
↙ ↓ ↘
PIP (info) Policy Context
↓
Permit / Deny
| Component | Role |
|---|---|
| PEP | Intercepts request, enforces decision |
| PDP | Evaluates policies against request |
| PIP | Provides attributes (user, resource) |
| PAP | Policy Administration Point (manage policies) |
5. Understanding Principal and Subject Concepts
| Term | Definition | Example |
|---|---|---|
| Principal | Entity making the request | User, service, device |
| Subject | Authenticated principal identifier | sub claim in JWT |
| Identity | Set of attributes describing principal | username, email, roles |
| Actor | Service acting on behalf of subject | OAuth on-behalf-of |
6. Understanding Credentials and Claims
| Type | Description | Example |
|---|---|---|
| Credential | Secret proving identity | Password, private key, OTP |
| Claim | Assertion about a subject | "role":"admin" |
| Standard Claims | JWT/OIDC defined | iss, sub, aud, exp, iat |
| Custom Claims | App-specific | "tenant":"acme" |
7. Understanding Trust Boundaries
A trust boundary is the perimeter at which data validation, authentication, and authorization decisions must occur. Crossing a boundary requires re-verification.
| Boundary | Control |
|---|---|
| Client ↔ API | TLS + token validation |
| Service ↔ Service | mTLS + service tokens |
| App ↔ Database | Connection auth + least privilege |
| Tenant ↔ Tenant | Row-level security + claim check |
8. Combining Authentication and Authorization
Example: Express middleware chain
// AuthN then AuthZ
app.get("/admin/users",
authenticate, // verifies JWT, sets req.user
authorize(["admin", "superadmin"]), // checks roles
(req, res) => res.json(users)
);
function authenticate(req, res, next) {
const token = req.headers.authorization?.replace("Bearer ", "");
try { req.user = jwt.verify(token, PUBLIC_KEY); next(); }
catch { res.status(401).json({ error: "invalid_token" }); }
}
function authorize(roles) {
return (req, res, next) => roles.includes(req.user.role)
? next() : res.status(403).json({ error: "forbidden" });
}
9. Understanding Defense in Depth
| Layer | Control |
|---|---|
| Network | WAF, DDoS protection, IP allowlists |
| Transport | TLS 1.3, HSTS, certificate pinning |
| Application | AuthN, AuthZ, CSRF, input validation |
| Data | Encryption at rest, field-level encryption |
| Monitoring | Audit logs, SIEM, anomaly detection |
10. Understanding Zero Trust Model
| Principle | Implementation |
|---|---|
| Never trust, always verify | Authenticate every request |
| Least privilege | Minimal scopes per token |
| Assume breach | Micro-segmentation, short-lived tokens |
| Verify explicitly | Device + user + context signals |
| Continuous validation | Re-auth on risk change |
Note: Perimeter-based trust ("inside the network") is obsolete in cloud and remote-work environments.