DEV Community

Cover image for Authentication vs Object Authorization: The API Security Mistake Everyone Makes
YogSec
YogSec

Posted on

Authentication vs Object Authorization: The API Security Mistake Everyone Makes

#authentication #apiauthorization #apiauthentication #apipentesting

If you’ve ever thought

“The user is logged in, so this API call must be safe”

…you’ve already stepped into the most common API vulnerability on the internet.

This post explains the difference between authentication and object authorization, why developers confuse them, and how this confusion leads to Broken Object Level Authorization (BOLA / IDOR) — the #1 issue in modern APIs.

What Is Authentication?

Authentication answers only one question:

Who are you?

In APIs, authentication usually happens using:

  • JWT tokens (RFC 7519)
  • OAuth 2.0 access tokens (RFC 6749)
  • API keys
  • Session cookies

When authentication succeeds, the backend says:

“Okay, I know who you are.”

That’s it.

Example 

GET /api/v1/profile
Authorization: Bearer eyJhbGciOi...
Enter fullscreen mode Exit fullscreen mode

✅ Token is valid
❌ No decision yet about which data you can access

What Is Object Authorization?

Object authorization answers a completely different question:

Are YOU allowed to access THIS specific object?

This is where most APIs fail.

Object authorization must verify:

  • Object ownership
  • User role
  • Organization / tenant scope
  • Object state (draft, deleted, archived, paid)

This failure class is officially called
👉 Broken Object Level Authorization (BOLA)
(OWASP API Top 10 – API1:2023)

Why Developers Confuse These Two

Because authentication is:

  • Centralized
  • Handled by frameworks
  • Easy to test

Object authorization is:

  • Custom logic
  • Different per endpoint
  • Often rushed or forgotten

Most vulnerable APIs follow this flow:

1. Authenticate user ✅
2. Trust object_id from request ❌
3. Return data ❌
Enter fullscreen mode Exit fullscreen mode

Real-World Vulnerable Example (IDOR) 

GET /api/v1/invoices/8421
Authorization: Bearer USER_A_TOKEN
Enter fullscreen mode Exit fullscreen mode

Response:

{
  "invoice_id": 8421,
  "user_id": 999,
  "amount": 4500,
  "status": "paid"
}
Enter fullscreen mode Exit fullscreen mode

What went wrong?

  • Authentication ✔️
  • No ownership validation ❌
  • User accessed another user’s invoice

This is a textbook IDOR vulnerability
(OWASP IDOR explanation)

“But We Use UUIDs” (The Biggest Myth)

Many teams believe:

“IDs are unguessable, so we’re safe.”

This is false.

UUIDs prevent guessing — not authorization bypass.

If the backend doesn’t verify ownership:

  • UUIDs
  • Hashes
  • Encrypted IDs
  • Base64 strings

…all fail equally.

OWASP explicitly warns about this misconception
(OWASP API Authorization Guide)

Authentication vs Object Authorization (Side-by-Side)

Feature Authentication Object Authorization
Question Who are you? Can you access THIS?
Scope User / session Object / resource
Frequency Once per request For every object
Typical bug Auth bypass BOLA / IDOR
OWASP API Top 10 Rare #1 issue

Why Bug Bounty Hunters Love This Bug Class

Because:

  • Login systems are usually solid
  • Authorization logic is not
  • Mobile APIs leak more data
  • Same object is often accessible via multiple endpoints

That’s why BOLA vulnerabilities pay well
(HackerOne API reports)

How Secure APIs Should Do It

Correct backend flow:

1. Authenticate user
2. Extract user_id / org_id from token
3. Fetch object from database
4. Verify object.owner_id == user_id
5. Return response
Enter fullscreen mode Exit fullscreen mode

Anything less is a risk.

Final Mental Model (Remember This)

Authentication lets you enter the building.
Object authorization decides which doors you can open.

Most APIs check the gate, not the doors.

If You’re a Developer or Security Tester

Every time you see:

  • IDs in URLs or JSON
  • Filters like user_id, org_id
  • Export / download endpoints
  • Mobile APIs returning extra fields

Ask one question:

Should this user be able to see THIS data?

That question alone finds real bugs.

Further Reading

Top comments (0)