External Authorization Management Systems: Choosing the Right Platform for Your Architecture

Abstract#

Building custom authorization works for many applications. But distributed systems increasingly benefit from dedicated authorization infrastructure that handles policy evaluation, relationship management, and fine-grained access control as a service. This post maps the current platform landscape, compares architectural approaches, and provides a decision framework for choosing between AWS Verified Permissions, SpiceDB, OpenFGA, Cerbos, OPA, and other platforms. It is the first post in a series that dives deeper into specific platforms and policy languages.

Note: This post complements the Scalable Permission Systems series, which covers building authorization internally with TypeScript and CASL. Here we address the question: when should you stop building and start integrating an external authorization system?

The Authorization Landscape#

The external authorization space has shifted significantly. Understanding these changes helps frame why platform selection matters more than ever.

Key Industry Shifts#

OPA/Styra disruption: Apple acqui-hired Styra's co-founders and core team. Styra DAS (the commercial OPA management platform) is transitioning to community-maintained open source as enterprise commercial support ends. OPA remains under CNCF governance, but enterprise users face uncertain commercial support. Many are evaluating alternatives like Cerbos, Cedar, and Permit.io.

ReBAC mainstream adoption: Google Zanzibar-inspired systems (SpiceDB, OpenFGA, Permify) have moved from academic curiosity to production infrastructure. OpenAI uses SpiceDB for ChatGPT Enterprise connectors, handling tens of billions of fine-grained permissions.

Policy language fragmentation: Cedar (AWS), Rego (OPA/CNCF), Polar (Oso), OpenFGA DSL, and Cerbos YAML/CEL represent a Cambrian explosion of policy languages. The industry has not converged on a standard, though Cedar and OpenFGA DSL are gaining momentum.

Non-human identity explosion: AI agents, service accounts, and machine identities now significantly outnumber human users in many enterprises. Authorization systems must handle agent-to-agent delegation and continuous policy enforcement -- requirements that most legacy systems were not designed for.

AWS Verified Permissions price reduction: AWS reduced pricing for single-authorization APIs (IsAuthorized, IsAuthorizedWithToken) by up to 97% to $5 per million requests in the published US rate card. Batch APIs (BatchIsAuthorized, BatchIsAuthorizedWithToken) and policy management APIs use separate per-call or tiered schedules. See Amazon Verified Permissions Pricing. This makes cloud-native fine-grained authorization economically viable for many high-volume applications when you model the right API mix.

Market consolidation: Permify was acquired by FusionAuth. WorkOS acquired Warrant (Zanzibar-based FGA). Auth0 FGA is now marketed as Okta FGA. The space is consolidating around a few well-funded players.

Authorization Models#

Before evaluating platforms, it helps to understand the authorization models they support. Most production systems end up combining multiple models.

RBAC (Role-Based Access Control)#

Roles are assigned to users. Permissions are attached to roles. This works well when roles are stable and access does not depend on resource context. It breaks down with dynamic access requirements, multi-tenancy, and resource-level sharing. Every platform supports RBAC as a baseline. The question is what you need beyond it.

ABAC (Attribute-Based Access Control)#

Decisions are based on attributes of the user, resource, action, and environment. ABAC excels at conditional logic: time-based access, location restrictions, compliance rules. Policy languages like Cedar, Rego, and Cerbos YAML/CEL express ABAC well. The trade-off: ABAC is more expressive but harder to audit and reason about than RBAC.

ReBAC (Relationship-Based Access Control)#

Access is determined by relationships between entities. This is the Google Zanzibar paradigm: "User X is editor of Document Y, which is in Folder Z." Platforms like SpiceDB, OpenFGA, and Auth0 FGA implement ReBAC natively. The trade-off: ReBAC is excellent for collaborative applications but requires maintaining a relationship graph, which introduces the dual-write problem.

Combined Approach#

In practice, mature systems combine multiple models:

• RBAC as the baseline framework
• ABAC for contextual conditions (time, IP, risk score)
• ReBAC for resource-level sharing and inheritance
• ACL as a local override on specific resources

Platforms like Permit.io and Oso Cloud are designed explicitly for this combined approach. Others require layering multiple systems together.

