Resource hub · Engineering
Authorization resources for engineering teams
Most teams start with a role column and a few if statements. A year later the checks are scattered across services, every new customer wants a custom role, and nobody can say for sure who can see what.
This page collects the Permit material we would hand a developer on day one of fixing that: how to pick a model, how to structure the code, and how to run your first check.
Problems this page helps with
- Choosing between RBAC, ABAC and ReBAC without painting yourself into a corner
- Pulling permission logic out of application code before it spreads further
- Supporting tenants, custom roles and sharing without a rewrite
The short version
Keep authorization out of your business logic. Model roles, attributes and relationships in one policy, run the decision point next to your service, and call a single check function from code.
Key concepts
RBAC
Roles such as admin, editor and viewer. Simple to reason about and enough for most apps on day one.
ABAC
Rules on attributes of the user, the resource or the request, like plan tier, region or time of day.
ReBAC
Access that follows relationships: owner of a folder, member of a team, parent of a document.
Multi-tenancy
The same user can be an admin in one tenant and a viewer in another, with no data crossing between them.
What a permission check looks like
- 1
Your app
calls permit.check(user, action, resource)
- 2
Local PDP
evaluates RBAC, ABAC and ReBAC policy
- 3
Decision
allow or deny in milliseconds
- 4
Audit log
who, what, which policy, why
Homegrown checks vs. a policy layer
If statements in every service
- Role logic copied across services and drifting apart
- Every custom role request turns into a code change
- No single answer to "who can see this record?"
One check call, policy outside the code
- One policy model for every service and language
- New roles and rules ship as policy, without a deploy
- Every decision is logged and explainable
How Permit handles it
- 01
Model in the UI, the API or code
Define resources, actions and roles in the policy editor, through the API, or with Terraform. Permit stores the model and distributes the resulting policy to your PDPs.
- 02
Combine the models you need
Policy as code and policy as graph live in one model, so a single check can mix role, attribute and relationship rules.
- 03
Decide locally
As shared in our docs, the PDP runs as a container next to your service, so checks do not cross the internet.
- 04
Start free
The free tier covers 1,000 MAU, 20 tenants and 3 environments, which is enough to build and test a real model.
“One of the main reasons we chose Permit was its ability to support different authorization models. We started with RBAC, but we knew we’d eventually need ABAC and ReBAC as well.”
Go deeper
Pick the right model
- BlogWhat is ReBAC?A plain definition of relationship-based access control, five real examples, and how it compares with RBAC and ABAC.
- BlogChoosing a fine-grained authorization modelA decision tree for combining RBAC for org roles, ABAC for context and ReBAC for sharing, all behind one check call.
- BlogConditions vs. relationshipsWhen an attribute rule is enough and when you really need a relationship graph.
- GuidePlanning your authorization model and architectureA full planning guide covering use cases, user management, approval flows and AI identities before you write code.
Structure the code
- BlogStop rebuilding permissions in application codeWhy authorization belongs in a dedicated control plane, and the signs that your homegrown RBAC has outgrown itself.
- BlogShould you roll your own RBAC?An honest look at the build vs. buy tradeoff for an authorization layer.
- BlogBest practices for multi-tenant authorizationHow to model roles per tenant so one customer never sees another customer's data.
- BlogBest practices for API authorizationThe layers, actors and tools involved in authorizing REST API calls.
Run your first check
- DocsPermit quickstartModel a policy, run a policy decision point (PDP) and make your first permission check.
- DocsEnforcing permissionsThe check, bulk check, user permissions and authorized users APIs you will call from your app.
- DocsSupported SDKsClient libraries for the languages and frameworks you already use.
- DocsReBAC overviewHow relationship-based policies are configured in Permit, with resource roles and role derivation.
Permit classic has a free tier with 1,000 MAU, 20 tenants, 3 environments and 14 days of logs, which is enough to build and test a real model.