Awesome Open Source
Awesome Open Source

Access Control Plus

License version npm Typescript

CircleCI codecov Maintainability NSP Status Known Vulnerabilities

Rich access control featuring roles, inheritance, dynamic attribute tests, backend integration and more.

npm install accesscontrol-plus


  • Roles with inheritance
  • Backend integration
  • Permissions on resource fields
  • Explanations for why permissions were granted or denied
  • Wildcard matching
  • Modular policy definition
  • Constraints on resources
  • Typescript ready

Quick start

// Create AccessControlPlus instance to manage a group of roles
import {AccessControlPlus} from 'accesscontrol-plus';

const accessControl = new AccessControlPlus();

// Define roles, scopes and conditions
      .read.onFields('*', '!dontreadthisfield') // allow read on all fields but one

function userIsAuthor({user, post}) {
  return == post.authorId;

// Test whether permission is granted
let permission;

permission = await accessControl.can('user', 'posts:create');
// permission.granted => truthy

permission = await accessControl.can('user', 'users:create');
// permission.granted => falsy

permission = await accessControl.can('admin', 'users:create');
// permission.granted => truthy (because of inheritance)

permission = await accessControl.can('user', 'posts:read');
// permission.granted => truthy
// permission.field('text') => true (matched by '*')
// permission.field('dontMatchThisField') => false (explicitly not granted)

permission = await accessControl.can('user', 'posts:read:text')
// permission.granted => truthy

// using context:
permission = await accessControl.can(
  'user',                                   // role
  'posts:update',                           // scope
  { user: {id: 123}, post: {authorId: 123}} // context
); // permission.granted => truthy


Role Based Access Control (RBAC) versus Attribute Based Access Control (ABAC)

Role based authorization defines permissions in terms of roles in an organization - users, editors, authors, etc. This is convenient, but RBAC relies on static definitions and can't use contextual information (like time, location, dynamic organizational relationships, etc) to determine access rights. In traditional RBAC, contextual tests must be performed in other layers of an application. On the other hand, ABAC allows use of contextual information, but is also more complicated, and is sometimes described as overkill for solving typical problems. For more discussion, see:

AccessControlPlus: RBAC with ABAC-powers

This library combines useful properties of RBAC and ABAC. You grant permission in terms of roles, making it easy to define and manage your policies, like tradition RBAC, and implement fine-grained context-sensitive tests that integrate with your backend, like ABAC.

The AccessControlPlus class provides the top-level API of this library. Use it to define role permissions (using grant or deny), add conditions using where, and and or, and test whether a permission is granted (using can). (See API).

const ac = new AccessControlPlus();
  .where(authorIsResourceOwner); // a function you write which tests attributes


Roles, Resources, Actions and Inheritance

Each role (e.g., "admin" or "user") has scopes which grant or deny permission to perform actions on resources, potentially limited to certain fields of the resource. Roles can inherit scopes from other roles.


A scope name is a resource:action pair or a resource:action:field triplet. For example,

"post:read" // read a post resource
"post:read:text" // read the text field of a post resource
Shortcuts for creating scopes
const userRole = accessControl.grant('user');

// the following are all equivalent:
userRole.resource('post').create // see CRUD shortcuts
Effect: Grant or Deny

A scope has an effect, which is either grant or deny, which is determined by how the role is accessed.


const ac = new AccessControl();
  .grant('user').scope('comments:read') // creates a grant scope
  .deny('user').scope('comments:*') // creates a deny scope
How permission is determined

Scopes are checked in the order defined.

Permission is granted if a grant scope is found for the specified role (or inherited roles) for the specified resource, action and optional field. If no grant scope is matched, the permission is denied where permission.denied is an array of strings describing all the scopes which were attempted.

Permission is immediately denied if a deny scope is matched.

Given, a request for a user role to read the text field of a post resource:

// request permission to read the text field of a post:
const permission = accessControl.can('user', 'post:read:text', context);
  1. Look for the specified role (user)
    • if user doesn't exist, look for the * role
    • if no role can be found, return a denied permission
    • otherwise, continue
  2. Look for the specified resource (post) on the role
    • if post resource doesn't exist, look for the * resource
    • if no resource can be found, return a denied permission
  3. Look for the read action
    • if read action doesn't exist, look for the * action
    • if no action can be found, return a denied permission
    • otherwise, there will be a list of one or more scopes defined for the action
  4. Iterate through each scope
    • Check whether the field (if requested in the call to can) is granted by the scope, and whether the condition (if provided) is satisfied. If these tests are satisfied, generate a permission and return it
  5. If no scope can be found for the current role, repeat this process for all inherited roles until finished
  6. If no permission was found, return a permission where denied contains descriptions of all the scopes which matched but failed


A permission is an instance of the Permission class returned by AccessControlPlus#can:

const permission: Permission = await accessControl.can('user', 'post:read');

// If the permission is granted, it is set to a "permission path", which
// which shows which scope tested successfully
permission.granted === "grant:user:post:read:0:::"

// if permission is denied, the permission paths of all scopes which were attempted
permission.denied === [ "..." , "..." } ] // the tests attempted and failed

