Frontend Authorization Compared: CASL, AccessControl, and Casbin

Managing what users can see or do in your app is critical — but doing it cleanly without cluttering your components is hard. The libraries @casl/ability, @casl/react, accesscontrol, and casbin each offer different approaches to this problem. Let’s compare how they define rules, check permissions, and integrate into real frontend code.

🔐 Defining Permissions: Natural Language vs JSON vs Policy Files

@casl/ability uses a fluent, human-readable API to define what a user can do.

// Define abilities using AbilityBuilder
import { AbilityBuilder, createMongoAbility } from '@casl/ability';

const { can, cannot, build } = new AbilityBuilder(createMongoAbility);
can('read', 'Post');
can('update', 'Post', { authorId: userId });
cannot('delete', 'Post');
const ability = build();

This style feels intuitive and maps closely to business requirements like “editors can update their own posts.”

accesscontrol defines permissions as static JSON-like objects grouped by roles.

// Define grants as an object
import AccessControl from 'accesscontrol';

const ac = new AccessControl({
  admin: {
    post: ['create', 'read', 'update', 'delete']
  },
  editor: {
    post: ['read', 'update']
  }
});

// Or add dynamically
ac.grant('editor').execute('update').on('post');

It’s great if your roles and permissions are fixed and you want to load them from config.

casbin uses external policy files (or arrays) with a generic format like [sub, obj, act].

// Define policy in code (usually loaded from file/db)
import { newEnforcer } from 'casbin';
import { MemoryAdapter } from 'casbin';

const adapter = new MemoryAdapter([
  ['admin', 'post', 'read'],
  ['admin', 'post', 'write'],
  ['editor', 'post', 'read']
]);
const enforcer = await newEnforcer('model.conf', adapter);

You also need a model file (model.conf) that defines the matching logic. This is powerful for complex systems but overkill for most frontend apps.

⚠️ Note: casbin’s JavaScript version is not optimized for frontend use. It includes large dependencies and assumes server-side execution. Avoid it in browser bundles unless absolutely necessary.

✅ Checking Permissions in Code

How do you actually test if a user can perform an action?

@casl/ability offers a simple method:

// Check anywhere
if (ability.can('update', post)) {
  // Show edit button
}

The second argument can be a class, string, or object — and it supports field-level and conditional checks.

accesscontrol uses role + resource + action triples:

// Check permission for a role
const permission = ac.can('editor').execute('update').on('post');
if (permission.granted) {
  // Allow action
}

Note: You must know the user’s role ahead of time. There’s no built-in concept of a “current user” — you manage that yourself.

casbin checks using subject, object, and action:

// Enforce policy
const allowed = await enforcer.enforce('editor', 'post', 'update');
if (allowed) {
  // Proceed
}

Again, this works but brings unnecessary overhead to the frontend.

🧩 React Integration: Reactive UI Updates

Only @casl/react provides first-class React support.

// Use the <Can> component
import { Can } from '@casl/react';
import { useAbility } from '@casl/react';

function PostActions({ post }) {
  return (
    <>
      <Can I="update" a="Post" of={post}>
        <button>Edit</button>
      </Can>
      <Can I="delete" a="Post">
        <button>Delete</button>
      </Can>
    </>
  );
}

// Or use the hook
function useCanEdit(post) {
  const ability = useAbility();
  return ability.can('update', post);
}

When the underlying ability instance changes (e.g., after login), components using <Can> or useAbility() automatically re-render.

accesscontrol and casbin have no official React bindings. You’d need to wrap their checks in useState/useEffect manually:

// Manual integration with accesscontrol (not ideal)
function PostActions({ post, userRole }) {
  const [canUpdate, setCanUpdate] = useState(false);

  useEffect(() => {
    const permission = ac.can(userRole).execute('update').on('post');
    setCanUpdate(permission.granted);
  }, [userRole]);

  return canUpdate ? <button>Edit</button> : null;
}

This adds boilerplate and doesn’t react to granular changes (like post ownership).

🔄 Updating Permissions at Runtime

User permissions often change during a session (e.g., after role upgrade). How do these libraries handle that?

@casl/ability lets you update rules dynamically:

// Update ability instance
ability.update((can, cannot) => {
  can('publish', 'Post');
});
// All <Can> components re-render automatically

accesscontrol allows adding/removing grants, but won’t notify your UI:

ac.grant('editor').execute('publish').on('post');
// Your React components won’t know unless you trigger a state update manually

casbin supports reloading policies, but again — no frontend reactivity.

📦 Architecture and Bundle Impact

• @casl/ability: Tiny core (~5KB min+gzip), modular design. Only import what you need.
• @casl/react: Adds ~1KB on top of @casl/ability for React-specific logic.
• accesscontrol: ~8KB, includes full RBAC engine but no framework glue.
• casbin: ~30KB+, includes parser, model evaluator, and adapters — too heavy for most frontend use cases.

🛑 Deprecation and Maintenance Status

As of 2024:

• @casl/ability and @casl/react are actively maintained, with regular updates and strong TypeScript support.
• accesscontrol hasn’t had a major release since 2020 but remains stable and functional for basic RBAC. No deprecation notice, but development is slow.
• casbin’s JavaScript port is community-maintained and lags behind the Go core. The team recommends using it only on the backend.

💡 When to Use What: Real Scenarios

Scenario 1: Admin Dashboard with Role-Based UI

You have roles like “admin”, “editor”, and “viewer”, and want buttons to appear/disappear based on permissions.

• ✅ Best choice: @casl/ability + @casl/react
• Why? Natural syntax, reactive updates, and minimal boilerplate.

Scenario 2: Static Permission Model Loaded from Config

Your app loads a JSON permission matrix at startup and never changes it during the session.

• ✅ Acceptable choice: accesscontrol
• Why? Simple setup, no need for reactivity.

Scenario 3: Complex Enterprise Policies (ABAC, Custom Matchers)

You need attribute-based rules like “managers can approve expenses under $10k”.

• ✅ Use Casbin — but only on the backend
• Why? Frontend should not contain policy logic; instead, call an authz API that uses Casbin server-side.

Scenario 4: Lightweight SPA with Simple Rules

You just need to hide a “Delete” button for non-owners.

• ✅ Best choice: @casl/ability alone (no React package needed if you manage state yourself)

📊 Summary Table

💎 Final Recommendation

For frontend authorization, CASL is the clear winner. Start with @casl/ability for the core logic, and add @casl/react if you’re in a React app. It gives you expressive rules, tiny footprint, and automatic UI updates.

Avoid casbin in the browser — push complex policies to your backend. Use accesscontrol only if you have a simple, static role model and don’t mind manual UI updates.

Remember: authorization logic should live as close to the data as possible. Even with CASL, always validate permissions on the server — frontend checks are just for UX, not security.