Skip to main content

Overview

What is Authzed?

Authzed is a platform to store, compute, and validate application permissions. Permissions are modeled based on relationships between objects that an defined by an application.

Developers design and test the objects and relationships that will be used for determining permissions for their application. They then extend their application using client libraries that create, delete, and check relationships within that data model.

Who can use Authzed?

Anyone building, running, or auditing software.

Typically, this is manifests itself as:

  • Developers using Authzed to build and test a permissions systems and subsequently integrating permissions into their application using provided client libraries.
  • Software Operators using Authzed to understand the real-time performance of production applications.
  • Security Teams auditing their applications using Authzed for security and compliance.

What's the process for setting up Authzed?

Authzed can be used in a variety of ways, but the typical use case is as follows:

An engineering leader signs up and creates an Organization for their company. They invite any other administrators to the organization and create a Permissions System for each application environment that will use Authzed (e.g. my staging webapp staging, my production webapp). Relationships cannot span multiple Permissions Systems; if you plan to share permissions across various microservices, you will only want to use a single Permissions System.

Next, they invite users to a Permissions System and/or create and grant access to Clients which represent people or applications that can access the Authzed API. Clients can be given read, write, or administrative access to a Permissions System.

  • Readers cannot perform any modifications to data, but can view it (e.g. check if Robin has read access to Document #1).
  • Writers can create relationships between users and application objects (e.g. grant Robin owner access to Document #1).
  • Admins can write Schemas that define the types of relationships that can exist between objects (e.g. documents can have owners that inherit both write and read access).

Clients can own multiple Access Tokens which are used to authenticate to the Authzed API. In the case of an emergency, a new Access Token can be created and deployed before revoking the old token.

Users can interact with Permissions Systems through the zed command line tool or any tool that supports the Authzed gRPC API directly. Developers use the Authzed client libraries configured with a Client's Access Token in order to access Authzed from their applications. At runtime, applications typically require Writer access to create new relationships and check existing relationships.

Anybody can build, experiment, exhaustively test, and share their permission system on the Authzed Playground. When a permission system is ready to be built into an application, you can import an initial system directly from a Playground link. Afterwards, any changes should be orchestrated in a process similar to relational database schema migrations.

Follow the guide for Protecting Your First App.

Is Authzed SaaS-only or can I use Authzed on-premise?

Authzed is focused on building out its SaaS functionality, but we're searchign for close partners for our enterprise offering. If you're interesting in deploying Authzed on-prem, we'd love to hear from you.

What is the difference between Authzed and Google Zanzibar?

At its core, Authzed is a service that is inspired by the Google Zanzibar paper. However, this paper is not an exhaustive description of the Google implementation and as such any implementation inspired by the paper will deviate. Because Authzed is not an internal service, but a multi-tenant SaaS product, it also has additional requirements that the internal systems at Google do not.

Excluding implementation details that are vague or not described in the paper, Authzed has made some explicit deviations from the original paper:

  • All Objects are owned by a Permission System, whose names are used as globally unique prefixes on all Object Types defined in that system (e.g. google/doc:4932832839040#reader). This is done to avoid naming collisions across tenants and is used as a security boundary. Because Zanzibar is a trusted, internal service, it does not have isolation between a tenants like Authzed requires.
  • Authzed does not make use of a special class of numerical user IDs, but rather users are defined as an Object Type in each Permission System. This enables systems to have significantly more flexible expressions of what a "user" can be. For example, you can write a Schema where applications check permissions on an "API Token" Subject that is owned by a "User", rather than requiring applications to resolve API Tokens into Users before calling the Authzed API. To design something equivalant to Zanzibar's user IDs in Authzed, you can defines Users as an Object Type that has no relations (e.g. google/user:123).

Why is Authzed a service and not just a library?

Permissions systems libraries take the first step of decoupling policy from business logic. A permissions service takes that idea one step further so that policy is decoupled from the application entirely. This enables multiple applications to work with the same data and enforce the same policies.

Companies such as Google, Facebook, GitHub, and Airbnb have needed to transition from using popular solutions such as shared libraries and policy engines to having dedicated services similar to Authzed.

Is Authzed a Policy Engine?

Authzed is not a policy engine, but it is a phenomenal service to use alongside one. Authzed can be used to filter results before/after executing a policy, but can also be integrated directly as a source of input to a policy engine. As an experiment, zed currently supports a direct integration with Open Policy Agent.

For more information see What are Policy Engines?