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) .

Within team management, I can add new people to the team, but not assign them any other role, apart from Admin.​

Authorization for Authorization is one of the biggest challenges (due to its recursive nature). We are aware of the irony here. This has been partially solved by the release of “Permit Elements” - which also enables you to easily create embeddable interfaces solving the challenges of AuthZ for AuthZ.

What does SET AS ACTIVE ENVIRONMENT do? If I set dev as active does it suppress API calls using production secret keys?​

It just means which is the current environment you're viewing in the interface - e.g. when you open the policy editor it would show you the policy / roles / permissions for that environment - it is the same as selecting a different environment from the top navigation bar dropdown menu.

Real World Questions

The following are questions asked in our Slack community (which represent general dilemmas), they are presented 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:

  1. NestJS's AuthZ is very nice, but really not performant - as you move from basic authorization / roles (And it will be a matter of time util you do - e.g. ABAC or ReBAC) with NestJS (Which is just CASL under the hood) you will be saving and querying your roles and attributes from a database, which would yield horrible performance - compared to using a mem-cached agent like OPA (which Permit provides as part of its microservice for authorization - aka the PDP)
  2. Permissions are not only about performance - but also about experiences - instead of having to refactor your access-control every time a new requirement comes in; with Permit's policy-editor and embeddable interfaces, not only would you be able to add experiences without changing your code, you can even delegate some of the power to other stakeholders (e.g. product managers, support, security) , and even the end customers themselves
  3. Lastly, Authorization is a hard and deep problem (just think about authorization for authorization [who can give permissions to assign permissions]). Just like with authentication and encryption - you don't want to roll your own unless you're 100% sure you know the problem space- as getting things wrong may not only cost a lot of additional RND time in refactors, but may also result in security issues.

If you want to build on your own- I recommend these following talks:

and building a microservice for authorization on-top of a mature agent like OPA or Ceder from AWS - you can layer NestJS (via CASL) on top of this (We have a CASL ability for Permit, too if you want to use it) We'll be happy to talk more about this over Zoom both with you and your team: https://calendly.com/permitio/meeting

Contents