FAQ

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 model 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 Tenant for each application environment that will use Authzed (e.g. my staging webapp staging, my production webapp). Relationships cannot span multiple Tenants; thus if you plan to share permissions across various microservices, you will only want to use a single Tenant.

Next, they invite users to a Tenant and/or create and grant access to Clients which represent applications. Users and Clients can be given read, write, or administrative access to a Tenant.

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

Users create tokens for themselves or on behalf of a Client. These tokens are used to authenticate to the Authzed API. Users and Clients can have multiple Access Tokens, in order to support zero-downtime credential rotation.

Users can interact with Tenants 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 Tenant Writer access to create new relationships and check existing relationships.

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

A visual walk-through of this process is available in the form of a Quick-Start Guide.

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

Right now Authzed is focused on building out its SaaS functionality, but that doesn't mean there will never be an on-prem 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 namespaces are owned by a tenant (e.g. tenant/namespace:objectid#relation), which is used to provide a globally unique prefix to namespaces. 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 have numerical user IDs, but rather represents users as usersets. This enables significantly more flexible expressions of what a "user" is in an application. For example, an "API token" could be the representation of users in a system, and API tokens obtain all their relationships transitively through another namespace that has an "owns" relation to the token. However, most commonly users are represented as a Namespace named "user" that has no relations (e.g. tenant/user:123#...).

Why is Authzed a service and not just a library?

Permission systems libraries take the first step of decoupling policy from business logic. A permissions service takes that logic 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.

Additionally, by putting permissions behind a dedicated service, more sophisicated software can be built and abstracted from the application.

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.

There are two configurations that make sense for most policy engines use cases:

• Authzed as a pre-filter
• Authzed as a policy engine input

In the former, applications first check access to a resource with Authzed and afterwards execute their policies. Authzed takes care of enforcing any requirements around relationships that a user has (e.g. the current user has read access to this document), leaving only attribute-based policies (e.g. the current user is not past their document viewing quota).

In the latter, a policy engine or application reads data from Authzed in order to provide the policy engine the input required to process policies on a given request.

For more information see What are Policy Engines?