Skip to main content
Version: 2.0.0

Frequently Asked Questions

Here you will find answers to all your possible questions regarding Permit.io.

info

This page gets updated regularly as more interesting questions pop-up.

What is Permit.io?​

Permit.io is a fullstack authorization solution that enables developers to bake-in access-control into their products within minutes and have them ready for future demands from customers and regulation.

The Permit.io developer SDK integrates with your product and enables you to add declarative permission checks that are as easy to use as feature flags.

Permit.io is built on strong open source foundations, enables Git-Ops out of the box, and goes far beyond enforcement - providing seamless access control experiences designed for humans that simply work: User Management, API Key management, Audit, User impersonation, and more.

What is the difference between Authentication and Authorization?​

While closely related, authorization and authentication are different.

To simplify with a metaphor - imagine a person is about to enter your home:

Authentication is about identifying who is at the door and deciding whether they may enter or not.

The authorization comes in as soon as the person is in your house, and handles their permissions inside the house - can they open the fridge? Sleep in your bed? Read your diary?

To conclude:

  • Authentication (AuthN) - Who is the user
  • Authorization (AuthZ) - What is the user allowed to do

Is there a free version of Permit.io?​

Of course! Our community version provides authorization capabilities up to 1,000 monthly active users. The best part? It’s free forever.

What's the difference between OPA and OPAL and Permit.io?​

OPA, or Open Policy Agent is a generic policy based decision engine, and OPAL, or Open Policy Administration Layer is a realtime solution to keep the policy agents updated with the policies and data, in an event-driven distributed fashion.

Permit.io is a full-stack authorization solution - covering all the layers required for building access-control for products and services: Infrastructure (e.g., Policy-engines, SDKS, APIs), Back office (the controls the team behind the product needs), and end-user interfaces (e.g. user management, audit logs, api-keys, ...). A key part of Permit.io's infrastructure is the open-source combo of OPA and OPAL.

Can I use other policy-agents with Permit.io (e.g. OSO, Casbin)?​

Yes, please join our slack or contact us at support@permit.io to learn more about these use cases.

Can I Connect my FGA/Google-Zanzibar solution with Permit.io (e.g. AuthZed, Ory Keto, Auth0 Sandcastle)?​

Yes, please join our slack or contact us at support@permit.io to learn more about these use cases.

When the tenant does not represent an end-customer company, then what does it represent?​

A tenant can be a company that you physically cater too, or it can also be a company that your umbrella organization owns and manages internally.

Can Permit help me create an app with multiple companies (tenants), where the admins of each company can invite and manage other users?​

Yes. Let's break it down by topics:

  • Multi-tenancy: Multi-tenancy is a first-class citizen concept in Permit - you can easily define Tenantsand assign users to them both in the UI and API- You can map each tenant (or a few tenants) to a your concept of a company

  • Roles: You can define as many roles as you want (via the UI or API) and assign them to as many users/tenants as you want (even more than one per user)

  • End-user management interface: You can easily enable your end-users to manage their tenants / companies with Permit, by building your own UI on top of Permit's API, or even better use Permit-Elements- ready made and customizable experiences you can embed into your application securely - including a user management interface and Audit logs.

  • Storing user profiles: you can use Permit as a DB to store any data you want about your users. But it's best to have the authorization data synced to Permit and the rest of the data to keep in your apps database (e.g. MongoDB). We recommend you use the same user-id in your app db and in Permit (usually the unique ID you get from your authentication solution) .