Module 9 - Security

Authentication vs Authorization

Who are you? vs What can you do? Two different questions, often confused.

1The Building Security Analogy

Simple Analogy
Authentication: Showing your ID badge at the entrance. "Are you who you claim to be?"
Authorization: Your badge only opens certain doors. "What are you allowed to access?"
You can be authenticated (verified identity) but not authorized (no access to CEO's office).

Authentication (AuthN) verifies identity. Authorization (AuthZ) determines permissions. Both are essential, but they solve different problems.

2Authentication Methods

Password-based

Low-Medium

Username + password. Simple but phishable. Add MFA for security.

Multi-Factor (MFA)

High

Password + something you have (phone) or are (fingerprint).

OAuth/Social Login

Medium-High

Delegate to Google, GitHub, etc. User doesn't create new password.

API Keys

Medium

Static secret for service-to-service. Easy to implement, hard to rotate.

Certificates (mTLS)

Very High

Both client and server verify certificates. Very secure.

3Authorization Models

RBAC (Role-Based)

Users get roles, roles have permissions. Simple and widely used.

User → Admin Role → [create, read, update, delete]

ABAC (Attribute-Based)

Decisions based on attributes: user, resource, environment, action.

If user.department == resource.department AND time < 6PM → allow

ACL (Access Control List)

Explicit list per resource of who can access.

File: [alice:read, bob:write, admins:full]

ReBAC (Relationship-Based)

Access based on relationships. Used by Google Zanzibar.

User can edit document if user is owner OR user is in editors group

4Real-World Flow

1
User logs in
Provides credentials (password, OAuth, etc.)
2
Server authenticates
Verifies credentials against stored hash or OAuth provider
3
Server issues token
JWT or session ID containing user identity and roles
4
User makes request
Includes token in Authorization header
5
Server authorizes
Checks if user's roles/permissions allow the action
6
Allow or deny
403 Forbidden if authenticated but not authorized

5Common Mistakes

Confusing 401 and 403

401 = not authenticated (who are you?). 403 = not authorized (you can't do this).

Authorization in Frontend Only

Always check on backend. Frontend can be bypassed.

Hardcoding Permissions

Use configurable roles/policies. Business rules change.

Over-Privileged Default

Start with minimal permissions. Add as needed (principle of least privilege).

6HTTP Status Codes

401Unauthorized

Not authenticated. Need to log in.

Missing or invalid token

403Forbidden

Authenticated but not authorized.

User lacks permission

200OK

Authenticated and authorized.

Request succeeded

404Not Found

Sometimes used to hide existence.

Resource doesn't exist OR user can't see it

7Key Takeaways

1Authentication = Who are you? Authorization = What can you do?
2401 = not authenticated. 403 = authenticated but not authorized.
3RBAC (roles) is most common. ABAC (attributes) for complex policies.
4Always enforce authorization on the backend. Frontend is just UX.
5Principle of least privilege: start with no access, add what's needed.

?Quiz

1. User logs in successfully but can't access admin panel. HTTP code?

2. RBAC stands for: