Authentication & Authorization 101

Most ATO war stories start with stolen passwords—this one starts with a help-desk badge.

1. The Story – When a Help‑Desk Intern Became a "Bank President"

Tuesday, 09:23 AM – Senior fraud analyst Jennifer Walsh sees an alert: help‑desk intern Michael Chen just approved a $2.7 million wire to a crypto exchange (an irreversible cash-out channel). Must be a glitch; Michael only resets passwords… right?

Jennifer checks the logs. Michael's login passed MFA and, shockingly, carried wire approval rights. She dives into the IAM audit trail (Identity and Access Management system, a ledger of every login, role grant, and permission change) and finds a slow-burn nightmare. Over six months an attacker quietly hijacked Michael's credentials, stacking roles (adding them one by one) and permission creeping their way to executive power.

By 14:45 Jennifer confirms Michael is a victim. The attacker weaponised his account through privilege escalation. Since every change was logged as "approved," the fraud team's customer‑centric rules never fired.

---

2. Six‑Month Escalation Timeline

CSR = Customer Service Representative

---

3. Core Concepts

3.1 Authentication (AuthN) vs Authorization (AuthZ)

Simple auth flow

Loading diagram...

1. AuthN check — user proves identity (password and MFA).
2. AuthZ check — system validates the user's role permissions.
3. Action — approve the wire if the role allows it; otherwise block and alert.

Takeaway: Perfect AuthN can't save you if AuthZ silently expands.

3.2 Role‑Based Access Control (RBAC)

1. Define roles → Help Desk, CSR, Loan Officer
2. Attach permissions → reset password, approve loan
3. Assign users → place staff in roles

Failure patterns Role confusion (blurry job lines), permission creep (rights never revoked), role stacking (toxic combos), ghost accounts (employees who left)

Guard rails Least Privilege — grant only today's access Segregation of Duties (SoD) — no user should both create and approve a high-risk action

Joiner → Mover → Leaver lifecycle (JML / IGA) Grant starter role, adjust on job change, revoke within 24 h of exit. Quarterly recertification curbs permission creep and works for ABAC too.

3.3 Privilege Escalation Basics

Red flags: gradual role adds, sudden high‑value access, out‑of‑hours grants.

3.4 UI vs API Paths (and BOLA)

Customers and attackers reach your service through the UI or via API calls. API endpoints often expose BOLA (Broken Object Level Authorisation): /accounts/123 → /accounts/124 lets an attacker change an ID to access another customer's data.

BOLA Attack Example:

Loading diagram...

The Problem: The API checks who you are (authentication) but not whether you own that specific resource (authorization).

Design note: Apply the same AuthZ checks to UI and API. A wire‑approval API must enforce the same role as the UI button.

---

4. Common Security Failures and Why They Happen

Understanding these failure patterns helps you recognize vulnerabilities before they become incidents:

Permission Creep

• Users accumulate privileges over time but never lose old ones
• Job changes add new roles without removing previous access
• Result: Help desk intern with executive wire approval rights

Role Stacking

• Users granted multiple overlapping roles instead of one comprehensive role
• Each role seems harmless individually but combined creates dangerous permissions
• Result: Customer service + temp admin + wire access = full system control

Ghost Accounts

• Former employees retain active accounts after departure
• Service accounts with unclear ownership and excessive permissions
• Result: Dormant accounts become attack vectors

Broken Segregation of Duties

• Single user can both initiate AND approve high-risk transactions
• No oversight or approval workflow for sensitive actions
• Result: One compromised account can cause maximum damage

---

5. Why These Fundamentals Matter for Fraud Analysts

Understanding authentication and authorization isn't just theoretical. It's the foundation of effective fraud investigation:

In Payment Fraud

• Merchant accounts use both authentication (login credentials, MFA) and authorization (who can update bank details, process refunds, access transaction data)
• Understanding both helps you investigate cases where criminals compromise merchant accounts to redirect payments or access customer data

In Account Security

• User accounts have authentication methods (passwords, MFA) and authorization levels (view-only, admin, etc.)
• Knowing how these work helps you investigate suspicious account activity

In System Design

• Every fraud prevention system relies on proper authentication and authorization
• Understanding the fundamentals helps you evaluate security controls and recommend improvements

---

6. Key Takeaways for Fraud Professionals

Master These Fundamentals

• Authentication verifies identity - "Who are you?"
• Authorization controls permissions - "What can you do?"
• Both must work together for effective security

Remember the Common Failures

• Permission creep - users accumulate too many privileges over time
• Role stacking - multiple roles create dangerous permission combinations
• Broken segregation - single users can both create and approve transactions
• Ghost accounts - former employees or unclear service accounts

Apply to Your Daily Work

• Every fraud investigation involves authentication and authorization concepts
• Understanding these fundamentals helps you evaluate security controls
• Use this knowledge to recommend better fraud prevention systems

---

7. Key Terms

For complete definitions of authentication and ATO terminology, see the ATO Glossary.

Core concepts from this module:

• AuthN vs AuthZ - Identity verification vs permission checking
• RBAC - Role-Based Access Control for managing user permissions
• BOLA - Broken Object Level Authorization (API security vulnerability)
• Permission creep - Gradual accumulation of privileges over time
• Privilege escalation - Gaining higher permissions than originally granted

---

All names, companies, and incidents are fictional and provided for educational use only.

---

Next module → ATO 101 — How criminals exploit authentication and authorization weaknesses in account takeover attacks.

---

Fast Facts (Real-World Statistics for 2024–2025)

• Stolen credentials were the initial vector in 22% of all breaches, powering 88% of basic web-app attacks in 2024.
  (Verizon DBIR 2025)

• Microsoft blocks roughly 7,000 password attacks every second—over 600 million per day—and 99% of identity attacks still target passwords.
  (Microsoft Digital Defense Report 2024)

• The global median dwell time between initial compromise and detection is 11 days (up from 10 days in 2023).
  (Mandiant M-Trends 2025)

• Phishing-resistant MFA can block > 99.2% of account-compromise attempts.
  (Microsoft Entra Identity)

---