--- og_image: "/images/guides/casl-vs-casbin-vs-accesscontrol-authorization-rbac-2026.webp" title: "casl vs casbin vs accesscontrol 2026" description: "Compare casl, node-casbin, and accesscontrol for role-based and attribute-based access control in Node.js. RBAC, ABAC, policy definitions, permissions." date: "2026-03-09" author: "PkgPulse Team" tags: ["nodejs", "typescript", "api", "developer-tools"] --- ## TL;DR **CASL** is the most popular isomorphic authorization library — define abilities as "can user X do Y on resource Z?", works in both Node.js and React, integrates with Prisma/MongoDB/Mongoose. **Casbin** is the policy engine — supports RBAC, ABAC, ACL, and custom models via a configuration DSL, used in enterprise systems across many languages. **accesscontrol** is the simpler RBAC library — role-based grant definitions with resource/action/possession patterns. In 2026: CASL for TypeScript-first projects, Casbin for complex multi-model authorization, accesscontrol for simple RBAC. ## Key Takeaways - **CASL**: ~500K weekly downloads — TypeScript-first, isomorphic (Node + browser), Prisma/Mongoose integration - **Casbin**: ~200K weekly downloads — policy engine, PERM model, supports 15+ languages, admin UI - **accesscontrol**: ~200K weekly downloads — simple RBAC, role hierarchy, grant chains - CASL defines abilities: `can("read", "Package")`, `cannot("delete", "Package", { published: true })` - Casbin separates model (WHO can do WHAT) from policy (specific rules) — very flexible - accesscontrol uses grant notation: `ac.grant("admin").createAny("package")` --- ## Authorization vs Authentication ``` Authentication: WHO are you? → Login, JWT, session, OAuth → Libraries: Passport, NextAuth, Lucia, better-auth Authorization: WHAT can you do? → Permissions, roles, policies → Libraries: CASL, Casbin, accesscontrol (this article) RBAC (Role-Based Access Control): User → has Role → Role grants Permissions "admin can delete any package" ABAC (Attribute-Based Access Control): User attributes + Resource attributes + Context → Permission decision "user can edit package IF user.id === package.authorId AND package.status !== 'published'" ``` --- ## CASL [CASL](https://casl.js.org) — isomorphic authorization: ### Define abilities ```typescript import { AbilityBuilder, createMongoAbility, MongoAbility } from "@casl/ability" type Actions = "create" | "read" | "update" | "delete" | "manage" type Subjects = "Package" | "User" | "Comment" | "all" type AppAbility = MongoAbility<[Actions, Subjects]> function defineAbilitiesFor(user: { id: string; role: string }) { const { can, cannot, build } = new AbilityBuilder(createMongoAbility) switch (user.role) { case "admin": can("manage", "all") // Admin can do everything break case "editor": can("read", "Package") can("create", "Package") can("update", "Package") // Can update any package cannot("delete", "Package", { published: true }) // Can't delete published can("read", "Comment") can("delete", "Comment", { authorId: user.id }) // Own comments only break case "viewer": can("read", "Package") can("read", "Comment") can("create", "Comment") can("update", "Comment", { authorId: user.id }) // Own comments only can("delete", "Comment", { authorId: user.id }) break default: can("read", "Package") // Public: read-only } return build() } ``` ### Check permissions ```typescript const ability = defineAbilitiesFor({ id: "user-123", role: "editor" }) // Check: ability.can("read", "Package") // true ability.can("delete", "Package") // true (unpublished) ability.cannot("delete", subject("Package", { published: true })) // true // In Express middleware: function authorize(action: Actions, subject: Subjects) { return (req, res, next) => { const ability = defineAbilitiesFor(req.user) if (ability.can(action, subject)) { next() } else { res.status(403).json({ error: "Forbidden" }) } } } app.delete("/api/packages/:id", authorize("delete", "Package"), deleteHandler) ``` ### With Prisma (CASL + Prisma integration) ```typescript import { accessibleBy } from "@casl/prisma" // Automatically filter database queries by user permissions: app.get("/api/packages", async (req, res) => { const ability = defineAbilitiesFor(req.user) // Only returns packages the user CAN read: const packages = await prisma.package.findMany({ where: accessibleBy(ability).Package, }) res.json(packages) }) // Editor sees all packages // Viewer sees only non-draft packages // The WHERE clause is generated automatically from CASL abilities ``` ### React integration (isomorphic) ```typescript import { Can } from "@casl/react" function PackageCard({ pkg, ability }) { return (