Platform Overview#

Cloud-Native Platforms#

AWS Verified Permissions + Cedar

Cedar is declarative, formally verified, and fast. Benchmarks show it evaluating policies 28-35x faster than OpenFGA and 42-80x faster than Rego. Note that these benchmarks compare fundamentally different architectures: Cedar evaluates local policies while OpenFGA traverses a relationship graph, so direct speed comparisons should be interpreted with that context. Single authorization APIs are $5 per million requests after the reduction; batch and policy management rates differ. See Amazon Verified Permissions Pricing and AWS Cognito + Verified Permissions for SaaS for a cost breakdown.

Integration is native with Cognito, API Gateway, AppSync, and Lambda. The main limitation is that Cedar is ABAC-focused with no built-in relationship graph. If you need Google Docs-style sharing, Cedar alone is insufficient.

Best for: AWS-native applications needing policy-as-code with formal guarantees.

For AWS-native SaaS products, Cognito and Verified Permissions form a complete authorization stack. Cognito handles authentication and tenant-aware token generation, while Verified Permissions makes fine-grained authorization decisions using those tokens. For a deep dive into this integration pattern, see AWS Cognito + Verified Permissions for SaaS.

Microsoft Entra ID

Entra ID is an identity platform with coarse-grained authorization capabilities. It is not a fine-grained authorization engine. The Conditional Access engine evaluates signals in real time: user identity, device state, IP location, sign-in risk, and application context. It answers the question "can this user access this application?" -- not "can this user edit this specific document."

What Entra provides: app roles as JWT claims for simple RBAC, group-based authorization, custom security attributes (P2 feature), Entra External ID for B2C/B2B, Workload ID for non-human identities, and Permissions Management (CIEM) across AWS, Azure, and GCP.

What Entra does not provide: fine-grained application-level authorization (ABAC/ReBAC), policy-as-code engines, or relationship-based access control. For resource-level decisions like "can user X edit row Y in tenant Z," you need an external authorization system.

The production pattern is hybrid: Entra handles identity verification, session management, and risk assessment. An external PDP (Cerbos, OPA, AWS Verified Permissions, or SpiceDB) then makes fine-grained authorization decisions using Entra's JWT token claims plus resource context.

Best for: Microsoft-ecosystem enterprises needing workforce identity, Conditional Access, and compliance -- paired with an external authorization system for fine-grained decisions.

Google Cloud IAM + Identity Platform

Firebase Authentication with Identity Platform supports SAML, OIDC, multi-tenancy, and MFA. But Google does not offer a dedicated fine-grained authorization service comparable to AWS Verified Permissions. Custom claims on tokens work for simple RBAC but do not scale for complex authorization models.

Best for: Firebase/GCP applications with simpler authorization requirements.

Third-Party Platforms#

Auth0/Okta FGA -- Built on OpenFGA (open-source, Zanzibar-inspired). Supports up to 100 billion relationships and 1 million requests per second with a 99.99% SLA. ReBAC-focused with limited ABAC capability. Best for organizations already using Auth0/Okta.

SpiceDB/Authzed -- The most mature open-source Zanzibar implementation. Used by OpenAI for ChatGPT Enterprise, handling tens of billions of permissions. ZedTokens provide consistency guarantees. ReBAC-focused; ABAC requires workarounds. Self-hosted requires PostgreSQL/CockroachDB and Kubernetes expertise. For a detailed comparison with Auth0 FGA, see SpiceDB vs Auth0 FGA: Relationship-Based Authorization.

Cerbos -- Purpose-built application authorization engine using YAML and CEL. Deploys as a single binary, container, or sidecar. Low learning curve. No built-in relationship graph; must be paired with another system for ReBAC. Best for teams wanting policy-as-code without learning Rego or Cedar.

OPA (Open Policy Agent) -- CNCF graduated project and general-purpose policy engine. Rego is powerful but has a steep learning curve (~30-40 hours to proficiency). The Styra acqui-hire has created uncertainty around commercial support. Best suited for infrastructure policy (Kubernetes admission control) where it has strong ecosystem support.

Permit.io -- Authorization-as-a-service built on OPAL. Multi-engine support: OPA, OpenFGA, or Cedar as backend engines. Best for teams wanting flexibility to switch engines without full rewrites.

