Authorisation is the process of determining whether an already identified and authenticated subject is permitted to perform a particular action on a particular resource under particular circumstances. It answers the question “What are you allowed to do?” rather than “Who are you?” A subject can be a human user, application, service, device, process, or workload, while a resource can be a file, database record, API endpoint, cloud object, administrative function, network service, or business operation.
The decision normally evaluates a requested action, the subject's identity or attributes, the target resource, applicable policies, and sometimes environmental information such as time, network location, device state, transaction value, or risk level. Authorisation therefore represents a policy decision rather than merely a credential check. In a mature security architecture, authentication establishes an identity context, authorisation evaluates that context against policy, and an enforcement component permits or denies the requested operation.
Authorisation can be implemented using many policy models. Access control lists associate permissions with individual subjects or groups for particular objects. Role-based approaches assign permissions to roles and assign users or other subjects to those roles. Attribute-based approaches evaluate properties of the subject, resource, action, and environment against policies. Rule-based systems use explicit conditions or rules to determine decisions, while capability-based systems provide possession of an unforgeable or suitably protected capability as evidence of authority to perform an operation.
Mandatory access control can impose centrally administered classifications and clearances, while discretionary access control allows resource owners or delegated administrators to control permissions within defined limits. These models can coexist within one system; for example, an application may use roles for broad business permissions while evaluating resource attributes and transaction context before approving an individual operation.
A typical authorisation architecture separates the policy decision from policy enforcement. A Policy Enforcement Point, or PEP, intercepts a request and enforces the result, while a Policy Decision Point, or PDP, evaluates the applicable policy. Supporting components may supply identity information, resource attributes, environmental context, entitlement data, or policy information. A decision might conceptually contain a result such as Permit or Deny, together with obligations or additional requirements.
In distributed systems, the enforcement point may be an API gateway, application middleware, database layer, operating-system security mechanism, cloud service, or service mesh component. Separating decision logic from enforcement can improve consistency and centralised policy management, but it also introduces availability, latency, policy-distribution, and failure-mode considerations. A secure architecture must define what happens when the policy engine is unavailable and must avoid accidentally converting an authorisation failure into permissive access.
Authorisation decisions commonly involve the principle of least privilege, which means granting only the permissions required for an identity or process to perform its legitimate duties. Least privilege reduces the number of operations available to a compromised account and therefore can limit the consequences of credential theft, software vulnerabilities, insider misuse, and accidental actions.
Related concepts include separation of duties, which divides sensitive responsibilities between different people or identities, and need-to-know, which limits access to information according to an operational requirement. Just-in-time access can provide temporary privileges only when needed, while just-enough-access limits the scope of those temporary permissions. These mechanisms are particularly useful for administrative operations because persistent broad privileges create a larger attack surface than narrowly scoped permissions that are granted for a limited purpose and duration.
Authorisation is often resource-specific and operation-specific rather than simply being a property of an account. For example, a user might be permitted to read a customer record but not delete it, permitted to update an order but not alter its financial value, or permitted to access one project but not another. API authorisation therefore frequently distinguishes HTTP or application operations such as read, create, update, and delete, although real business systems often require much finer-grained permissions.
Object-level authorisation is especially important in applications where users can manipulate identifiers supplied by clients; an application that correctly authenticates a user but fails to verify whether that user is authorised to access the requested object can expose data through an insecure direct object reference or related broken-access-control vulnerability. Authorisation must consequently be enforced server-side and cannot safely rely solely on interface elements such as hidden buttons or disabled menu items.
Authorisation policies can become complex because permissions may depend on organisational relationships, ownership, delegated authority, transaction states, legal requirements, geographic restrictions, or temporal conditions. A manager might approve expenses for members of their department but not their own expenses; a clinician might access records for patients under their care but not unrelated records; or a service account might access production data only through a particular application and only for specific operations.
Policy engines may therefore need hierarchical relationships, attribute evaluation, policy precedence, deny rules, conflict resolution, and obligations. Poorly designed policies can create privilege accumulation, unexpected inheritance, conflicting rules, excessive administrative complexity, or unanticipated access paths. Effective authorisation engineering requires both technical correctness and a clear representation of the underlying business authority model.
Authorisation also has an important relationship with auditing and accountability. A system should be able to determine not only whether an operation was permitted but which identity requested it, what resource and action were involved, which policy or entitlement produced the decision, and when the event occurred. Audit records can support incident investigation, compliance requirements, fraud detection, and access reviews, although logging sensitive information requires appropriate privacy and security controls.
Periodic access certification can compare actual permissions with current business requirements and identify stale entitlements. Authorisation systems should also account for changes in employment, organisational roles, project membership, resource ownership, and application status so that permissions do not remain indefinitely after the underlying business justification has disappeared.
Authorisation is distinct from authentication, accounting, and identity management even though these functions interact closely. Authentication establishes evidence of identity, authorisation evaluates permission, and accounting or auditing records relevant activity. Identity and access management provides broader lifecycle and governance capabilities for identities, credentials, entitlements, and policies. Common misconceptions include assuming that being authenticated means being authorised, assuming that membership of a group always implies unrestricted access to all associated resources, or treating client-side access restrictions as sufficient security controls. Authorisation is ultimately a policy enforcement problem: a secure implementation must make explicit what is permitted, under which conditions, to which subject, against which resource, for which operation, and for how long, while ensuring that every relevant access path consistently enforces the resulting decision.
