Authorization in Practice
Ongoing · 5 parts
in engineering
Who can do what, and how you prove it — roles vs attributes, policy tests that hold the line, multi-tenant isolation, audit trails, and what happens when permissions become a graph.
- 1 RBAC vs ABAC: Roles, Attributes, and Where Each One Breaks RBAC answers 'what kind of user is this'; ABAC answers 'can this user do this thing, right now, to this row.' Where role checks stop scaling, where attribute policies get hard to audit, and the hybrid every real app lands on — with Laravel examples.
- 2 Testing Authorization Policies Like the Boundary They Are A policy bug isn't a bug, it's an incident. Table-driven Pest tests over the attribute grid, feature tests that prove the 403 is actually wired, and the Gate::before mistake that silently kills every policy you have.
- 3 Multi-Tenant Authorization: One Database, Many Customers, Zero Leaks In a SaaS, the worst bug class is the cross-tenant leak — customer A seeing customer B's rows. Global scopes that make the leak impossible by default, why tenancy is not authorization, and the escape hatches that bite: queues, commands, and reports.
- 4 Audit Trails: Who Did What, When, and Prove It Authorization decides what happens; the audit trail proves what happened. What a useful audit event records, spatie/laravel-activitylog for model changes, logging the denials (not just the changes), and why append-only is the property that makes it an audit log at all.
- 5 ReBAC: When Permissions Become a Graph Google's Zanzibar modeled access as relationship tuples — editor of the folder that contains the doc. When your ABAC policies turn into chains of relationship-walking, ReBAC (OpenFGA, SpiceDB) is the tool built for it. What it buys, what it costs, and the seam that keeps you free to adopt it later.