If constraints were defined for the scope, the permission will contain a constraint key.

permission paths

Permission paths are strings structured as:


Note: the scopeIndex indicates which


Scopes can be restricted with conditions, javascript sync or async functions of the form:

type Condition = (ctx: Context)=> Promise<boolean> | boolean // type Context = any

Conditions should be named functions. The condition name is used to generate a description string, assigned to permission.grant

// Add a condition to post:update:
  .where(userIsOwner); // add a condition

function userIsOwner({user, resource}) {
  return === resource.ownerId;

permission = await accessControl.can('user', 'post:update',
  { user:     { id:      1 },
    resource: { ownerId: 1 }});

permission.granted // => 'grant:user:post:update:0::userIsOwner'

If a condition throws an error, it is treated as though it returned false. (Note: this may cause unexpected behavior if a condition is used to deny, so this behavior may change in the future, such that exceptions will be treated as true for deny).


The context is a developer-specified value that is passed to the test function can, which in turn passes the value to various developer-defined functions involved in testing scopes. Arbitrary values such as the current user, the request parameters, time, environment and location can be passed in the context. See the example above under Conditions.

type Context = any;


Fields represent attributes of the resource. They can be allowed or denied using the onFields method.

// E.g., Allow fields and disallow specific fields:
accessControl.grant('user').resource('post').read.onFields('*', '!stats');

// request permission for action on a specific field:
ac.can('user', 'post:read:stats'); // permission denied
ac.can('user', 'post:read:foo'); // permission granted
permission = ac.can('user', 'post:read');
// permission granted with
// permission.fields = { "*": true, "stats": false }

Alternatively, you can request a permission for the action, and you will receive a permission with a fields property which is an object describing which fields are accessible:


Field permissions can also be calculated dynamically be providing a function (which can be async). The function returns an Object mapping field names to boolean values indicating whether the field is granted or not.
E.g., the following is equivalent to the `onFields` call shown above.
accessControl.grant('user').resource('post').read.onDynamicFields((ctx: Context) => ({
  '*': true, // grant all fields
  stats: false



Top level object which exposes the API.


import {AccessControlPlus} from 'accesscontrol-plus';
const accessControl = new AccessControlPlus();


Returns a Role object which can be used to grant permissions

// accessControl.grant(roleName)
accessControl.grant('admin') // => Role instance


Returns a Role object which can be used to deny permissions

// accessControl.deny(roleName);
accessControl.deny('admin') // => Role instance


Async function returning a permission indicating whether the given role can access the scope:

// context is a developer-defined value passed to conditions
// (see Scope #where, #and, #or)
const context = { user: { id: 'the-user-id' } };
// accessControl.can(role, scope, context)
const permission = await accessControl.can('admin', 'delete:user', context);
if (permission.granted) {
  // delete the user
} else {
  // report access denied

The first argument can also be a list of role names.


Represents a named role.


Inherit scopes from another role:

// role.inherits(roleName)
role.inherits('public'); // => Role instance


Access a resource of a particular role:

// role.resource(resourceName)
role.resource('article'); // => Resource instance


Access a scope, a short cut for accessing a resource then accessing an action:

// role.scope(scopeName)
role.scope('article:read'); // same as role.resource('article').action('read')


A resource object is obtained using the Role.resource method


// resource.action(actionName)
resource.action('read'); // => Scope

Note: you can create multiple scopes per action. This allows you to provide different constraints and fields for the same action:

    .withConstraint(FooBarConstraint).onFields('foo', 'bar')

CRUD shortcuts

resource.create // = resource.action('create');   // = resource.action('read');
resource.update // = resource.action('update');
resource.delete // = resource.action('delete');


Represents a specific permission, and enables setting conditions and constrains on the permission.


Sets one or more tests which must all pass for the permission to be granted. This method is equivalent to scope.and, except for the name generated in the permission.grant and permission.deny:

// scope.where((context: Context) => boolean)
// scope.where(async (context: Context) => Promise<boolean>)
function async ownsResource({ user, request }) {
  const resource = await MyResource.loadFromDB({ id: });
  return ===;
scope.where(ownsResource); // => Scope


Grants permission for the scope if all of the tests return truthy values:

scope.and(test1, test2, test3...); // => Scope


Grants permission for the scope if any of the tests return a truthy value:

scope.or(test1, test2, test3...); // => Scope


Note: constraints are deprecated and may be removed from a future version of the API.

Add a function which returns a constraint useful to the developer for passing to a function that accesses a resource:

  .withConstraint(({user})=>({ ownerId:})); // => Scope
let permission = await accessControl.can('user', 'article:create', { user: { id: 123 }});
if (permission.granted) {
  await Article.create(permission.constraint); // { ownerId: 123 }


Restrict the grant/denial to specific fields. Provide a list of fieldNames. Use * for all fields, !{fieldName} to exclude a field:

// grant on all fields
accessControl.can('admin', 'user:read:superPrivateData');
// permission.granted => "grant:admin:user:read:0:superPrivateData:"
// deny on specific fields
  .onFields('*', '!privateData');
permission = await accessControl.can('admin', 'user:read:privateData');
// permission.granted => undefined
// permission.denied = ["grant:admin:user:read:0:privateData:"]
permission = await accessControl.can('admin', 'user:read:name');
// permission.granted = "grant:admin:user:read:0:name:"
// grant on specific fields
await accessControl.can('admin', 'user:read:name');
// permission.granted => yes
await accessControl.can('admin', 'user:read:phoneNumber'); // permission.granted => no


Generate field grants dynamically, given a context. You can use async calls, if needed:

  .onDynamicFields(async ({admin, user}: Context) => {
    const permissive = await myBackend.adminHasPermissionFromUser(admin, user);
    if (permissive) {
      return { '*': true };
    } else {
      return { 'id': true, 'userName': true, 'phoneNumber': true };


Object returned by AccessControlPlus#can


If permission granted this will be a string describing the scope granted.


If permission denied, this is set to an array of objects that contain


Tests whether permission was granted for the specified field. Accounts for wildcards and denied fields (!foo) provided in .onFields.

permission.field('foo') // => true or false

Extended Example

import AccessControlPlus from 'accesscontrol-plus';

function userIsResourceOwner({user, resource}) {
  return === resource.ownerId;
function userImpersonatesResourceOwner({user, resource}) {
  return user.impersonationId === resource.ownerId;
function articleIsPublished({resource}) {
  return resource.state === 'published';

const ac = new AccessControlPlus();
// 4 roles in this scenario: public, author, admin, superadmin
  // Define roles:
  .deny('public') // start by disallowing the public access to everything
        .onFields('*', '!viewers') // allow all fields except viewers
        // add a constraint - to include when creating the article:
        .withConstraint(({user})=>({ ownerId: }))
      .action('read') // === .scope('article:read')
      .action('update') // === .scope('article:update')
  // ADMIN

// The following are objects which are generated by your code
// during a request - users, resources, etc:
const user = { id: 1234 }; // determined by request authentication
const draft = { ownerId: 1234, state: 'draft', text: '...' }; // retrieved from db
const published = { ownerId: 1234, state: 'published', text: '...' }; // retrieved from db
const adminUser = { id: 999, impersonationId: 1234 };
const superAdmin = { id: 222 };

async function testPermissions {
  let permission;
  // public can read published articles
  permission = await accessControl.can('public', 'article:read', { user: null, resource: published });
  // permission.granted => truthy

  // public can't read draft articles
  permission = await accessControl.can('public', 'article:read', { user: null, resource: draft });
  // permission.granted => falsy
  // permission.denied = ['public:article:read:articleIsPublished']

  // author can read their own draft article
  permission = accessControl.can('author', 'article:read', { user, resource: draft });
  // permission.granted => truthy

  // auth can update their own article
  permission = accessControl.can('user', 'article:update', { user: user, resource: draft });
  // permission.granted => truthy

  // admin cannot update an author's article, even if they are impersonating them
  permission = accessControl.can('admin', 'article:update', { user: adminUser, resource: draft});
  // permission.granted => falsy
  // permision.denied = [ 'grant:author:article:update:0::userIsResourceOwner' ]

  // admin can read a draft article if they are impersonating the author
  permission = accessControl.can('admin', 'article:read', { user: adminUser, resource: draft});
  // permission.granted => truthy

  // superadmin can do anything to user resources
  permission = accessControl.can('superadmin', 'user:delete', { user: superAdmin, resource: user });
  // permission.granted => truthy
Alternatives To Accesscontrol Plus
Select To Compare

Alternative Project Comparisons
Related Awesome Lists
Top Programming Languages
Top Projects

Get A Weekly Email With Trending Projects For These Topics
No Spam. Unsubscribe easily at any time.
Typescript (245,560
Role (17,671
Permission (11,613
Authorization (5,850
Rbac (1,373
Access Control (1,111
Abac (182
Scope (99