{pkg.name}

) } ``` --- ## Casbin [Casbin](https://casbin.org) — policy engine: ### Model definition (PERM) ```ini # model.conf — RBAC model: [request_definition] r = sub, obj, act [policy_definition] p = sub, obj, act [role_definition] g = _, _ [policy_effect] e = some(where (p.eft == allow)) [matchers] m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act ``` ### Policy rules ```csv # policy.csv: p, admin, package, read p, admin, package, write p, admin, package, delete p, admin, user, read p, admin, user, write p, editor, package, read p, editor, package, write p, editor, comment, read p, editor, comment, write p, viewer, package, read p, viewer, comment, read p, viewer, comment, write # Role hierarchy: g, alice, admin g, bob, editor g, charlie, viewer ``` ### Node.js usage ```typescript import { newEnforcer } from "casbin" // Load model and policy: const enforcer = await newEnforcer("model.conf", "policy.csv") // Check permission: const allowed = await enforcer.enforce("alice", "package", "delete") // true — alice is admin, admin can delete packages const denied = await enforcer.enforce("charlie", "package", "write") // false — charlie is viewer, viewers can't write packages // Express middleware: function casbinAuth(obj: string, act: string) { return async (req, res, next) => { const allowed = await enforcer.enforce(req.user.username, obj, act) if (allowed) { next() } else { res.status(403).json({ error: "Forbidden" }) } } } app.delete("/api/packages/:id", casbinAuth("package", "delete"), deleteHandler) ``` ### ABAC model (attribute-based) ```ini # model.conf — ABAC: [request_definition] r = sub, obj, act [policy_definition] p = sub_rule, obj_rule, act [policy_effect] e = some(where (p.eft == allow)) [matchers] m = eval(p.sub_rule) && eval(p.obj_rule) && r.act == p.act ``` ```typescript // Check with attributes: const allowed = await enforcer.enforce( { role: "editor", department: "engineering" }, { type: "package", status: "draft" }, "delete" ) ``` ### Database adapter (persist policies) ```typescript import { newEnforcer } from "casbin" import TypeORMAdapter from "typeorm-adapter" // Store policies in PostgreSQL: const adapter = await TypeORMAdapter.newAdapter({ type: "postgres", host: "localhost", port: 5432, database: "casbin", }) const enforcer = await newEnforcer("model.conf", adapter) // Add policy at runtime: await enforcer.addPolicy("dave", "package", "read") // Remove policy: await enforcer.removePolicy("dave", "package", "read") ``` --- ## accesscontrol [accesscontrol](https://github.com/onury/accesscontrol) — simple RBAC: ### Define grants ```typescript import { AccessControl } from "accesscontrol" const ac = new AccessControl() // Admin: ac.grant("admin") .createAny("package") .readAny("package") .updateAny("package") .deleteAny("package") .createAny("user") .readAny("user") .updateAny("user") .deleteAny("user") // Editor: ac.grant("editor") .createOwn("package") .readAny("package") .updateOwn("package") // Own packages only .deleteOwn("package") .readAny("comment") .createOwn("comment") .updateOwn("comment") .deleteOwn("comment") // Viewer (extends editor's read permissions): ac.grant("viewer") .readAny("package") .readAny("comment") .createOwn("comment") .updateOwn("comment") // Role hierarchy: ac.grant("superadmin").extend("admin") ``` ### Check permissions ```typescript // Check: const permission = ac.can("editor").createOwn("package") console.log(permission.granted) // true console.log(permission.attributes) // ["*"] (all attributes) // With attribute filtering: ac.grant("viewer").readAny("package", ["name", "version", "downloads"]) // Viewers can only see name, version, downloads — not internal fields const perm = ac.can("viewer").readAny("package") const filtered = perm.filter(packageData) // Returns only { name, version, downloads } — strips other fields ``` ### Express middleware ```typescript function authorize(action: string, resource: string) { return (req, res, next) => { const permission = ac.can(req.user.role)[action](resource) if (!permission.granted) { return res.status(403).json({ error: "Forbidden" }) } // Filter response attributes: req.permission = permission next() } } app.get("/api/packages", authorize("readAny", "package"), async (req, res) => { const packages = await PackageService.getAll() // Filter each package to only allowed attributes: const filtered = packages.map(pkg => req.permission.filter(pkg)) res.json(filtered) }) ``` --- ## Feature Comparison | Feature | CASL | Casbin | accesscontrol | |---------|------|--------|--------------| | RBAC | ✅ | ✅ | ✅ | | ABAC | ✅ | ✅ | ❌ | | Isomorphic (browser) | ✅ | ❌ | ❌ | | Prisma integration | ✅ | ❌ | ❌ | | React components | ✅ (``) | ❌ | ❌ | | Policy DSL | ❌ | ✅ | ❌ | | Database persistence | Via Prisma | ✅ (adapters) | Manual | | Multi-language | JS/TS only | 15+ languages | JS/TS only | | Admin UI | ❌ | ✅ | ❌ | | TypeScript | ✅ First-class | ✅ | ⚠️ | | Weekly downloads | ~500K | ~200K | ~200K | --- ## Designing an Authorization Model Before implementing authorization, design your permission model explicitly. The most common mistake is adding authorization as an afterthought — bolting `if (user.role !== "admin") return 403` checks onto routes without a coherent model. A good authorization model answers three questions for every operation: who (subject) can do what (action) on which data (resource), and under what conditions (constraints). CASL's ability definition forces this thinking explicitly at setup time. Casbin's model file makes the policy structure visible as configuration separate from business logic. AccessControl's grant notation encodes ownership semantics (Any vs Own) that are easy to overlook when writing ad hoc role checks. Whichever library you choose, document the full permission matrix — which roles have which permissions on which resources — in a way that non-developers can review, because the business requirements for authorization are often defined by product managers and compliance teams rather than engineers. ## Production Security Considerations Authorization libraries are security-critical code and deserve more review than typical utility dependencies. CASL's MongoDB-style conditions (`{ authorId: user.id }`) must be validated server-side on every mutation — never trust the client to send the correct conditions. The `accessibleBy(ability).Package` Prisma integration is particularly powerful, but verify that it generates correct SQL `WHERE` clauses for your specific permission model rather than assuming it handles every edge case. Casbin's `enforce()` call is synchronous or async depending on the adapter, and failing open (defaulting to `true` on errors) is a critical vulnerability — always fail closed and log the enforcement failure for investigation. ## Performance and Caching Strategies In high-traffic APIs, authorization checks on every request can become a bottleneck if the policy data must be fetched from a database. Casbin supports adapter-level caching and policy auto-loading on a configurable interval — enable this for production deployments where policies change infrequently. CASL abilities should be built once per request from the session's role/permission data rather than re-queried from the database each time. Cache the serialized ability object in the JWT payload or session store for read operations, but always re-derive abilities for write operations where stale permissions create security risks. The accesscontrol library's synchronous `can()` checks are naturally fast since all grants are held in memory. ## TypeScript Integration CASL's TypeScript integration is the strongest of the three. Defining `type Actions = "create" | "read" | "update" | "delete"` and `type Subjects = "Package" | "User"` enables the TypeScript compiler to catch calls like `ability.can("publish", "Package")` where "publish" is not a valid action — a compile-time error rather than a silent runtime bug. Casbin's TypeScript SDK provides types for the enforcer API but not for policy structure — the string-based `enforce("alice", "package", "delete")` call is untyped and can silently fail if the argument order doesn't match the model definition. For accesscontrol, the community `@types/accesscontrol` package covers the main API but the attribute filtering system is loosely typed, requiring explicit casting at the point where `permission.filter(data)` returns an `any`. ## Multi-tenancy and Organizational Hierarchy CASL's multi-tenancy story uses scoped abilities — create separate ability instances per tenant, keyed by the tenant ID from the JWT. Casbin has a dedicated multi-tenancy model template where the tenant is added to the request definition (`r = sub, dom, obj, act`) enabling policy rules like `p, admin, tenant-A, packages, write`. This domain-aware RBAC is Casbin's strongest differentiator for SaaS platforms where each organization has independent role hierarchies. The accesscontrol library has no built-in multi-tenancy support — teams typically instantiate separate `AccessControl` objects per tenant or encode the tenant in the resource name as a prefix. ## Migration Between Libraries Migrating from accesscontrol to CASL is the most common migration path as applications grow beyond simple role-based grants. The conceptual mapping is direct: `ac.grant("admin").createAny("package")` becomes `can("create", "Package")` in CASL. The significant difference is that CASL's field-level conditions replace accesscontrol's attribute array filtering — you gain more expressive power (`{ authorId: user.id }`) but lose the automatic field stripping that `permission.filter(data)` provides. Teams migrating from Casbin to a JavaScript-native solution typically choose CASL because Casbin's policy-file approach creates friction in TypeScript codebases that want compile-time guarantees rather than runtime policy parsing. ## Auditing Permission Changes and Compliance Enterprise applications often require audit logs of authorization changes — who granted a permission, when it was revoked, and what policy change caused an access control decision. CASL's ability definitions are code-defined, meaning permission changes are tracked through version control — the git history of your ability factory function serves as an audit trail for permission logic changes. For runtime audit logging of access control decisions, wrap CASL's `ability.can()` calls in a decorator or middleware that logs the subject, action, resource, and decision to an append-only audit log. Casbin's policy persistence in a database enables audit logging at the storage layer — any adaptor write operation (adding or removing a policy rule) can be intercepted and logged. The Casbin audit middleware records every `enforce()` call result along with the subject, object, and action that were evaluated. For regulated industries (healthcare, finance, government), the combination of Casbin's runtime enforcement logging and policy version history satisfies the most common compliance requirements for access control auditing. ## Testing Authorization Logic Comprehensively Authorization logic is security-critical code that deserves thorough test coverage, yet it is frequently undertested because the tests require scaffolding a user context and request environment. With CASL, test your ability definitions directly by calling `ability.can("action", subject)` in unit tests without any HTTP layer — create ability instances for different user roles and assert the expected permission outcomes for each role. Use table-driven tests to cover the combinatorial space: each role crossed with each action on each subject type. Casbin's policy engine can be tested with in-memory adapters — load the model and policies programmatically and call `enforcer.enforce(sub, obj, act)` to verify that the policy produces the expected allow or deny result. Pay particular attention to negative tests: verify that an admin role does NOT have permissions it shouldn't have, rather than only testing that it has the permissions it should. For accesscontrol, test the grant definitions by calling `ac.can(role).createAny(resource).granted` and verifying the boolean outcome matches your expected permission model before any HTTP requests are made. ## When to Use Each **Choose CASL if:** - TypeScript-first project — best type inference for abilities - Need isomorphic authorization (same rules in Node.js AND React) - Using Prisma — `accessibleBy()` auto-filters database queries - Want ABAC with MongoDB-style conditions (`{ authorId: user.id }`) **Choose Casbin if:** - Complex authorization requirements (RBAC + ABAC + custom models) - Multi-language system — same Casbin model across Go, Java, Python, Node.js - Need a policy admin UI for non-developers to manage permissions - Want to store policies in a database with hot-reload **Choose accesscontrol if:** - Simple RBAC is sufficient — roles → resources → actions - Need attribute filtering (only return certain fields based on role) - Own vs Any distinction is your primary access pattern - Straightforward, minimal API --- ## Methodology Download data from npm registry (weekly average, February 2026). Feature comparison based on @casl/ability v6.x, casbin v5.x, and accesscontrol v2.x. *[Compare authorization and security packages on PkgPulse →](https://www.pkgpulse.com)* *See also: [pm2 vs node:cluster vs tsx watch](/guides/pm2-vs-node-cluster-vs-tsx-watch-process-2026) and [h3 vs polka vs koa 2026](/guides/h3-vs-polka-vs-koa-lightweight-http-frameworks-nodejs-2026), [better-sqlite3 vs libsql vs sql.js](/guides/better-sqlite3-vs-libsql-vs-sql-js-sqlite-nodejs-2026).*