Authorization glossary

Access control

Access control is the process of regulating who can access or use resources in a system based on predefined policies. It ensures that only authorized users or systems can perform specific actions on resources, typically through mechanisms such as role-based, attribute-based, or relationship-based access control.

Access Control List (ACL)

An Access Control List is a data structure that specifies which users or system processes are granted access to a particular resource, along with the operations they are allowed to perform. Each entry in an ACL typically maps a user or group to a set of permissions for a specific resource. ACLs are one of the oldest and most straightforward authorization mechanisms, commonly used in file systems, network devices, and databases.

Access token

An access token is a short-lived token issued by an Identity Provider after successful authentication, which grants the user access to a specific resource or service. It is typically used in OAuth 2.0 and OpenID Connect to authenticate API calls or access user data. Access tokens are usually passed in HTTP headers and have a limited lifespan for security reasons.

Action

An action is a specific operation that a user or system can perform on a resource, such as read, write, delete, approve, or transfer. Authorization policies evaluate whether a given user is permitted to perform a specific action on a specific resource. Defining a clear set of actions for each resource type is essential for building precise and enforceable access control rules.

Attribute-Based Access Control (ABAC)

ABAC is an authorization model that evaluates access decisions based on attributes associated with the user, the resource, the action, and the environment. For example, an ABAC policy might allow access only if the user's department matches the resource's owner department and the request is made during business hours. ABAC offers fine-grained, dynamic control but can be more complex to implement and audit than role-based models.

Audit log

An audit log is a chronological record of access events and authorization decisions within a system. It captures who accessed what resource, when, and whether the request was allowed or denied. Audit logs are essential for compliance, security investigations, and demonstrating adherence to access control policies. In enterprise environments, customers often require exportable audit logs as a condition of procurement.

Authorization

Authorization is the process of determining what actions, resources, or data a user is allowed to access after they have been authenticated. It relies on policies, roles, and permissions to enforce access boundaries within a system. While authentication answers "who are you?", authorization answers "what are you allowed to do?"

Authorization policy

An authorization policy is a formal rule or set of rules that defines who can access a resource and under what conditions. Policies can be expressed in code, configuration, or domain-specific languages and are evaluated at the time of each access request. Well-defined policies enable centralized, auditable, and consistent enforcement of access control across an application or organization.

Authorization token

An authorization token is a credential (typically a JSON Web Token or opaque string) issued after authentication that encodes the user's identity, roles, and permissions. The token is sent with each request to prove the user's authorization to access a resource. Tokens are commonly used in stateless architectures where the server verifies the token's claims without maintaining session state.

Claims

Claims are pieces of information about an entity (typically the user) that are embedded within a security token, such as a JSON Web Token (JWT). Claims can include details like the user's name, email address, roles, and other attributes, or custom data related to the authentication process. Claims are used by service providers to make authorization decisions. In the context of OAuth or OpenID Connect, claims provide essential identity information and can be trusted as long as the token is properly signed.

Coarse-Grained Authorization

Coarse-Grained Authorization refers to access control that operates at a broad level, such as granting or denying access to an entire application, service, or API endpoint. It is simpler to implement and reason about than fine-grained models, and is often sufficient for early-stage products or internal tools. However, as applications grow in complexity and serve enterprise customers, coarse-grained controls typically need to be supplemented with finer-grained authorization.

Consent

Consent, in the context of authorization, is the explicit approval given by a user to allow a third-party application to access specific resources or perform certain actions on their behalf. Consent is a core component of OAuth 2.0 authorization flows, where the user is presented with a consent screen listing the requested scopes before granting or denying access. Proper consent management ensures transparency and user control over data sharing.

Contextual authorization

Contextual authorization evaluates access requests based on dynamic, real-time context in addition to static roles and permissions. Contextual factors can include the user's IP address, device type, location, time of day, or the sensitivity of the resource being accessed. This approach enables adaptive security, for example, requiring additional verification when a user attempts to access a resource from an unfamiliar device.

Delegation

