RBAC basics
Role-Based Access Control — user has roles; roles grant permissions.
admin → delete any order. user → delete own orders only.
Simple; breaks at fine-grained ("editor on doc 42 only").
ABAC / relationship-based (awareness)
Attributes: user, resource, action, context (time, IP).
Google Zanzibar model — user:123 viewer document:456. Used at scale; most teams use RBAC + resource checks first.
Resource-level authorization (must implement)
Every mutation checks: does this principal own or have rights to this resource ID?
order = db.get(order_id)
if order.user_id != current_user.id:
raise Forbidden()IDOR — insecure direct object reference — #1 API bug. UUIDs don't prevent IDOR; AuthZ does.
Multi-tenant isolation
SaaS B2B: tenant_id on every row; enforce in every query.
SELECT * FROM orders WHERE id = ? AND tenant_id = ?Missing tenant filter in one endpoint = cross-tenant leak.
Policy engines (when to mention)
OPA, Cedar, SpiceDB — centralize AuthZ when rules explode.
Interview: "Start with code checks; extract to policy engine when rules are shared across 10 services."
Scopes vs roles
OAuth scopes — coarse (read:orders). App roles — business (billing_admin).
Map scopes to roles at gateway; fine checks in service.
Audit for AuthZ failures
Log denied access attempts (not just successes) — detect probing.
Cross-reference: LLD for designing auth interfaces; Observability for security metrics and alerting on authZ denial spikes.
Further Reading
Hands-On Tasks (Optional)
Security design drills — threat modeling, auth flows, and incident playbooks. Assumes Networking (TLS) fundamentals.
- Fix an IDOR vulnerability15m
GET /api/orders/{id} returns any order if you guess UUID. Describe code-level fix, test case, and audit log addition.