1. Learning Objectives

By the end of this lesson, you will be able to:

• Define authentication (AuthN) and authorization (AuthZ) and never conflate them.
• Explain identity, credentials, and factors in practical terms.
• Describe sessions, cookies, and tokens at a high level.
• Apply RBAC (Role-Based Access Control) to organize permissions.
• Recognize IDOR and missing function-level checks as authorization bugs.
• Map AuthN/AuthZ failures to real breach themes (API leaks, token theft).
• Design mental checklists for “who are you?” vs “what may you do?”

2. The Two Questions Every System Must Answer

Every secure application answers two distinct questions:

Authentication without authorization is incomplete: logging in does not mean you may access every record.

Authorization without authentication is dangerous: anonymous APIs that guess IDs can leak data.

Memory trick

AuthN = badge at the door.
AuthZ = which rooms your badge opens.

Fingerprint unlock on a payment app → AuthN.
Paying only from your linked bank account → AuthZ.

3. Identity, Credentials, and Subjects

Service accounts and API keys are identities too — not just humans.

4. Authentication Factors

Multi-factor authentication (MFA) uses two or more different factor types. Password + security question (both knowledge) is weak MFA. Password + TOTP app is stronger.

5. Authentication Mechanisms (Survey)

OAuth is often confused with AuthN — it can delegate identity, but your app must still enforce AuthZ on every API call.

6. Sessions and Tokens

After successful AuthN, systems track state:

6.1 Cookie attributes (web)

6.2 Session lifecycle

1. Login → issue session/token with expiry.
2. Each request → validate session + re-check authorization for the action.
3. Logout → invalidate server-side session or revoke refresh token.
4. Idle timeout + absolute timeout limit exposure.

Never authorize based only on “they have a valid session” without checking resource ownership.

7. Authorization Models

7.1 Discretionary ACLs (ACL)

Owner of a file sets who may read/write — classic Linux/Windows file ACLs.

7.2 RBAC — Role-Based Access Control

Users receive roles; roles bundle permissions.

Benefits: Easier audits (“who has admin?”), consistent onboarding/offboarding.

Pitfalls: Role explosion, static roles without attribute checks (department, clearance).

7.3 ABAC — Attribute-Based Access Control

Decisions use attributes: user department, resource classification, time of day, device compliance. Common in Zero Trust policies.

7.4 ReBAC — Relationship-Based

Access derived from graph relationships (Google Zanzibar model) — “edit if owner or editor.”

For fundamentals, RBAC + resource ownership checks covers most app bugs.

8. Authorization in Applications

Every sensitive operation needs:

1. Authentication — valid session/token.
2. Authorization — subject may perform this action on this object.

Check at:

• API layer (mandatory)
• Business logic layer (defense in depth)
• Database (row-level security where available)

8.1 IDOR — Insecure Direct Object Reference

Classic bug: user changes ?invoiceId=1001 to 1002 and views another customer’s invoice.

AuthN succeeded; AuthZ failed.

Fix: server loads invoice only if invoice.ownerId == session.userId (or role permits).

8.2 Horizontal vs vertical privilege escalation

Both are authorization failures.

8.3 Function-level vs object-level

Test both in authorized labs only.

9. Federation and SSO (Awareness)

Single Sign-On lets one identity provider (IdP) authenticate users for many apps (service providers).

Flow (simplified OIDC):

1. App redirects to IdP login.
2. User authenticates (with MFA at IdP).
3. IdP returns ID token / code to app.
4. App establishes local session.

AuthZ remains local: SSO does not mean every app user is admin.

10. Common Anti-Patterns

11. Logging and Monitoring

Log authorization denials (without leaking secrets):

• Subject ID
• Action attempted
• Resource ID (hashed if sensitive)
• Outcome

Spikes in 403 responses or unusual admin actions may indicate probing.

12. Case Study Themes: Large Platforms and APIs

