Lesson 15 · Senior auth & authz

Designing authorization models: roles, permissions, attributes, and boundaries

Why mature authorization design is about choosing the right boundary for each rule — and why this repo uses roles, permissions, location attributes, and RLS together.

Your win: explain why this repo blends RBAC, permission modeling, location scope, and RLS instead of pretending one model can carry every rule cleanly.

In plain English Plain English: good authorization design is not picking one acronym forever — it is putting the right kind of rule at the right layer.

Why this lesson matters

Many auth discussions get stuck in acronym fights: RBAC vs ABAC, app-layer checks vs database enforcement, simple role lists vs policy engines. That is understandable, but it is not how strong systems are usually built.

The stronger earlier auth lessons in this course keep asking one practical question: “what job is this layer actually doing?” This lesson does the same thing for authorization design as a whole.

The design rule Put coarse rules where they are cheap, fine rules where they are explicit, and non-negotiable data boundaries where the database can enforce them.

The trap of single-model thinking

The tempting wrong answer is: “pick one model and use it everywhere.” Real systems usually need more honesty than that.

Roles are readable and easy to attach to methods. Permissions express real business capabilities. Locations add the “where” dimension. RLS gives the database authority to refuse out-of-scope rows even if app code slips. The blend is not accidental overlap. It is boundary design.

Why the blend makes sense here

If the rule is coarse and method-shaped, RBAC is a good fit. If it is capability-shaped, permissions help. If it is scope-shaped, access paths matter. If it is a hard data boundary with high blast radius, the database is the right final gate.

That is why this repo does not sound “pure” in architecture-theory terms. It sounds practical, because each layer is carrying the kind of rule it is best at enforcing.

Backend use case When someone asks “why not just use roles?” or “why not let the DB do everything?”, this lesson gives you the repo-grounded answer instead of a generic security slogan.

Common mistake Treating every access rule as either purely role-based or purely row-based, instead of recognizing that different rules belong at different layers.

RBAC, ABAC, and the repo blend

Read the general models, then come back and classify which parts of this repo feel role-based, attribute-like, or database-enforced.

→ NIST — RBAC
→ NIST — ABAC

The answer you want ready in interviews

A strong senior answer is not “we use RBAC and RLS.” It is: “we use a layered authorization model because different rules are cheaper, clearer, and safer at different layers.”

That answer sounds grounded because it explains the design pressure, not just the nouns.

Check yourself (from memory)

Q1. The best explanation of this repo’s authz design is…

The blend is deliberate boundary design, not random overlap.

Why does this repo use roles, permissions, location scope, and RLS together?

recall, then click to reveal

Because roles are good coarse gates, permissions express explicit capabilities, locations add scoped context, and RLS enforces the hardest data boundary at the database layer.

Want me to turn the whole authz model into a “which layer should own this rule?” checklist? Ask me.

Sources. NIST RBAC/ABAC; repo permission and RLS design.