Delegation in authorization is the act of granting another user or system the ability to perform actions or access resources on your behalf. This is commonly seen in enterprise workflows where a manager delegates approval authority to a direct report, or in OAuth flows where a user delegates access to a third-party application. Delegation requires careful scoping to ensure the delegated authority does not exceed what is appropriate.

Entitlement

An entitlement is a right or privilege granted to a user, account, or organization that determines what features, resources, or tiers of service they can access. Entitlements are commonly used in SaaS applications to manage feature gating and plan-based access, for example, granting access to advanced analytics only to users on an enterprise plan. Entitlements bridge the gap between authorization and product packaging.

Fine-Grained Authorization (FGA)

Fine-Grained Authorization refers to access control systems that can make decisions at a highly specific level, for example, controlling access to individual documents, rows, or fields rather than broad resource categories. FGA often combines elements of RBAC, ABAC, and ReBAC to evaluate complex conditions. It is essential for applications that require per-object or per-action permissions, such as collaborative editing tools and data platforms.

Identity delegation

Identity delegation allows a user to grant another system or service permission to act on their behalf for authentication and authorization purposes. This is commonly used in OAuth and OpenID Connect, where a user delegates their authentication to an Identity Provider (IdP), and the system receives tokens to access resources without sharing user credentials directly. It simplifies access control in scenarios where one system needs to interact with multiple services on behalf of a user.

Identity federation

Identity Federation allows users to use their identity credentials across different organizations or services. It enables seamless authentication between systems without requiring users to create separate accounts for each service, often achieved through standards like SAML or OAuth.

Impersonation

Impersonation is the ability for a privileged user (such as an administrator or support agent) to act as another user within a system, typically for troubleshooting or support purposes. When impersonating, the system applies the target user's permissions and context, allowing the admin to see exactly what the user sees. Impersonation must be tightly controlled and fully auditable to prevent misuse.

JSON Web Token (JWT)

JSON Web Token (JWT) is a compact, URL-safe token format used for securely transmitting information between parties. JWTs are commonly used for authentication in OAuth 2.0 and OpenID Connect, where the token contains claims (such as user ID, roles, and permissions) that are cryptographically signed to ensure their integrity. JWTs can be used as access tokens or identity tokens in distributed systems.

Multi-tenancy

Multi-tenancy is an architecture in which a single instance of an application serves multiple tenants, each with isolated data and access controls. From an authorization perspective, multi-tenancy requires the system to enforce strict boundaries so that users can only access resources belonging to their own tenant. This model is standard in SaaS products and requires careful authorization design to balance shared infrastructure with tenant-level security.

OAuth

OAuth is an open authorization framework that allows a third-party service to access resources without sharing user credentials. It enables users to grant limited access to their data on one platform to another, securely. OAuth is widely used in applications where services need to interact on behalf of users, such as social media logins or API access.

Open Policy Agent (OPA)

Open Policy Agent is an open-source, general-purpose policy engine that can be used to create, manage, and enforce authorization policies. OPA is a mature project (started in 2016) with abstractions and supporting projects that enable various coarse-grained and fine-grained infrastructure and application-level authorization schemes.

Organization

An organization, in the context of authorization, is a logical grouping of users that represents a customer, company, or team within a multi-tenant application. Organizations serve as the primary authorization boundary. Roles, permissions, and policies are typically scoped to an organization, ensuring that access controls are enforced per-customer rather than globally. Managing organizations effectively is key to building enterprise-ready applications.

Permissions

Permissions are the specific actions or operations that a user is allowed to perform on a resource within a system. They represent the most granular unit of access control, for example, "read," "write," "delete," or "invite_members." Permissions are typically assigned to roles or policies rather than directly to individual users, enabling scalable and maintainable access management.

Policy Administration Point (PAP)

A Policy Administration Point is the interface or system used to create, manage, and maintain authorization policies. It provides tools for administrators to define roles, permissions, and rules, and to update them as organizational needs change. The PAP feeds policy definitions to the Policy Decision Point (PDP) and is essential for maintaining a clear and auditable authorization posture.

Policy-Based Access Control (PBAC)

PBAC is an authorization approach that uses centralized, declarative policies to govern access decisions. Policies are written as rules that evaluate conditions at the time of the request, taking into account user attributes, resource properties, and environmental context. PBAC enables organizations to manage authorization logic separately from application code, improving consistency and auditability across systems.

