Authenticated Principal
DevOps & Tooling / Knowledge library
Authorization
Decides whether an authenticated principal may perform an action
Why learn Authorization?
It enforces permissions at protected resources
The problem it solves
It prevents known identities from exceeding allowed access
Where it came from
Authorization is a security concept that decides whether an authenticated principal may perform an action. Its guarantees and tradeoffs depend on the concrete implementation and operating context.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Define Authorization and distinguish it from a neighboring concept.
- Choose a realistic task where Authorization is appropriate.
- Identify a failure mode caused by misusing Authorization.
- Interpret a small design or result involving Authorization.
- Explain one tradeoff or limitation of Authorization.
Documentation and sources
- OWASP Developer Guide: Security Principles (devguide.owasp.org)
Connect the ideas
Explore next
Real World Example
Granular Access Control for Medical Records
Healthcare providers managing sensitive patient data across multi-disciplinary teams.
The business problem
Unauthorized staff members are accessing patient records outside their assigned department, leading to potential privacy violations and compliance failures.
How this topic solves it
Implement Complete Mediation by enforcing authorization checks on every request to ensure that only users with explicit, role-based permissions can access specific patient records.
- Define granular roles such as Physician, Nurse, and Billing Clerk.
- Map each role to specific resource actions like ReadRecord or UpdateBilling.
- Implement a central authorization service that validates the user's token and requested action against the resource policy.
- Enforce the check at the API gateway level to ensure every incoming request is mediated before reaching the database.
- Audit all authorization decisions to ensure compliance with privacy regulations.
This diagram shows how a user request is intercepted and validated against a policy before accessing the patient record.
Enforcement Point
Policy Decision Point
Resource
- User → Request Resource → API Gateway
- API Gateway → Verify Permission → AuthZ Service
- AuthZ Service → Grant/Deny → API Gateway
- API Gateway → Fetch Data → Patient DB
Implementation example
This function maps to the solution by enforcing a check on every request, ensuring that the system fails safe if no explicit permission is found.
function authorize(user, action, resource) {
// Check if the user has the required permission for the specific resource
const hasAccess = policyEngine.check(user.role, action, resource);
if (!hasAccess) {
throw new Error('Access Denied'); // Fail safe: deny by default
}
return true;
}Expected business outcome
A secure environment where access is strictly limited to the minimum necessary information, reducing the risk of unauthorized data exposure.
Limitations and checks
The primary trade-off is latency, as performing a check on every request adds overhead; this can be monitored by tracking the response time of the authorization service.