API Boundaries: Authentication vs Authorization

What This Is

This lesson teaches a boundary that every serious SaaS depends on: proving who the caller is versus deciding what that caller may do.

Why This Matters in Production

Production systems fail quietly when auth and authorization are mixed. You either block valid work or, worse, allow privileged actions to untrusted users because “the user is logged in” felt sufficient.

Mental Model

Authentication is identity. Authorization is policy. API handlers should first establish principal, then evaluate policy, then perform business logic.

Deep Dive

A route should never infer privilege from convenience. Auth verifies a session, token, or credential. Authz evaluates resource ownership, role, feature flag, or approval state. Mature systems make these checks obvious in code because ambiguity invites abuse. This matters even more in AI systems, where generated handlers often skip the policy layer entirely.

Worked Example

In a learning platform, `POST /submissions` requires an authenticated learner, but `POST /admin/reviews` requires a founder or staff reviewer. Both routes may use the same session primitive, yet their policy checks are completely different. A good design states those checks explicitly, not by implication.

Common Failure Modes

Common failures include “logged in means allowed”, checking role but not resource ownership, and pushing policy into the frontend where it can be bypassed.

official-doc

Better Auth Documentation

Use this for identity primitives and auth flow expectations.

article

OWASP Access Control

Anchor the lesson in a real security failure category.

official-doc

Cloudflare Zero Trust Concepts

Connect policy thinking to perimeter and application access.