Policy Decision Point (PDP)

A Policy Decision Point is the component in an authorization architecture that evaluates access requests against defined policies and returns an allow or deny decision. The PDP receives a request containing information about the user, the resource, and the action, then applies the relevant policies to determine whether access should be granted. Separating the PDP from application logic enables centralized and consistent authorization enforcement.

Policy Enforcement Point (PEP)

A Policy Enforcement Point is the component that intercepts access requests and enforces the decisions made by the Policy Decision Point (PDP). The PEP sits in the path of the request (for example, in an API gateway, middleware, or application layer) and either allows or blocks the request based on the PDP's response. The PEP ensures that authorization policies are applied consistently at every point of access.

Principle of least privilege

The principle of least privilege states that users, systems, and processes should be granted only the minimum level of access necessary to perform their tasks. By limiting permissions to what is strictly required, organizations reduce the attack surface and minimize the potential damage from compromised accounts or insider threats. It is a foundational concept in secure authorization design.

Privilege escalation

Privilege escalation occurs when a user gains access to resources or actions beyond what their assigned permissions allow. This can happen through software vulnerabilities, misconfigurations, or exploits in authorization logic. Privilege escalation is a critical security risk, and defending against it requires robust authorization checks, input validation, and regular audits of access control configurations.

Refresh Token

A refresh token is a long-lived token used to obtain a new access token when the current one expires. It allows users to maintain their authenticated session without needing to log in again. Refresh tokens are usually stored securely and used to issue new access tokens without requiring user interaction, ensuring a seamless experience.

Relationship Based Access Control (ReBAC)

ReBAC is an authorization model where access decisions are determined by the relationships between entities in a system. Rather than relying solely on roles or attributes, ReBAC evaluates whether a specific relationship exists, for example, whether a user is a member of a team that owns a document. This model is well-suited for applications with complex, graph-like data structures such as social networks, collaborative tools, and file-sharing platforms. ReBAC also allows for easier expression of inherited or hierarchical access control. Google's Zanzibar service is a prominent example of a ReBAC-compliant authorization system.

Resource

A resource is any entity (such as a file, API endpoint, database record, or application feature) that is subject to authorization controls. In authorization systems, resources are the objects that users request access to, and policies define the conditions under which access is granted. Clearly defining and categorizing resources is a foundational step in designing an effective authorization model.

Role-Based Access Control (RBAC)

RBAC is an authorization model that assigns permissions to roles rather than to individual users. Users are then assigned one or more roles, and they inherit the permissions associated with those roles. RBAC simplifies access management in organizations by grouping permissions into logical roles like "Admin," "Editor," or "Viewer," making it easier to enforce the principle of least privilege at scale.

Roles

Roles are named collections of permissions that represent a job function or responsibility level within a system. Instead of assigning individual permissions to each user, administrators assign roles (such as "Admin," "Member," or "Billing Manager") and users inherit the associated permissions. Roles simplify authorization management and make it easier to onboard users, audit access, and enforce organizational policies.

Scope

In the context of authorization, a scope defines the boundaries or extent of access that a token or credential grants. Scopes are commonly used in OAuth 2.0 to specify what resources and actions a client application can access on behalf of a user, for example, read:documents or write:settings. Scopes help ensure that applications request only the permissions they need, supporting the principle of least privilege.

Separation of Duties (SoD)

Separation of Duties is a security principle that requires multiple individuals to complete a sensitive process, preventing any single user from having enough access to commit fraud or cause significant harm. In authorization systems, SoD is enforced by ensuring that conflicting roles or permissions (such as the ability to both create and approve a financial transaction) are never assigned to the same user.

Tenant

A tenant is a distinct organizational unit (typically a company, team, or workspace) within a multi-tenant application. Each tenant has its own users, data, and authorization boundaries, ensuring that users in one tenant cannot access resources belonging to another. Proper tenant isolation is a critical aspect of authorization in SaaS applications, preventing data leakage and unauthorized cross-tenant access.

Zanzibar

Zanzibar is 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.