Access control is the strategy for managing access to systems, data, and resources. It combines policies, rules, and mechanisms that decide who may access what, when, and under which conditions. Authorization is the enforcement mechanism: it answers whether a requested action should be allowed now, using identity, attributes, and policy. section 4.3 section 4.3.2
Authentication establishes confidence in the requester; access control determines the requester’s permitted actions. A correct policy can still produce a dangerous result when authentication accepts a stolen or otherwise false identity, so authorization depends on reliable identity, enrollment, and relationship context. section 2.3.2 section 3.9
An access decision can draw on several kinds of context:
- Roles and permissions, such as allowing a project manager to view dashboards and assign tasks. section 4.2 section 4.3.2
- Attributes of the principal, resource, or environment, including department, classification, location, time, and risk score. section 4.3.2
- Relationship boundaries, such as contractor status, sponsor, project scope, and an access expiration date. section 3.4.3
- Policies that combine these signals into real-time, context-aware decisions rather than relying only on static lists or groups. section 1.7 section 4.1
Authenticated is not automatically authorized
A call center agent may authenticate successfully yet receive sensitive customer data only during an assigned shift. Likewise, a strongly authenticated contractor remains limited by the relationship established at enrollment; strong proof of identity does not make the contractor an employee. section 4.2 section 3.4.3
Figure 1.1 Embedding access logic throughout application code (left) creates tight coupling. Externalizing authorization into a separate component (right) makes access policies explicit, decouples decision-making from application behavior, and enables scalable, auditable access control.
Externalizing authorization into a separate component makes policies explicit, separates access decisions from application behavior, and supports scalable, auditable control. section 1.1
Static access-control lists and group permissions can become opaque across distributed organizations, making it hard to determine who has access or whether policy is applied consistently. Policy-based authorization makes access logic adaptable and can support testing, version control, automation, audits, compliance changes, and more precise customer-facing features. section 1.2.7 section 1.7
Weak boundaries have direct consequences. In the Target breach, compromised vendor credentials were extended beyond legitimate billing and project work toward payment systems. In the Ring case, authenticated employees and contractors lacked meaningful limits on access to private customer video feeds. Access control must therefore limit access by resource, purpose, context, and relationship—not merely recognize an account. section 1.0 section 4.0