Keycloak -- CNCF incubating project for identity and access management. Java-based and resource-heavy (512MB-2GB RAM per instance). Not purpose-built for fine-grained authorization. Best for organizations needing self-hosted IAM with built-in authorization capabilities.

WorkOS FGA -- Acquired Warrant (Zanzibar-based FGA). Extends RBAC with hierarchical, resource-scoped access control. Integrated with SSO (SAML), Directory Sync (SCIM), and Audit Logs. Best for B2B SaaS applications needing integrated identity and fine-grained authorization.

Architecture Patterns#

How you deploy the authorization engine matters as much as which engine you choose. There are five common patterns, and most production systems end up with a hybrid approach.

Centralized PDP#

A single authorization service evaluates all requests. All services call it via API.

• Pros: Single source of truth, easy to audit, simple policy management
• Cons: Single point of failure, network latency on every request, scaling bottleneck
• Use when: Low authorization volume, simple deployments, small service count

Sidecar PDP#

The authorization engine is deployed as a sidecar container alongside each service. Policies sync from a central management plane.

• Pros: Low latency (local evaluation), resilient (no network dependency for decisions), scales with services
• Cons: Resource overhead per pod, policy sync complexity, eventual consistency
• Use when: Kubernetes environments, high authorization volume, latency-sensitive workloads

Embedded Library PDP#

Authorization logic runs as an in-process library (Casbin, CASL, Cedar SDK). No network call for authorization decisions.

• Pros: Fastest evaluation (no IPC or network overhead), no additional infrastructure
• Cons: Language-specific, harder to manage policies across services, no centralized audit
• Use when: Single-language stack, simple policies, performance-critical paths

API Gateway Authorization#

Coarse-grained authorization at the gateway level combined with fine-grained authorization at the service level. A two-tier approach where the gateway handles "can this user access this API?" and the service handles "can this user perform this specific action?"

• Implementations: AWS API Gateway + Cognito Authorizer + Verified Permissions, Kong + OPA plugin

Hybrid Pattern#

This is what most mature organizations use. It combines multiple patterns:

• Coarse-grained RBAC at the API gateway
• Fine-grained ABAC/ReBAC via sidecar or embedded PDP
• Relationship data synced from a centralized authorization service
• Audit trail aggregated centrally

The hybrid pattern provides the best balance of performance, flexibility, and operational manageability. Starting with the API gateway for coarse checks keeps the fine-grained authorization volume manageable.

Cost Analysis#

Cost depends on authorization volume, operational overhead, and team expertise. The following table compares approximate monthly costs at 100 million authorization decisions per month.

Tip: These numbers represent infrastructure costs only. Factor in team learning time for the policy language, integration development, and ongoing policy maintenance. A "free" open-source solution that requires 3 months of engineering time to operationalize is not free.

Decision Framework#

Build vs. Integrate#

The first decision is whether you need an external authorization system at all.

Managed vs. Self-Hosted#

Platform Selection Matrix#

*Styra DAS (the managed OPA option) is transitioning to community-maintained open source as enterprise commercial support ends following the Apple acqui-hire.

Tip: Policy language choice is one of the most consequential decisions in this space. Switching from Rego to Cedar (or vice versa) means rewriting every policy. For a detailed comparison of Cedar, Rego, OpenFGA DSL, and Cerbos YAML/CEL with side-by-side code examples, see Policy Language Comparison: Cedar vs Rego vs OpenFGA.

Common Pitfalls#

Choosing a Platform Before Understanding Your Model#

Teams often pick a tool first and then try to fit their requirements into it. A team choosing SpiceDB because it sounds impressive will struggle if their authorization is primarily attribute-based. Start by defining your authorization model (RBAC, ABAC, ReBAC, or hybrid), then select the platform that supports it natively.

Underestimating the Dual-Write Problem#

External relationship stores require keeping authorization state synchronized with application data. Without a strategy (outbox pattern, CDC, reconciliation), authorization decisions will drift from application reality. Budget meaningful engineering time for this. For a detailed walkthrough of the dual-write problem with implementation patterns, see SpiceDB vs Auth0 FGA: Relationship-Based Authorization.

