The Real Problem with Most RBAC Implementations

Role-Based Access Control (RBAC) is deceptively simple in theory: assign roles to users, grant roles specific permissions, and guard endpoints accordingly. But in real-world REST APIs, things break down fast.

Why? Because developers often bolt RBAC on top of an existing authentication layer without a clear authorization model. The result is brittle code: conditional blocks scattered across route handlers, permission logic duplicated, and unclear separation between identity and authority.

Let’s fix that.

The Scenario

You’re building a backend for a SaaS dashboard. Your API supports:

• Admins – can manage users, billing, and system settings

• Editors – can update content, but not touch users

• Viewers – read-only access to most resources

The API is built with Express, authentication is handled via JWT, and you need a maintainable RBAC layer.

This guide shows how to implement that RBAC layer with:

• Granular permission checks

• Stateless, token-based auth

• Declarative access control

Step 1: Define the Authorization Model

Start by decoupling your roles from permissions. That gives you flexibility as your system evolves.

// roles.js
export const rolePermissions = {
  admin: [
    'user:read',
    'user:create',
    'user:delete',
    'settings:manage',
  ],
  editor: [
    'content:read',
    'content:update',
  ],
  viewer: [
    'content:read',
  ],
};

Roles are just tags. Permissions express capability. This separation is crucial when roles multiply or need to inherit capabilities.

Step 2: Issue JWTs with Role Claims

On login, embed the user's role into the JWT payload — never permissions directly.

// authController.js
import jwt from 'jsonwebtoken';

function login(req, res) {
  const user = db.getUser(req.body.email);
  const token = jwt.sign(
    { sub: user.id, role: user.role },
    process.env.JWT_SECRET,
    { expiresIn: '1h' }
  );
  res.json({ token });
}

This ensures authorization logic remains server-side and modifiable without reissuing tokens.

Step 3: Build a Permission Middleware

Here’s where clarity and power meet: a clean, reusable middleware that enforces permission checks.

// middleware/authorize.js
import jwt from 'jsonwebtoken';
import { rolePermissions } from '../roles.js';

export function authorize(requiredPermission) {
  return (req, res, next) => {
    const authHeader = req.headers.authorization || '';
    const token = authHeader.split(' ')[1];
    if (!token) return res.status(401).send('Missing token');

    try {
      const payload = jwt.verify(token, process.env.JWT_SECRET);
      const permissions = rolePermissions[payload.role] || [];

      if (!permissions.includes(requiredPermission)) {
        return res.status(403).send('Forbidden: insufficient permission');
      }

      req.user = payload;
      next();
    } catch (err) {
      return res.status(401).send('Invalid or expired token');
    }
  };
}

Now your permission checks are declarative and centralized.

Step 4: Secure Your Routes

Apply RBAC at the route level — not inside your controller logic.

// routes/userRoutes.js
import express from 'express';
import { authorize } from '../middleware/authorize.js';

const router = express.Router();

router.get('/', authorize('user:read'), getAllUsers);
router.post('/', authorize('user:create'), createUser);
router.delete('/:id', authorize('user:delete'), deleteUser);

export default router;

This makes permissions auditable at a glance and avoids buried logic inside business code.

Full Example: Permission in Action

Assuming a viewer token:

curl -H "Authorization: Bearer eyJ..." https://api.myapp.com/users
# 403 Forbidden

But with an admin token:

curl -H "Authorization: Bearer eyJ..." https://api.myapp.com/users
# 200 OK

No extra logic required — the RBAC layer handles everything.

Pro Tips from Production

• Use JWT for stateless auth, but store permissions server-side for revocation flexibility.

• Don’t hardcode permissions in handlers — keep them declarative and centralized.

• Add a fallback authorizeAny(...perms) helper for compound checks.

• Log permission failures — it helps trace bugs and audits.

• Integrate with CI tests to ensure route coverage by role.

TL;DR: Secure, Maintainable RBAC in REST APIs

Final Takeaway

RBAC isn’t just about denying access—it’s about codifying trust boundaries in a way that’s composable, auditable, and hard to get wrong.

Do it with scattered if statements and you’ll regret it in six months.
Do it declaratively, and your API will scale as your team does.