PBAC

How it works

PBAC (Policy-Based Access Control) moves the authorization decision into an external policy engine, expressed as code, that your application queries at runtime. Instead of hardcoding if user.role == admin throughout your services, the app sends the decision point a request (here is the user, the resource, the action, and the context) and gets back allow or deny. The policy lives in version control, is tested and reviewed like any other code, and deploys independently of the app. The two engines to know are the Open Policy Agent (OPA, with its Rego language) and AWS Cedar.

When it matters

PBAC matters when authorization logic is duplicated across many services and you want one governed, testable, versioned source of truth instead of scattered if statements. Because a policy can read roles, attributes, and relationships, PBAC in practice subsumes RBAC, ABAC, and ReBAC: those describe what the rules are made of, PBAC describes how you deliver and govern them. See RBAC vs ABAC vs ReBAC vs PBAC.

Common misconceptions

• "PBAC is the same as [ABAC](/glossary/abac/)." ABAC is a rule model; PBAC is the delivery pattern (policy-as-code) that can express ABAC, RBAC, and ReBAC.
• "You need PBAC from day one." For one small app it is overkill; adopt it when policy sprawls across services.
• "Externalizing policy slows every request." Engines like OPA and Cedar are built for low-latency, in-process decisions.