Static authorization decides access from predefined authorization data: explicit permissions, group memberships, and role assignments. The relevant facts are stored before a request arrives, rather than drawn from changing details around that request. Unix file permissions, access control lists (ACLs), and role-based access control (RBAC) are familiar forms. This approach gives an organization a concrete starting point for answering who may perform which actions on which resources. section 1.2 section 5.4
An ACL attaches permissions directly to a resource, making its allowed actions comparatively visible. RBAC inserts roles between people and permissions, aligning access with organizational responsibilities and reducing the need to assign every permission individually. Both models can be efficient to evaluate at runtime and can fit systems with stable responsibilities and clearly bounded access needs. RBAC can also support governance mechanisms such as role hierarchies and separation-of-duty constraints. section 5.4 section 1.2
From a small product to scattered checks
A young SaaS organization might begin by hardcoding dashboard access for known staff and relying on folders for customer-data separation. Growth changes the decision surface: contractors need limited support access, sales needs regional account access, engineers need project-scoped staging access, and Finance needs compliance visibility. Adding one-off conditionals in APIs, databases, and frontend code can produce undocumented, inconsistent rules. Static models provide a structured alternative to purely ad hoc checks, but still require deliberate policy definition and maintenance. section 5.0 section 5.4
Static authorization becomes difficult when stored assignments must represent changing business situations:
- Permissions can outlive a person’s job or employment, leaving principals with access they no longer need. section 1.2.6
- Large group hierarchies and ACLs distributed across systems can obscure who has access, why access exists, and what removing a group would change. section 1.2.7
- Fine-grained requirements—temporary external sharing, delegation, regional rules, approval workflows, or device conditions—can create more roles, groups, checks, and special cases. section 1.5.2
- Offboarding, temporary access, exception handling, audits, and permission-failure diagnosis shift recurring work onto support, engineering, and governance processes. section 1.5.1
The central trade-off is stability versus adaptability. Static models express known permissions well, but do not natively account for dynamic context. A zero-trust posture requires checking each access request; static tools can support parts of that effort, yet managed-device checks, just-in-time escalation, and similarly contextual controls may demand bespoke integrations or custom programming. As access logic spreads across applications, embedded lists and checks also make consistent review and explanation harder. section 1.2.6 section 1.2.7 section 5.4
Static authorization is therefore most suitable where access responsibilities are stable, resources are clearly bounded, and straightforward assignments can be reviewed and maintained. When access depends on current relationships, resource state, device posture, time limits, approvals, or other request context, organizations may need more expressive approaches that evaluate policy against current facts at runtime. The application still enforces the resulting decision; making decision logic explicit can make it more reviewable and changeable. section 5.4 section 1.5.2
Figure 1.4 As an organization grows, the number of access policies tends to increase faster than linearly. Although a small organization might manage with a simple, flat set of policies, larger organizations face compounding complexity due to team structures, regional compliance, and overlapping responsibilities, leading to superlinear policy growth.
Policy growth can compound as teams, regions, compliance requirements, and overlapping responsibilities expand, making simple flat assignments harder to sustain. section 1.5.1
