DEV Community

AuthZed for AuthZed

Posted on • Originally published at authzed.com on

Why Businesses Are Embracing Google Zanzibar for Authorization

Introduction

A business operating complex software environments needs to provide end-user experiences that enable and delight users, but never at the cost of a poor security stance. In 2022, a lapse in security fetched on average 9.44M for a data breach in the US, and $4.35M globally according to IBM.

This post reviews what we see in the market through conversations with companies looking to solve their authorization challenges, specifically authorization that impacts end-user interaction with their products. I’ll cover how authorization became a bottleneck for most companies, the solution the market is converging on, the prominent use cases driving businesses to adopt a new approach, and what you can expect when moving to a relationship-based access control system (ReBAC).

Why Authorization is an Issue

Because the Internet is, by definition, a networked system that connects users, most Internet-facing software is designed with a multi-user experience in mind. These environments require constructs to facilitate a natural experience that protects users’ data: authentication is the key that verifies an application-specific identity, typically called a user, and authorization dictates what doors that key can open for a user.

Collectively in the context of a product’s end users, authentication and authorization are called Customer Identity and Access Management (CIAM). Authorization is such a foundational part of the digital experience that its underlying design principles have become 99% invisible, even to developers, leading to fundamental challenges as a business scales.

A company typically starts by aggregating all user requests into a single piece of software that tightly couples application logic with authorization. As the company’s product gains traction and its user base grows, the focus shifts to distributing the software and scaling infrastructure components, often ignoring a much-needed change to the authorization system. This further embeds an authorization construct not meant to handle a growing number of requirements.

From the business’ perspective, the two key limitations of a legacy authorization system are:

  • Permissions are inflexible : there isn’t a way to easily add additional constructs like user-defined roles, recursive relationships, attribute-based access control (ABAC), or fine-grained authorization (FGA).
  • Siloed permissions: as a company grows, it scales revenue by offering additional products; application teams then build bespoke authorization implementations that are hard to reason about and don’t consider a holistic user experience.

Google set out to fix this problem, along with several “unique challenges involving data consistency and scalability.”

Google’s Solution to Authorization

The confluence of business requirements driving the adoption of zero-trust architectures and 94% of consumers wanting more control of their data in near real-time galvanized the search for a modern authorization system. Google’s response was a modern approach that can scale with your business and maintain strict security requirements, now known as Google Zanzibar.

Among the requirements set forth by the Zanzibar team is “support for a rich set of access control policies as required by both consumer and enterprise applications” and “establish consistent semantics and user [developer] experience across applications.” Zanzibar powers authorization across hundreds of Google Products, including Google Calendar, Cloud, Drive, Maps, Photos, and YouTube. Notably, it unlocks unique experiences like cross-product authorization checks, e.g., Slack’s Gmail extension can check if a recipient has access to a Google Doc, unlocking growth through reduced friction points while maintaining user privacy.

Zanzibar is a relationship-based access control system (ReBAC), meaning that permissions are derived from the existence of a relationship between digital objects and users. This has positive performance implications, especially for recursive permissions, but, importantly, it’s a natural extension of sharing in the real world, which makes it intuitive for most developers.

Use-Cases Driving Adoption of Google Zanzibar

Product-Led Growth

To share something is a user choice and subsequent action. Companies we’re speaking with have learned that facilitating frictionless sharing can help onboard additional users to their platforms. For instance, a hiring platform we’re working with implements fine-grained authorization (FGA) so enterprise recruiters are comfortable exposing permissions to hiring managers related to the positions the managers are looking to fill. Hiring managers, in turn, can proactively engage with candidates and increase activity on the platform.

Another example is adding capabilities that foster more in-app experiences. For instance, a sharing economy company is boosting engagement with its platform by bringing resource management for users into their native applications instead of relying on third-party applications. Most companies we speak with share similar product-led growth initiatives built atop robust authorization.

Breaking into the Enterprise

Enhancing security and compliance is a key requirement for B2B companies looking to scale revenue within an enterprise market segment, and OWASP’s 2021 report cites broken access control as a top security concern. One of the main risks is “exposure of sensitive information to an unauthorized actor,” which is a core tenet of the Google Zanzibar paper; the system "must ensure consistency of access control decisions to respect user intentions.

Enterprise users also require increased flexibility; these manifest as the following requirements for product teams:

  1. Fine-grained authorization (FGA): the ability to control resources down to a granular level, e.g., a page in a document, though there is a balance, see How small is too small?
  2. User-defined Roles and Permissions: beyond a typical application-defined Role-Based Access Control (RBAC) system, product teams need to allow end-user admins to create roles and associated permissions for delegating to internal teams.
  3. Recursive relationships: at a certain scale, teams start owning teams. This is challenging for a traditional authorization system dealing with permissions stored in a relational database alongside application data.
  4. Attributes-Based Access Control (ABAC): support for dynamic time-bound or otherwise caveated access.

What to Expect When Adopting Relationship-Based Access Control (ReBAC)

A key part of ReBAC systems like Google’s Zanzibar and our own Zanzibar-inspired authorization system, SpiceDB, is storing permissions data in a separate database; product-specific data (e.g. content of a social media post) is stored in the application database, while the data that drives who can edit that data live in the permissions database. If you have an existing authorization flow, you’ll have to translate that data into permissions data.

Modeling data is probably the most fun and intuitive part. SpiceDB, like other solutions, has a domain-specific language (DSL) called the SpiceDB Schema Language for defining the objects you want to create an authorization system for. The permissions schema defines the objects, e.g., users and documents, how they relate to each other, and the permissions those relationships define.

Since you’re writing permissions data, integration is a big part of the journey. A ReBAC authorization system is delivered over a gRPC or HTTP API; SpiceDB has libraries available in multiple languages to help developers get up to speed quickly. You’ll want to make sure whatever solution you choose delivers a solid developer experience.

Google’s Zanzibar doesn’t mention policy, but we’ve learned through our collaboration building Attribute-Based Access Control (ABAC) for Netflix that pairing policy with ReBAC is a powerful paradigm. An example of this capability is SpiceDB Caveats: Caveats: A Scalable Solution for Policy.

A common practice is to organize a core team of developers tasked with architecting and executing an overhaul to your authorization system. The effort must be cross-functional; you’ll want platform engineers, application engineers, and product managers to work together to ensure smooth adoption.

Get Started

Given how popular Google's approach to authorization has become, there are a number of new companies and projects looking to provide Zanzibar-aaS. At AuthZed, we've created a faithful open source implementation of Google Zanzibar called SpiceDB, and offer managed commercial offerings that make it easy to get into production. Join the community on Discord or schedule a call to learn more!

Related Reading

Top comments (0)