A form of fine grained authorization where access is determined based on a user or entity's 'attributes'. Whereas role based access control is limited to access decisions based on the presence of (boolean) permissions on roles, attribute based access control supports more dynamic and granular policy expressions. For example, an ABAC policy keyed on a 'user type' attribute allows for different authz behavior for each value of the 'user type' enum. ABAC policies can also be defined and evaluated across multiple attributes, allowing for even more granularity. Read more here.
The act of validating an entity's (user or system) identity. In other words, the process of determining who someone or something is. Read more here.
The other half of the 'auth' equation. Authorization (often stylized as authz) determines what a user or entity can access or do within a system based on permissions, entitlements and other context. There are many different authz schemes that vary in complexity and implementation. Read more here.
Used to describe simple, 'one-dimensional' authorization systems and policies. The main example of coarse grained authorization is role based access control, where access/permissions are purely driven off of the presence of a role. Coarse grained authorization is not as powerful or expressive as fine grained authorization but is generally easier to implement and deploy.
Within the context of B2B software and SaaS, entitlements usually refer to all the functionality that a user has access to within an application. Entitlements may be defined and allocated strictly for auth and security purposes (ex. ability to create/edit sensitive reports) but can even be driven purely by business needs. For example, paid users within a SaaS application might have entitlements granting them access to all 'paid' features within the application whereas free users wouldn't have those entitlements. Entitlements are typically attributes of users and thus can be considered a form of attribute based access control.
In contrast to coarse grained authorization, fine grained authorization is generally defined as authorization that is 'resource or object-based' and takes multiple attributes into account. For example, a coarse grained authz policy might specify that 'anyone with the admin role can edit reports' whereas a fine grained version of the policy might specify that 'user x who is an admin can edit report y'. Fine grained authorization systems are more powerful and expressive but more difficult to implement and maintain.
A generally accepted umbrella term used to describe the two main components of auth (authentication and authorization). It's a more descriptive term typically used when describing auth systems and vendors. For example, AWS brands its IAM system simply as 'AWS IAM'.
An open source, general-purpose policy engine that can be used to create, manage and enforce authorization policies. OPA is a fairly mature project (started in 2016) with abstractions and supporting projects that enable various coarse grained and fine grained infrastructure (and more recently application-level) authorization schemes.
Most commonly used in B2B SaaS or consumer freemium apps, pricing tiers represent 'packages' or 'groups' of specific features and entitlements that a user has access to within an app based on their payment or subscription tier. For example, a SaaS application might have a 'free' tier that grants all customers access to a base set of features. In addition, the app may have separate paid 'business' and 'enterprise' tiers which grant access to more premium features. Customers are then granted 1 or more of these tiers based on their chosen payment plan. In addition to simplifying pricing, pricing tiers can be a powerful abstraction within an application to enable self-service and dynamic pricing with minimal code changes.
A form of access control where access is determined based on relationships between entities. One of the most common examples of ReBAC in use is the 'shared content access model' (ex. Google Drive). In this model, the ability to edit a document or entity is determined by one's relationship with it (i.e. 'owner', 'editor'). Like ABAC, ReBAC allows for the definition of more fine grained, resource-based authz policies. Unlike ABAC or RBAC, ReBAC allows for easier expression of inherited or hierarchical access control. For example, in the case of Google Docs, an 'owner' is inherently an 'editor' and 'viewer' and thus has all permissions and abilities associated with those two relationships. Google's Zanzibar service is an example of a ReBAC-compliant authz system. Read more here.
One of the most common forms of access control, especially within B2B and SaaS applications. Role based access control (RBAC) is driven off of 3 main entities: roles, permissions and users (subjects). Permissions are coarse-grained and define actions that can be taken in a system (ex. create-report, delete-report) while roles allow for easy grouping of permissions (ex. admin, owner). Users can then be assigned to 1 or more roles to be given the underlying permissions associated with those roles. Read more here.
Google's centralized, consistent, global authorization system that powers permissions and access control for various user-facing Google services including Calendar, Drive, Maps and Photos. Zanzibar was designed specifically for performance, reliability and correctness at Google-scale while remaining generic and flexible enough to model various application authorization use-cases. The original paper can be found here.
A newer security paradigm that advocates for stricter, granular security at every layer and within every application. Historically, the common pattern within corporate networks and systems has been to establish a security perimeter or 'walled garden' inside which applications and systems are widely accessible. Examples of this include corporate virtual private networks (VPNs) used by employees to access corporate systems. Once an employee is logged into their VPN, they have full access to production systems and data. Zero trust proponents argue that this 'walled garden' approach is prone to exploits in today's world and instead each system and application needs to operate with 'zero trust' when dealing with users or other applications and systems. In the context of application auth (authn and authz), this means strict identity and authn protocols as well as more granular, fine-grained authorization and access control.