loom-auth

# Authentication & Authorization Authentication proves *who* you are; authorization decides *what* you may touch. **Authorization is where real bugs cluster** — broken object-level authorization (IDOR/BOLA) is the #1 API risk (OWASP API Security Top 10). Get object-ownership checks right before polishing token plumbing. ## When to Use Auth is security-critical; default to Opus (`loom-senior-software-engineer`) for design, token/session lifecycle, access-control model choice, and anything touching production credentials. Delegate to Sonnet only for well-scoped execution against an existing pattern: unit tests for auth code, boilerplate middleware, scaffolding from a concrete plan. Never ship auth code that a senior hasn't adversarially reviewed against the checklist below. Scope boundary: this skill is *mechanisms*. For vuln scanning use `loom-security-scan`; deep audit `loom-security-audit`; architecture threats `loom-threat-model`. ## Authorization: IDOR / BOLA (read this first) Every request that names an object (`/orders/123`, `?user_id=…`, a foreign key in a body) must verify the caller **owns or is granted** that specific object — authentication ("is logged in") is not authorization. The bug is invisible in tests that only use one account. ```typescript // ❌ BOLA: any authenticated user reads any order by guessing the id app.get("/orders/:id", requireAuth, async (req, res) => { const order = await db.orders.findUnique({ where: { id: req.params.id } }); res.jso...