Concepts / Glossary
Look up the authorization terms and Permit.io concepts used across these docs. Each entry defines one term and links to the page that covers it in depth.
General authorization terms
Authorization
Authorization decides what a user can do after the user signs in.
Authentication is a different step. Authentication verifies that users are who they claim to be, and decides who can sign in to your application. See Authentication and authorization.
Policy
An authorization policy is a set of rules that determines access to resources in your application. A policy combines who (the identity), what (the action), and which resource (the part of your software being accessed). Policies can add criteria such as roles, attributes, and relationships.
In plain English, a role-based authorization policy has this structure:
A User can perform Action on Resource.
For example:
John who is an Administrator can read a document.
See What is a policy?.
Policy language
A policy language is a formal syntax for the rules, conditions, and logic of a policy. A policy engine evaluates policies written in that language. Examples include Rego, the policy language of Open Policy Agent (OPA), AWS Cedar, and Polar by Oso.
Policy engine
A policy engine evaluates authorization queries against policies written in a policy language and returns a decision. Permit supports Open Policy Agent (OPA) and AWS Cedar. See Policy engines.
OPAL
Open Policy Administration Layer (OPAL) is an open-source project that the Permit.io team develops and maintains. OPAL detects changes to policy and policy data in real time and pushes live updates to the policy engines in your policy decision points (PDPs).
PDP
A policy decision point (PDP) is a network node that answers authorization queries using policies and contextual data.
In Permit, the PDP is the authorization microservice your application sends permission checks to. You can run the PDP as a Docker container next to your services, or use the managed Cloud PDP.
PEP
A policy enforcement point (PEP) enforces access to resources, usually by asking a PDP for a decision and acting on the result.
In Permit, you create PEPs in your code with an SDK (a single permit.check() call, a function, an API route, or middleware),
or outside your code with plugins for a reverse proxy or an API gateway.
Multi-tenancy
Multi-tenancy is a system design in which every part of a service serves multiple customers without a separate deployment for each customer.
See Multi-tenant authorization.
AuthZ for AuthZ (meta authorization)
AuthZ for AuthZ is authorization applied to the access control system itself: who can change roles, policies, and permissions. In Permit, member roles decide which team members can view or change policy.
See Member management.
Authorization models
An authorization model determines the access a user gets, based on roles, attributes, relationships, or a combination of them. Permit supports these models:
RBAC
Role-based access control (RBAC) grants access through predefined roles. You assign permissions to roles (like "Admin" or "Viewer"), and assign roles to users.
See RBAC in Permit.
ABAC
Attribute-based access control (ABAC) grants access based on conditions on attributes:
characteristics of users, resources, or the environment. ABAC lets you define fine-grained rules, such as "users in the finance department can read invoices under $10,000".
See ABAC in Permit.
ReBAC
Relationship-based access control (ReBAC) derives permissions from the relationships between users, groups, and resources. ReBAC fits nested hierarchies such as org charts and file directories.
See ReBAC in Permit.
Permit.io terms
Action
An action is an operation a user can perform on a resource, such as read, update, or publish. Each resource has its own list of actions. See Actions.
API key
An API key authenticates your application, SDK, and PDP with Permit. An environment API key is scoped to one environment. See Get your API key.
Cloud PDP
The Cloud PDP is the PDP that Permit hosts and manages at https://cloudpdp.api.permit.io. The Cloud PDP does not support ABAC policies. See Cloud PDP capabilities.
Control plane
The control plane is the part of Permit that runs in Permit's cloud. You manage policy, roles, resources, users, and tenants in the control plane through the dashboard or the API. See Control and data planes.
Data plane
The data plane is the set of PDPs that evaluate permission checks. Container PDPs run in your network, next to your services. See Control and data planes.
EAP
Early Access Program (EAP). Features marked EAP are released, but their APIs may change.
Environment
An environment is a silo of policy and data. An environment usually represents one deployment stage of a project, such as development, staging, or production. You can copy one environment into another through the API. See Copy and merge environments.
Each PDP syncs with one environment, identified by that environment's API key.
MAU
Monthly active users (MAU) are the unique users (end users) you check permissions for in a given month.
A user counts as one monthly active user no matter how many permission checks you run for that user in the month. Permit uses MAU and tenant counts to calculate billing. See Workspace usage and the pricing page.
Member
A member is a person on your team who signs in to the Permit dashboard. Members are different from users: users are the identities you check permissions for. See Member management.
Permit Elements
Permit Elements are embeddable UI components that give your end users access control flows, such as user management, access requests, approvals, and audit logs. An individual component is an element, such as the User Management element.
See Permit Elements.
Projects
A project is a collection of environments within a workspace. A project usually maps to one application or service your organization provides. See Projects and environments.
Resource
A resource is an object type you control access to, such as a document, a board, or an API endpoint. Resources belong to an environment. See Resources.
Role
A role is a named collection of permissions that you assign to users. Top-level roles apply across a whole tenant. See Roles.
Tenant
A tenant is an isolated unit within an environment, used in multi-tenant applications. Each tenant has its own users, resource instances, and role assignments.
In a multi-tenant application, different organizations use the same application, each in its own tenant. Role assignments are scoped to a tenant, which keeps tenants separate from each other. A tenant usually represents one of your customers.
User
A user is an identity you check permissions for, such as an end user of your application. You sync users to Permit with the API or SDK. See Sync users.
Workspace
A workspace is your Permit organization account. A workspace holds all of your configuration, projects, and environments. Workspaces are isolated from each other.
You can have several workspaces and switch between them.