Authentication & Authorization Architecture · Authorization at Scale
Centralized Authorization and Policy Engines
Externalize authorization decisions with OPA, Cedar, OpenFGA and friends.
As systems grow, authorization rules scattered across services drift. Policy engines externalize decisions: services (policy enforcement points) ask a decision point "can user X do action Y on resource Z?". Options: OPA/Rego (general-purpose policies), Cedar (AWS Verified Permissions; readable, analyzable policies), OpenFGA/SpiceDB (ReBAC graphs). Benefits: consistency, auditability and policy testing; costs: latency, data synchronization and another critical dependency.
// Cedar policy example
permit (
principal in Role::"finance-manager",
action == Action::"approveExpense",
resource
) when {
resource.amount <= 5000 &&
resource.department == principal.department
};
forbid (principal, action, resource) when { resource.status == "locked" };
Common pitfalls
- Network round trips on every check without caching or local evaluation.
- Policies depending on data the engine doesn't have.
- No tests for policies (they're code).
Key points
- Decision point vs enforcement point
- OPA, Cedar, OpenFGA/SpiceDB
- Test and version policies like code
Further reading: Cedar policy language
Practice questions
What is the difference between a PDP and a PEP?
Answer
The policy decision point evaluates policies and returns allow/deny; the policy enforcement point (your API or gateway) asks the PDP and enforces the result.
Why can't a policy engine fix broken object-level authorization by itself?
Answer
It only decides on the inputs it's given; services must still call it for every object access with the correct resource and context, and scope data queries accordingly.
Open in the app to mark lessons complete, take notes and track your progress.