Introducing Role-Based Access Control (RBAC) for AuthKit

‍Authenticating users, or verifying that they actually are who they claim to be, is a day 0 need that you simply cannot avoid when building B2B SaaS apps. But as your app grows, larger customers will inevitably ask for authorization, which defines what the users can do within your application after their identity has been verified. Unlike authentication (AuthN), authorization (AuthZ) is more complex to support, since it is a dynamic process with frequent updates to user roles and attributes.

Today, we are launching permissions as part of AuthKit’s core authorization capabilities. Permissions are rules that define the types of resources and actions users can access in your application. Typically, Permissions are assigned to roles and function as important building blocks for role-based access control (RBAC), which supports a more precise and flexible way to manage user access.

For most applications, implementing even basic RBAC can help mitigate unauthorized access to sensitive data. However, maintenance becomes an issue as your authorization hierarchy balloons with complex roles to permissions mappings. With AuthKit, you can leverage a full-stack of AuthN to AuthZ capabilities for free, up to 1 million users.

Permissions use cases

If your application only requires coarse-grained access control, roles alone can be sufficient, but this is suitable only if users need to be separated into broad categories and there is minimal overlap between roles. Simple roles are easier to manage, but lack flexibility for complex access control scenarios such as these:

1. You need to frequently modify access rights or introduce new roles.
2. There is significant overlap in access rights between different roles, but with some variations.
3. You want to minimize code changes when modifying access rights. By abstracting access control checks to permissions, you can add or modify roles and their access rights without changing the application code.

Extending RBAC with Directory Sync

What makes WorkOS RBAC special is that it can be used with Directory Sync to support an identity provider (IdP)-based authorization system.

Most authorization providers require your customer’s admin to generate the data source for roles, resources, and permissions inside your app. With IdP-based authorization systems, the admin can use roles, resources, and permissions data that already exist in their IdP.

This is critical for enterprises that want to manage their users’ roles and permissions from a single source of truth instead of managing hundreds of different SaaS tools and their unique permissions schemes.

For example, if you are a collaboration tool with Nike as a customer, the admin at Nike can easily assign their “engineering” group as a '“member” role within your app, “finance” group as a “billing” role, and “design” group as a “reviewer” role using information that already exists in their IdP.

WorkOS ensures end-to-end data integrity from the moment users are first provisioned, to role assignment, and all the way to access checks that occur in your application.

Getting started with permissions

Here is a tutorial for using permissions with the next-authkit-example app. ‍For more information on roles and permissions, check out the documentation.