Public reporting on major platforms repeatedly highlights:

• Broken access control in APIs (OWASP #1 category in many years).
• Scraping enabled when pagination tokens do not enforce ownership.
• Over-broad tokens (GitHub, cloud provider keys) causing deep impact when leaked.

Lesson: AuthN establishes identity; every read/write must enforce AuthZ against that identity.

13. Case Study: Stolen Credentials and Broad Tokens

Historical incidents involved stolen OAuth tokens, PATs, or session cookies with wide scope.

Lesson: Short lifetimes, refresh rotation, step-up MFA for sensitive actions, least-privilege scopes.

14. Practical Lab: AuthN vs AuthZ on Your Own Apps or OWASP Juice Shop (Local)

Objective: Separate the two concepts hands-on — only authorized targets.

Option A — Thought exercise (no hacking)

1. Pick Gmail: list three AuthN steps and three AuthZ rules (e.g., cannot read others’ mail).
2. Draw a table: Action | AuthN required? | AuthZ rule?

Option B — Local OWASP Juice Shop (if you run it locally)

3. Register two users Alice and Bob.
4. Log in as Alice; note an API call that returns only Alice’s data.
5. Attempt to access Bob’s cart or profile by changing an ID — observe 403/401 when fixed vs leak when vulnerable (document for class discussion).

Option C — Your web project

6. Add middleware: requireAuth vs requireRole('admin') — explain difference in comments.

Never test IDOR on production sites you do not own.

15. Knowledge Check

Q1. Entering a password at login is primarily which process?

A. Authorization
B. Authentication
C. Accounting
D. Auditing only

Q2. Changing a URL parameter to view another user’s order without permission is a failure of:

A. Authorization
B. DNS
C. Authentication only if password weak
D. Compression

Q3. RBAC assigns permissions based on:

A. Random IP addresses
B. Roles mapped to permissions
C. MAC addresses only
D. Browser language

Q4. An HttpOnly session cookie primarily mitigates:

A. Some XSS-based cookie theft
B. All phishing
C. DDoS attacks
D. Hard drive failure

Q5. OAuth “Login with Google” primarily helps with:

A. Delegated authentication
B. Automatic admin rights in your app
C. Removing need for HTTPS
D. Database indexing

Q6. A valid JWT in Authorization header proves identity, but your API must still:

A. Skip authorization for speed
B. Enforce authorization for each action and resource
C. Trust any claim forever
D. Disable logging

Q7. Vertical privilege escalation means:

A. Gaining higher privileges (e.g., admin) than assigned
B. Reading only your own files
C. Changing DNS records
D. Using two monitors

Q8. Which is the best description of AuthZ?

A. Proving who you are
B. Deciding what an authenticated subject may do
C. Hashing passwords
D. Assigning IP addresses

Q9. MFA with password + authenticator app uses factors:

A. Knowledge + possession
B. Knowledge + knowledge
C. Possession + possession
D. None

Q10. Server-side session invalidation on logout helps because:

A. Stolen session IDs may stop working when revoked
B. It increases password length
C. It disables TLS
D. It removes need for RBAC

Answer Key

1. B
2. A
3. B
4. A
5. A
6. B
7. A
8. B
9. A
10. A

16. Lesson Summary

Authentication verifies identity; authorization enforces what that identity may access. Sessions and tokens carry proof of AuthN but must not replace per-request AuthZ checks. RBAC scales permission management, yet object-level checks stop IDOR. Real breaches often combine stolen credentials with missing or coarse authorization.

Remember: Logged in ≠ allowed. Test access control on authorized lab systems only.

17. Coming Next: Password Security and MFA

The next lesson covers password hygiene, phishing-resistant MFA, passkeys, and FIDO2 — turning authentication from a single weak factor into layered defense.

CYNARKS Academy – Learn to Understand. Practice to Defend.

Practice only on systems and networks you own or have explicit authorization to test.