Over-Engineering for Simple Applications#

A monolithic application with straightforward roles does not need SpiceDB or AWS Verified Permissions. A library like CASL or a simple middleware-based approach is sufficient. External systems add value when authorization crosses service boundaries.

Ignoring Policy Language Lock-In#

Switching policy languages means rewriting every policy. Choose a policy language you can commit to for years, or use an abstraction layer (like Permit.io) that supports multiple engines. Factor the team's learning investment into this decision.

Neglecting Policy Testing#

Authorization policies are code. They need unit tests, integration tests, and CI/CD pipelines. All major platforms support policy testing, but teams frequently skip it. Untested authorization policies are a security liability.

Ignoring Vendor Stability#

The OPA/Styra acqui-hire demonstrates that open-source projects with commercial backers can face disruption. Evaluate the governance model (CNCF, independent foundation, single-vendor) when choosing platforms. Strong open-source foundations provide insurance against vendor instability.

RBAC Ceiling#

Starting with RBAC is fine, but plan for the inevitable "we need one exception" moment. Choose platforms that support multiple authorization models rather than RBAC-only solutions. The cost of migrating from a RBAC-only system to a multi-model platform grows exponentially with time.

Conclusion#

There is no universal best authorization platform. The right choice depends on your authorization model, cloud environment, team expertise, and scale requirements.

The key insights from evaluating the landscape:

1. Cedar and OpenFGA DSL are emerging as the leading policy languages -- Cedar for ABAC-focused workloads with formal verification needs, OpenFGA DSL for ReBAC-focused workloads at scale.

2. External authorization adds value at the microservices boundary. For monolithic applications, embedded libraries like CASL and Casbin remain simpler and sufficient.

3. Plan for non-human identities from day one. AI agents and service accounts need authorization policies. Systems designed only for human users will require expensive retrofitting.

4. The dual-write problem is the hidden cost of external authorization. Budget engineering time for synchronization, consistency, and reconciliation.

5. Policy-as-code is non-negotiable. Regardless of platform choice, authorization policies must be version-controlled, tested, and deployed through CI/CD.

6. The market is consolidating. Smaller players are being acquired, and commercial sponsors are shifting. Choose platforms with strong governance or open-source foundations.

Start by defining your authorization model. Then evaluate platforms against that model. Run a proof of concept with your most complex authorization scenario before committing. The cost of switching authorization platforms in production is significant -- invest the time upfront to make the right choice.

This is the first post in the External Authorization Systems series. Upcoming posts cover AWS Cognito + Verified Permissions for SaaS, SpiceDB vs Auth0 FGA, and Cedar vs Rego vs OpenFGA policy language comparison.

References#

• Cedar Policy Language Documentation - Official Cedar language reference, grammar specification, and policy writing guides
• AuthZed SpiceDB GitHub Repository - Open-source Google Zanzibar-inspired authorization system with documentation and examples
• OpenFGA Documentation - Open-source Zanzibar-inspired authorization engine powering Auth0/Okta FGA
• Okta Fine Grained Authorization - Auth0/Okta FGA product overview and architecture documentation
• Cloud Native Now - Apple Buys Styra Brains, OPA Remains Open - Coverage of the OPA ecosystem disruption following Apple's acqui-hire
• Cerbos - Framework for Evaluating Authorization Providers - Vendor-neutral evaluation criteria for authorization platforms
• Permit.io - Policy Engine Showdown: OPA vs. OpenFGA vs. Cedar - Comprehensive policy engine comparison with syntax examples
• Teleport - Security Benchmarking Authorization Policy Engines - SPEF framework benchmarking Rego, Cedar, OpenFGA, and Teleport ACD
• OWASP Microservices Security Cheat Sheet - Authorization patterns for microservices including PDP/PEP/PIP
• Amazon Verified Permissions Pricing - Single versus batch authorization and policy management rates
• AWS - Amazon Verified Permissions reduces authorization request price - Announcement of the single-authorization API price reduction (up to 97%)
• Microsoft Learn - Conditional Access Overview - Entra ID Conditional Access policies, signal evaluation, and Zero Trust enforcement