Why Permit.io?
This page is for engineering leads and architects deciding whether to build application authorization in-house or use Permit.io. It explains what Permit provides and how each part works.
What authorization covers
Authorization decides what a signed-in user or service can do in your application. For example: can Macy, an editor in the acme-corp tenant, publish a document?
Answering that question in production takes more than an if statement in your code:
- Your services need a fast, consistent decision at every enforcement point.
- Your product, support, and security teams need to change who can do what without a code release.
- Your customers' administrators need to manage their own users and approve access requests.
Permit provides one layer for each of these needs.
Decision infrastructure for your services
Permit decouples authorization policy from application code. Your code calls permit.check(), and a policy decision point (PDP) evaluates the policy and returns the decision.
- Control plane. Permit's cloud stores your policy and the identifiers it refers to: users, roles, tenants, and resources. You manage it in the dashboard, the API, the Terraform provider, or GitOps.
- PDP. You run the PDP container in your own network, next to your services, or use the managed Cloud PDP. Open Policy Administration Layer (OPAL) pushes policy and data changes from the control plane to each PDP.
- SDKs and APIs. SDKs for your backend language send checks to the PDP and manage users, roles, and tenants through the Permit API. See the SDKs overview.
A PDP container answers thousands of checks per second with sub-millisecond latency. When it runs as a sidecar, checks go over the loopback interface, so there is no network latency. For the architecture, see How Permit.io works.
A back office for your team
The Permit dashboard lets the people who manage access change authorization without writing code. A product manager can grant the Editor role publish on Document in the Policy Editor, and the change reaches every PDP without a deploy.
Member roles (Workspace Owner, Workspace Editor, and Workspace Viewer) control which team members can change policy, for the whole workspace or for a single project or environment. For example, a product manager can be an editor in the staging environment and a viewer in production. The Audit Log screen shows the decisions your PDPs make, so the team can see why a user was allowed or denied.
Embeddable UI for your users
Permit Elements are embeddable UI components for user management, access requests, approvals, and audit logs. You embed them in your application so your customers' administrators can manage access in their own tenant, and your Permit policy controls what each administrator can do in those components.
Compliance
Permit.io is SOC 2 Type II attested and HIPAA compliant. For security and compliance details, see permit.io.