FAQ
Answers to the questions developers ask most often about Permit.io, from what the product does to pricing, policy engines, tenants, and the Permit API. Each answer links to the page that covers the topic in depth.
About Permit.io
What is Permit.io?
Permit.io is an authorization platform for apps, APIs, and AI agents. You model roles, attributes, and relationships
in the Permit UI or as code, and enforce them with a permit.check() call from your application.
A policy decision point (PDP) answers each check. The PDP is a microservice built on open-source policy engines (Open Policy Agent (OPA) and Cedar) that runs next to your services. Permit generates your policy as code and can push it to your own Git repository.
Permit also ships the access-control interfaces your users and team need: user management, access requests and approvals, and audit logs.
What is the difference between Authentication and Authorization?
Authentication and authorization answer two different questions:
| Question it answers | Example | |
|---|---|---|
| Authentication (AuthN) | Who is the user? | A user signs in with a password or single sign-on, and your identity provider issues a token. |
| Authorization (AuthZ) | What is the user allowed to do? | Your app calls permit.check() to decide whether that signed-in user can edit a document. |
Authentication runs first and establishes identity. Authorization runs on every protected action and uses that identity to decide access. See How authentication connects to Permit.io.
Pricing and purchasing
Is there a free version of Permit.io?
Yes. Permit.io has a free plan. Plan quotas and limits change, so read the current figures on the Permit.io pricing page rather than relying on a number quoted elsewhere. To start on the free plan, follow the Permit.io quickstart.
Can I subscribe to Permit.io via the AWS Marketplace?
Yes. See the Permit product page on AWS Marketplace.
Policy engines and other authorization systems
What's the difference between OPA and OPAL and Permit.io?
Open Policy Agent (OPA) is a general-purpose policy decision engine. Open Policy Administration Layer (OPAL) is an open-source project that keeps policy engines up to date with policy and data by pushing event-driven updates to them.
Permit.io is the authorization platform built on top of them. Permit covers the infrastructure (policy engines, SDKs, APIs), the back office your team uses to manage policy, and the end-user interfaces (user management, access requests, audit logs). OPA and OPAL are a core part of that infrastructure. Permit also supports Cedar as a policy engine.
Can I use other policy-agents with Permit.io (e.g. OSO, Casbin)?
The Permit PDP supports OPA and Cedar. To discuss other policy engines, ask in the Permit Slack community or email support@permit.io.
Can I connect my FGA or Google Zanzibar solution with Permit.io (e.g. AuthZed, Ory Keto, Auth0 Sandcastle)?
Permit supports relationship-based access control (ReBAC) natively. See ReBAC in Permit. To discuss connecting an existing fine-grained authorization (FGA) or Zanzibar-style system, ask in the Permit Slack community or email support@permit.io.
Tenants and users
When the tenant does not represent an end-customer company, then what does it represent?
A tenant is an isolated group of users and resources inside an environment. A tenant can be a customer company you serve, or a company or business unit that your own organization owns and manages internally. See Tenants.
Can Permit help me create an app with multiple companies (tenants), where the admins of each company can invite and manage other users?
Yes. Each part of that app maps to a Permit feature:
-
Multi-tenancy: Tenants are a first-class concept in Permit. You define tenants and assign users to them in the UI or the API, and map each tenant (or group of tenants) to a company in your app.
- When you check permissions within a tenant, pass the tenant ID as part of the resource.
- If your app identifies companies by subdomain, pass the subdomain (or a UUID you derive from the subdomain) as the tenant ID.
- A user can be assigned roles in multiple tenants. Use the same user key for every tenant.
-
Roles: Define as many roles as you need in the UI or the API, and assign them to users in any tenant. A user can hold more than one role.
-
End-user management interface: Let your customers' admins manage their own users by building a UI on the Permit API, or embed Permit Elements, embeddable UI components for user management, access requests, and audit logs.
-
Storing user profiles: Permit can store arbitrary user attributes. Sync only the data your policies need and keep the rest in your application database. Use the same user key in your database and in Permit, usually the unique ID from your authentication provider.
Which roles can I give a new member of my Permit team?
Team members of your Permit workspace (members) and the users of your application are managed separately:
- Members of your Permit workspace get a workspace role (Workspace Owner, Workspace Editor, or Workspace Viewer), or a role scoped to one project or environment. See Member management.
- Users of your application get the roles you define in your policy. To let your customers' admins manage their own users' roles, embed Permit Elements.
Environments and the Permit API
What does Set as active environment do? If I set dev as active, does it block API calls that use production API keys?
No. The active environment only sets which environment you view in the Permit UI. For example, the Policy Editor shows the policy, roles, and permissions of the active environment. Setting the active environment is the same as picking an environment from the dropdown in the top navigation bar. The API key and the project and environment in the request decide what an API call can access. The active environment in the UI has no effect on API calls. See Projects and environments.
How can I create an incremental live feed from the activity API without duplicates?
Poll the Activity Log API (GET /v2/activity) with the timestamp_from and timestamp_until query parameters. Both parameters take seconds since the epoch, so consecutive time windows can return the same event twice. Deduplicate on your side with the id field of each activity log event.
Questions from the Permit community
These questions come from the Permit Slack community and reflect common decisions teams face. Each question is quoted verbatim.
Why can't I just use the AuthZ with my framework (NestJS) ?
Question:
I am product owner for a SaaS software. Our developers prefer to always custom built solutions. We have some basic multi-tenant user permission management that one developer made over 3 months time that is no longer sufficient. To rebuild it to our current needs it would take 2-3 months. I'm looking for solutions that could speed this up. But our lead developer is skeptical that anything can speed it up. His response was "NestJS has a really good system for permissions & roles, so there is no need for external service, just for this".How would you respond so I can convince him to look into Permit.io anyway?
Answer:
A framework-level authorization layer such as CASL in NestJS covers role checks inside one service. Three tradeoffs decide whether that layer is enough:
| Tradeoff | Framework authorization in NestJS | An external policy decision point (PDP) |
|---|---|---|
| Where the policy data lives | In your application database. An ABAC or ReBAC check queries roles, attributes, or relationships on every request. | In the PDP's local store. The PDP evaluates the check against preloaded policy and data. See PDP overview. |
| How a policy change ships | As a code change to the access-control code, through your release process | As a configuration change in the Permit Policy Editor or the Permit API, without a deployment. Non-developers can own parts of it through Permit Elements. |
| Who may change permissions | Whoever can merge code | A separate policy for policy administration: the workspace roles decide who may change policy. See Member management. |
The two layers combine. You can keep CASL as the enforcement point in NestJS and let a policy engine decide, through the Permit CASL integration.
If you build the authorization layer yourself, build it on a policy engine such as Open Policy Agent (OPA) or AWS Cedar rather than on hand-written checks, and read these talks on the failure modes first: