How Permit.io Works

Authorization has to evolve with your application. Requirements grow from a simple admin/non-admin check into roles, attributes, and relationships, and authorization logic scattered through your code becomes hard to keep consistent.

Permit solves this by separating policy from code.

Decoupling policy and code

How a permission decision is made

1. IdentityA user, service, or AI agent, authenticated by your identity provider.
2. RequestYour code asks: can this identity perform this action on this resource?
3. Policy decision pointRuns in your VPC next to your services and evaluates policy with OPA or Cedar.
4. DecisionAllow or deny, returned to your code. The decision log records why.
5. AuditEvery decision is logged and can be forwarded to your logging stack or SIEM.

The same five steps apply whether the caller is a person clicking a button or an agent calling a tool. Only the identity changes.

Decoupling policy and code is a best practice: your application code asks an authorization microservice for decisions, and the policy lives in that microservice instead of in your code. Open-source policy engines such as Open Policy Agent (OPA) and AWS Cedar are a solid base for that microservice. Running it yourself still takes ongoing work: connecting it to your application, to its policy sources, and to the data it needs, and building the access-control interfaces on top.

Permit handles that work. It builds on these open-source projects and gives you:

• An authorization microservice based on your policy engine of choice
• OPAL, an administration layer that keeps the policy engine up to date with the latest policy and data
• SDKs for your language
• A cloud service to manage it all

Permit's Hybrid Architecture

The Permit architecture has two parts, a control plane and a data plane:

• The control plane is where you manage your authorization layer, in the UI or the API. It runs in Permit's cloud and holds your policy and the identifiers it refers to (user keys, roles, attributes).

• The data plane is where decisions are made. Policy decision points (PDPs) run in your own VPC or network, next to your services, and can use the data your policies need (names, emails, and other attributes) without sending it to Permit.

Hybrid deployment

Permit control plane

Permit cloud

• Policy editor and API
• Policy as code in your Git repo
• Audit logs

OPAL syncs policy and data

Your networkVPC, data center, or on-prem

Policy decision points

Run beside your services and answer checks locally, without a round trip to the control plane.

• Your apps and APIs
• Your data

Policy is managed in the control plane and evaluated in your network. The data your policies need can stay on your side.

With this split, you manage authorization in Permit without exposing sensitive data to the cloud:

• Sensitive data can stay in your network, which helps with security and compliance requirements.

• Authorization decisions are made on your side, without a network round trip to Permit. Run the PDP as a sidecar and checks go over the loopback interface, with no network latency at all.

• Checks are answered by the PDP in your network, so they don't depend on Permit's availability.

Two components make the hybrid architecture work, OPAL and the Permit PDP:

OPAL

Open Policy Administration Layer (OPAL) is an open-source project developed and maintained by the Permit.io team. It is an administration layer for policy engines: it detects changes to policy and policy data in real time and pushes live updates to your agents.

OPAL has two parts, the OPAL Server and the OPAL Client.

The OPAL Server runs in Permit's cloud service. It creates a pub/sub channel that OPAL clients subscribe to, tracks a Git repository (by webhook or polling) for policy updates, and pushes those updates to clients as diffs, so only changes are sent.

The OPAL Client runs inside the PDP.

The Policy Decision Point (PDP)

A PDP is a network node that answers authorization queries using policies and contextual data. The Permit PDP is your authorization microservice, and you deploy it beside your own services.

The Permit PDP has two parts, a policy engine and the OPAL Client:

• The policy engine evaluates authorization queries, using the policy rules as the source of truth. Policies are written in a policy language (such as Rego or Cedar), and the engine interprets them to return a decision for each query.

  Permit is policy engine agnostic and supports Open Policy Agent and AWS Cedar, so you can choose the engine that fits your needs.

• The OPAL Client runs alongside the policy engine and keeps it up to date with the latest policy and data. It subscribes to topic-based pub/sub updates for both data and policy, and fetches them from the OPAL Server (in Permit's cloud service) and from any other relevant sources (for example databases, APIs, and third-party services).

Together, Permit's cloud service, OPAL, and the PDP let you change your authorization layer in Permit (in the UI or the API) and have those changes reach your application right away, without your data leaving your network.

For more information, see the PDP documentation.