# Identity, Sessions & Authorization

**Track:** The Full-Stack Substrate — AI-Native Full-Stack Development — complete (30)
**Framework / surface:** web dev (auth / OAuth / row-level security)
**Level:** Intermediate
**Prerequisites:** Data Modeling, Migrations & Transactions, Server/Client Boundaries & Routing

**In one line:** Authentication answers who; authorization answers what that identity may do — including when an agent acts on its behalf.

## Theory, aesthetics & inspiration

Identity is not permission. Authentication establishes who a user or service is; a session carries that identity across requests; authorization decides what the identity may do right now — and collapsing the three into one "logged in" check is among the most common sources of insecure application logic. Saltzer and Schroeder's 1975 principles, least privilege chief among them, remain the standing rules: every action should execute with the narrowest authority that accomplishes it. In the reference stack, sessions ride cookies or tokens whose transport, lifetime, and script access need deliberate handling, and PostgreSQL's row-level security moves access rules into the data layer itself — policies decide which rows an identity may read or write. The AI-native extension is delegated authority: an agent acting for a user must not inherit unlimited power because a model emitted a tool call — which is why OAuth's core separation of client, resource owner, and authorization server matters here, and why RFC 9700 (2025), the current OAuth security best-practice, tightens how tokens and grants may flow between them. Ask of every request: acting as whom, allowed to do exactly what?

**Builder question:** When this request reaches the database or tool, what identity is it acting as and what exact authority does that identity possess?