Building an Authorization Policy Engine

In this lesson, you will learn how to shift from scattering if/else permission checks throughout your controllers to a centralized, testable "Policy Engine" that evaluates access based on code rather than hardcoded logic.

The Problem with Distributed Logic

When authorization logic (e.g., if (user.role === 'admin' || user.id === doc.ownerId)) lives directly inside your API routes, it becomes a maintenance nightmare. As your application grows, these conditions become complex, inconsistent, and incredibly difficult to unit test. If you need to update a rule—such as allowing "super-users" to view all documents—you might have to hunt through dozens of files, risking an inconsistent security posture.

Building a Centralized Policy Engine

A Policy Engine treats authorization as a pure function. It takes the Subject (the user), the Action (e.g., read, delete), and the Resource (the object being accessed) as inputs, and returns a simple boolean or a Decision object.

By abstracting this into a standalone service, you can test your security rules in isolation without needing to mock HTTP requests or database connections.

Example Implementation

Instead of checking logic in your route, delegate to a PolicyEngine:

// policyEngine.js
const policies = {
  document: {
    read: (user, doc) => user.role === 'admin' || doc.ownerId === user.id,
    delete: (user, doc) => user.role === 'admin'
  }
};

export const can = (user, action, resourceType, resource) => {
  const policy = policies[resourceType]?.[action];
  return policy ? policy(user, resource) : false;
};

In your controller, the check becomes clean and readable:

import { can } from './policyEngine.js';

if (!can(req.user, 'read', 'document', doc)) {
  return res.status(403).send('Forbidden');
}

Why This Matters

This approach implements "Policy-as-Code." Because the policies object is just a collection of standard JavaScript functions, you can write unit tests that verify every edge case—such as what happens when a user is deactivated or a resource is private—without ever starting your server. This centralization ensures that your security rules remain consistent across every microservice and endpoint in your application.

Key Takeaway: By decoupling authorization logic into a centralized, pure-function service, you transform complex, hidden security requirements into auditable, unit-testable code.