Why words matter
Every field develops its own linguistic shortcuts – jargon – to streamline communication around complex ideas. Consider browser cookies: a term that conjures images of tasty treats, but actually refers to bits of data that can be used for tracking online activity. While convenient for insiders, such jargon can be confusing for the uninitiated.
Common language, including jargon, usually settles organically as an area of practice matures. Sometimes early innovators intentionally agree to a particular framework for convenience.
While the practice of building authorization in applications is not new, modern approaches are evolving rapidly, spurred by advancements like Google's Zanzibar paper and the increasing demand for sophisticated collaborative features.
However, the language used to describe authorization solutions hasn't kept pace. We often rely on terminology borrowed from the lexicon of identity and access management (IAM), a field focused on resource control rather than application development. This mismatch can hinder clear communication and can lead to confusion.
How do we start clearing the air? Common language helps the community converse more productively about the tradeoffs involved when comparing authorization services and permissions systems. The first step: establish a shared vocabulary, starting with foundational elements.
Semantics
Often used interchangeably, the terms permissions and authorization represent distinct, yet related concepts. Permissions establish and reason about the rules and logic that govern permissible actions, defining the boundaries of what can and cannot be done under specific conditions and contexts. Authorization is the process of answering questions about permissions. In short, permissions determine whether or not an action is authorized.
Permissions systems
To determine whether any particular action is allowed or not, a decision maker requires the following:
- A defined set of guidelines governing allowable actions
- Relevant data about the action, including the actor (who's doing it), the action itself, the object of the action, and sometimes additional context or attributes
- The method for applying those guidelines to the relevant data
In a legal trial, the court determines whether the defendant's actions violated the law. The laws and policies serve as the set of guidelines, while the facts of the case provide the information relevant to the action in question. The mechanism that applies these laws and policies to the facts of the case would be the judge or jury.
Coming back to software, an authorization decision requires similar information:
- A permissions model that defines the logic and rules governing allowable actions
- Data pertinent to the decision being made, either from a datastore or provided at runtime
- Engine capable of applying logic and rules to provided data and returning a decision
These components make up a permissions system. The system itself may be wholly contained outside of an application, be dispersed throughout a monolithic application, or some combination of both. A system might have multiples of a component, such as multiple data sources or permissions models.
Applying SpiceDB concepts to this terminology, a SpiceDB permissions system uses a schema to structure relationship data, creating a graph database capable of returning answers about authorization.
The permissions system concept not only applies to other Zanzibar implementations, but any other system that may follow a different paradigm.
Authorization service
While a permissions system can function independently to provide authorization to an application, an authorization service provides a layer of abstraction on top of a permissions system.
This service manages the business logic of authorization and permissions systems while also providing additional operational functionality such as caching decisions, auditing and logging, and managing supportive resources.
Used in context, the AuthZed Cloud authorization service deploys, manages, and provides additional operational capabilities for SpiceDB permissions systems. Other organizations choose to build their own authorization service for their SpiceDB permissions systems within their own infrastructure.
By establishing a clear and consistent lexicon for implementing authorization, we foster a shared understanding that allows us to compare disparate approaches, evaluate tradeoffs with precision, and ultimately architect more robust and secure collaborative workflows and sharing capabilities within applications.
Glossary
Permissions establish and reason about the rules and logic that govern permissible actions, defining the boundaries of what can and cannot be done under specific conditions and contexts.
Authorization is the process of answering questions about permissions.
Permissions systems construct a mechanism for defining, storing, and evaluating permissions.
Authorization services provide a layer of abstraction on top of permission systems that provide answers to an end consumer, such as an application.
