Authorization is a cornerstone of the Identity and Access Management (IAM) stack. Yet, despite its critical role in securing digital systems, it suffers from a lack of standardized mechanisms, protocols, and formats to communicate authorization-related information across platforms.

This gap has real consequences. According to the OWASP Top 10, Broken Access Control is the #1 security risk in web applications OWASP Top 10:2021 report on Broken Access Control, with an average incidence rate of 3.81% and over 318,000 occurrences in recent datasets. Moreover, 80% of cyberattacks now leverage identity-based techniques 2023 Global Threat Report, and 77% of breaches begin with compromised credentials 2025 roundup by Expert Insights — many of which are exploited due to poor access control.

Clearly, the status quo isn’t working.

At The Beginning, It Was Chaos

Like many organizations, we began our journey with Role-Based Access Control (RBAC), using LDAP groups in Active Directory. This worked well for legacy systems and offered a familiar structure. We even extended this model to our R&D teams, allowing them to define roles and permissions in self service for their applications.

But that’s where the chaos began.

Without governance or consistency, each application implemented authorization differently. Auditing became a nightmare. The number of groups exploded (27247 authorization groups and 705 team groups). Modeling became brittle and unsustainable.

For our business applications, LDAP-based RBAC proved limiting. Years ago, we pivoted to a custom database model, still RBAC-based, but tailored to our needs. Initially, this gave us flexibility. But as our business evolved, so did our requirements — inheritance, delegation, dynamic access — all of which strained the RBAC model to its breaking point.

Two years ago, we asked ourselves:

• Can we improve our LDAP-based model?
• Can we build a scalable DB schema using graph databases?
• Can we adopt an existing solution that’s future-proof?

Two teams — one managing infrastructure access, the other business authorization — reached the same conclusion: we needed to rethink authorization entirely.

Authorization was fragmented across applications, implemented inconsistently, and exposed us to serious security risks.

Enters ReBAC: Relationship-Based Access Control.

ReBAC: Relationship-Based Access Control.

ReBAC offers the fine-grained, context-aware control we needed. It models access based on relationships — between users and resources.

Why the Shift from RBAC to ReBAC?

ReBAC changed the paradigm: instead of asking “Does this role/group allow access?”, we now ask “Can this identity do this action on this resource?”

There are some nice articles on that matter on the web:

• Relationship Based Access Control (ReBAC): The Ultimate Guide
• Authorization Academy — Relationship-Based Access Control (ReBAC)
• How to Implement Relationship Based Access Control (ReBAC)

Why And How We Built AuthZilla

While evaluating various ReBAC solution providers, we found that — even though many offered powerful engines with low latency, high throughput, and intuitive schema definitions — they lacked critical components needed for complex, regulated environments. We weren’t just looking for a high-performance policy engine; we needed a complete authorization solution that could support governance, compliance, and real-world workflows out of the box.

Key Gaps We Identified

So to fulfill these requirements, we built AuthZilla on top of OpenFGA Fine-Grained Authorization | OpenFGA an open source solution, inspired by Google Zanzibar, backed by the CNCF Cloud Native Computing Foundation which gives us a solid foundation.

AuthZilla 🦖 isn’t just a wrapper — it’s an Authorization as a Service platform that transforms OpenFGA into a secure, developer-friendly, governance-ready authorization system. It’s built for scale, compliance, and clarity.

AuthZilla’s Core Principles

• Security-first modeling: Approval and resource provider are enforced at the schema level.
• Governance patterns: Common authorization scenarios are built-in.
• Regulatory compliance: Supports SOX, SOC2, and auditability.
• Event-driven architecture: Change requests and access decisions are tracked and observable.
• Developer-friendly APIs: Easy integration, clear schema, and scalable design.

Some Challenges We Faced

• Schema complexity: Each team had unique requirements and often built their own OpenFGA models. However, understanding relationship graphs and modeling complex business rules was not straightforward. The process should ideally begin by clearly describing the use cases, the specific needs, and the features we aim to implement.
• Modeling ambiguity: Roles, ABAC, LDAP groups — how do we have and build a ubiquitous language that allows teams to understand themselves?
• Global roles vs. local context: We strive to balance the flexibility of defining roles with the clarity of their scope — whether a role applies globally across all domains/namespace or is specific to a particular one.

Some solutions we’ve settled

• Separation of concerns: We decoupled product requirements from the authorization schema. Defining requirements with the schema that implements specific features is complex and difficult for product and engineering teams.
• Governance team: A dedicated group offering support and defining predefined templates for common patterns, working on the ubiquitous language, and enforcing good practice in development
• Schema abstraction: We’re building tooling to simplify schema understanding across teams.

What’s Next: The Future of Authorization

Authorization is still evolving. Standardization efforts like OpenID AuthZEN AuthZEN Working Group — OpenID Foundation aim to bring interoperability and clarity to the space. AuthZEN is working to become the OAuth of authorization, defining protocols for policy enforcement and decision points.

Other initiatives include:

• OASIS XACML: A mature standard for attribute-based access control.
• Google Zanzibar: A scalable ReBAC model used internally at Google.
• IDQL (Identity Query Language): A declarative language for access policies.
• OPA (Open Policy Agent): A general-purpose policy engine gaining traction.

AuthZilla is built with these standards in mind, ready to integrate and evolve as the ecosystem matures.

---

Authorization isn’t just a technical concern — it’s a business enabler and a security imperative. With AuthZilla, we’ve built a solution that’s scalable, secure, and ready for the future.

If you’re struggling with fragmented access control, role explosion, or audit nightmares — maybe it’s time to unleash your own AuthZilla.

🔜 Up Next: In our next article, we’ll dive deep into AuthZilla’s architectural design, explore how we’ve engineered for performance and scalability in our infrastructure, and reveal how we’re tackling one of the toughest challenges in identity management: bridging the gap between CIAM (Customer Identity Management) and WIAM (Workforce Identity Management).

It’s a story of trade-offs, innovation, and a few surprises — stay tuned.