It evaluates the subject, resource, operation, and applicable policy, often using roles, attributes, relationships, ownership, risk, or environmental context. The outcome may allow, deny, or constrain the request, and it may be re-evaluated as conditions change.
Authorization can occur after authentication, but the two functions are independent. A service may authenticate a workload yet grant it only a narrow API operation; a public service may authorize limited anonymous access without identifying a person. Sound design evaluates effective permissions at the resource and prevents one component from silently expanding a decision made elsewhere.
Key points
Decision inputsSubject attributes, resource sensitivity, requested operation, policy, delegation, device or session context, and current risk signals.
Possible scopeA whole resource, particular records or fields, defined actions, time windows, transaction limits, or combinations of these constraints.
Ongoing governanceOwners should review grants, inherited permissions, role composition, exceptions, and actual use, then remove access when the need ends.
Important limitationA correct authorization decision has no effect if an application fails to enforce it consistently, trusts user-controlled inputs, or exposes an alternate path around the check.