Why PBAC?
PBAC is an authorization server — not a policy engine, not a library you embed in each application, and not an add-on to your identity provider. It makes policy decisions at the token layer, so every application that speaks OAuth gets centralized authorization without per-app integration.
You already have identity. You don't have authorization.
Your organization runs an identity provider — Okta, Azure AD, or something similar — that handles authentication. But authentication answers "who is this?" Authorization answers "what can they do?" and that question is still answered differently by every application. PBAC is the missing layer between your IdP and your applications.
How PBAC compares
vs. running OPA yourself
OPA (Open Policy Agent) is a general-purpose policy engine — and it is the engine inside PBAC. But OPA has no opinion about identity, tokens, or federation. If you run OPA directly, you build everything that connects it to the real world: OAuth flows, client registration, token issuance, introspection, bundle serving, and audit logging.
PBAC is the opinionated application layer on top of OPA. You get OPA's policy evaluation integrated into standard OAuth token flows — policy evaluated at token issuance and re-evaluated at token use — with federation, client management, and audit built in.
Choose OPA directly if your need is purely infrastructure policy (Kubernetes admission control, API gateway rules). Choose PBAC if you need application-level authorization tied to identity and tokens.
vs. authorization libraries (Oso, Permit.io, Cerbos)
These products are authorization sidecars or SDKs — you integrate them into each application, and each application calls the service to check permissions. The authorization decision happens inside or alongside your application code. You still need your own OAuth infrastructure, token management, and federation.
PBAC makes policy decisions at the protocol layer — at token issuance and at token introspection. One enforcement point for all applications, not one integration per application.
Choose an authz library if you are building a single application and want fine-grained permissions within that application's data model. Choose PBAC if you have many applications and want centralized policy enforcement without integrating an SDK into each one.
vs. your IdP vendor's add-on (Okta FGA, Microsoft Entra)
IdP vendors offer fine-grained authorization features as extensions to their identity platforms. These work well within a single vendor's ecosystem. But if your organization uses multiple identity providers — common after acquisitions, in federated sectors, or in multi-cloud environments — a single vendor's add-on cannot serve as the unified policy plane.
PBAC federates across any OIDC-compliant identity provider. It is the authorization layer that sits above all of your IdPs, not an extension of one. Even in a single-IdP environment, PBAC separates your authorization decisions from your identity vendor — your policies are portable (OPA Rego, not a proprietary format), your audit trail is independent, and you avoid deepening a dependency that becomes costly to unwind. Authentication is not authorization, and coupling them to the same vendor means you cannot change one without disrupting the other.
Choose PBAC when you want authorization that is independent of your identity vendor — whether you have one IdP or many. The multi-IdP case makes the value obvious, but the single-IdP case is where organizations most often regret the coupling later.
vs. building it yourself
The most common alternative. An internal team builds custom authorization logic — middleware, database-backed role tables, and conditional checks — over 12 to 18 months. The initial build is the easy part. The ongoing cost is in maintenance: OAuth spec changes, audit infrastructure, federation when the business requires it, and AI agent authorization patterns that did not exist when the system was designed.
Choose to build only if your authorization requirements are genuinely unique and cannot be served by a configurable policy engine (this is rare). Choose PBAC if you want standards-compliant, auditable, federation-ready authorization from day one.
Starting small
PBAC does not require you to migrate your entire authorization stack on day one. Common starting points:
- Single application — Even if you start with one application, PBAC's AuthZEN evaluation endpoint (
/access/v1/evaluation) gives you a direct policy decision API that any application can call — no OAuth token flow required. You get centralized policy, audit, and a path to expand to more applications without rearchitecting. - Infrastructure and API gateway policy — PBAC includes a direct OPA evaluation pathway. If your starting need is API-level policy decisions, you can use PBAC as the policy management and audit layer while calling OPA directly for infrastructure concerns.
- Alongside your IdP vendor's authorization — PBAC complements existing authorization features. Start by federating the cases your IdP vendor cannot handle (cross-org, cross-IdP, AI agents) and expand from there.
The value of PBAC grows with every application and trust boundary you bring under one policy plane — but you do not have to start with all of them.
What you'd have to build
If you choose "just use OPA directly," here is what you would need to build, operate, and maintain alongside your Rego policies. PBAC provides all of these out of the box.
| Category | What PBAC provides | What you'd build with OPA alone |
|---|---|---|
| Token issuance | 4 OAuth grant types (client credentials, authorization code, refresh token, token exchange), PKCE, DPoP sender-constrained tokens, Rich Authorization Requests, OpenID Connect ID tokens | A complete OAuth 2.0 authorization server — token generation, code lifecycle, PKCE verification, key management |
| Token validation | Introspect endpoint with real-time policy re-evaluation, RS-supplied transaction context, JIT single-use tokens | An introspection service, OPA query integration, context merging logic, token revocation |
| Client management | Admin API, Dynamic Client Registration (RFC 7591), CIMD zero-config registration, software statement validation, BCrypt secret hashing | A client registry, registration endpoint, secrets management, JWT validation |
| Policy management | OPA bundle server with long-polling, policy data PATCH API, policy rule CRUD, extension hooks, data.oauth_config anti-recursion synthesis | Bundle packaging and serving, a data management API, Rego module composition |
| Identity federation | Multi-IdP support, OIDC discovery, dynamic IdP selection by policy, id_token signature verification, UserInfo endpoint | An OIDC relying party, IdP routing logic, JWKS fetching, callback handling |
| Delegation | Token exchange (RFC 8693), composite tokens with act claim, cross-domain id_token exchange, trust tiers | Delegation chain validation, scope down-scoping, composite token generation |
| Access evaluation | AuthZEN /access/v1/evaluation endpoint, obligation orchestration (consent, step-up auth, RS obligations) | An evaluation API, obligation state machines, external redirect handling |
| Audit | Every decision logged with full PDP input and output, filterable audit API | Audit logging infrastructure, query API, storage |
| Security | HTTPS-only jwks_uri, PKCE enforcement, DPoP replay protection, refresh token rotation, admin key separation, bundle key separation | Each security measure implemented individually |
| Standards | OAuth 2.0/2.1, OIDC, RFC 7591, RFC 8693, RFC 8707, RFC 9396, RFC 9449, UMA 2.0, CIMD, MCP Authorization | Each RFC read, interpreted, and implemented |
The total: Teams that build their own authorization layer with OPA typically spend 12-18 months before reaching feature parity with what PBAC provides on day one. OPA is an excellent policy engine — PBAC handles everything around it so you can focus on writing policies, not building infrastructure.
Next steps
- How it works — Understand the access model
- Start Here — Try PolicyArc end-to-end from the dashboard
- Use Cases — See how PBAC applies to your sector