This lesson's interactive features are locked, please to keep using them
Access Control Models
Once an application has more than a few protected routes, repeated and inconsistent authorization checks become hard to keep track of. An access control model gives those checks a consistent structure.
Role-Based Access Control
Role-Based Access Control (RBAC) assigns permissions to roles, then roles to users. For example, you may have roles like:
developerfor API access but no financial dataaccountantfor financial-only accessownerfor complete ownership of all resources
Instead of hard-coding 14 different if/else permission checks into every route, you can write a shared helper that accepts the current user and the allowed roles, then rejects the request if the user's role isn't allowed.
Keep Policies Centralized
Centralization doesn't change who is allowed to do what. It makes authentication and role evaluation easier to find, review, and apply consistently. Poorly organized code isn't inherently insecure, but it's more likely to become insecure as it changes.
Scattered copies of a policy drift. One copy gets a bug fix, another doesn't. One is written as an allowlist that denies by default, another only checks the roles its author was thinking about that day and quietly lets everyone else through. A single shared helper means there's one place to get it right.
RBAC works well when permissions follow stable job functions. Its tradeoff is rigidity. As systems grow, teams sometimes invent increasingly specific roles like admin-read-only, editor-plus, or support-admin. That can lead to role explosion.