BasaFinder, the rental platform I built, has three kinds of users: admins, landlords and tenants. Each one may do different things, so the API has to answer two questions on every request: who is calling, and what are they allowed to do. This post walks through how the Express and TypeScript API in that project answers them, and where the approach has limits.

Roles are a single constant

The three roles live in one object, and the TypeScript type is derived from it, so a typo in a route definition fails at compile time instead of silently allowing nobody (or everybody).

export const USER_ROLE = {
  admin: 'admin',
  landlord: 'landlord',
  tenant: 'tenant',
} as const;

export type TUserRole = keyof typeof USER_ROLE;

Layer 1: an auth middleware that takes the allowed roles

Routes are protected by auth(...roles), a function that returns an Express middleware. It does five things, in this order: read the token, verify its signature, load the user, reject accounts that should not be active, and check the role. This is a simplified version of the real code.

const auth = (...requiredRoles: TUserRole[]) =>
  catchAsync(async (req, res, next) => {
    const token = req.headers.authorization;
    if (!token) throw new AppError(401, 'You are not authorized!');

    // throws if the token is forged or expired
    const { email, role } = jwt.verify(token, config.jwt_access_secret) as JwtPayload;

    const user = await User.isUserExistsById(email);
    if (!user) throw new AppError(404, 'This user is not found!');
    if (user.isDeleted) throw new AppError(403, 'This user is deleted!');
    if (user.status === 'blocked') throw new AppError(403, 'This user is blocked!');

    if (requiredRoles.length && !requiredRoles.includes(role)) {
      throw new AppError(403, 'You do not have the required permissions!');
    }

    req.user = user;
    next();
  });

The token itself is created at login, after the password is checked with bcrypt. Its payload carries the user id, email and role, and it is signed with a server-side secret, so a client cannot edit its own role.

With that in place the route files read like a policy:

router.post('/tenants/create', auth(USER_ROLE.tenant), createRentalRequest);
router.patch('/requests/:requestId/status', auth(USER_ROLE.landlord), updateRentalRequestStatus);
router.get('/', auth(USER_ROLE.admin), getPayments);

Tenants create requests, landlords approve or reject them, and only admins can list every payment. Anyone reading the route file can see who may call what without opening a controller.

Layer 2: a role is not ownership

"Landlord" is a role, but a landlord should only decide on requests for their own listings. A role check cannot express that, because it knows nothing about the specific record. So the service layer checks ownership after loading the data:

const rentalHouse = await RentalHouse.findById(request.rentalHouseId);

if (!rentalHouse || rentalHouse.landlordId !== landlordId) {
  throw new AppError(403, "You don't have permission to update this request");
}

The same pattern protects the tenant side: a tenant can only pay for a request that belongs to them, and can only delete their own request while it is still pending. Two layers, two different questions: the middleware decides whether a kind of user may use an endpoint at all, and the service decides whether this user may touch this record.

A trade-off: where the role comes from

In BasaFinder's middleware the role check uses the role claim inside the signed token, while the database lookup is used for existence and for the deleted and blocked flags. The consequence is that if an admin changes someone's role, the old role keeps working until their token expires. Blocking an account takes effect immediately, but a role change does not.

In the admin API of this portfolio, a separate project, I check the role stored in the database instead. It costs nothing extra, because the middleware already loads the user on every request, and role changes apply at once. The token lifetime there is also one day.

Two lessons from getting it wrong

A middleware nobody applies protects nothing. This portfolio's API contained an auth middleware, but no route used it, so its write endpoints were open. The fix was not new code but applying auth('admin') to every write route, and testing that each one returns 401 without a token. When reviewing an API, list the routes first and check each one has a guard.
Client-side role checks are only convenience. BasaFinder's Next.js client redirects each role to its own dashboard routes, and the admin app in this portfolio once decided who was an admin from a cookie that the browser could edit. Both are fine for navigation and fatal as security. The API is the boundary, so every rule that matters has to be enforced there.

What I would add

A small automated test per protected route that asserts the status codes for no token, a wrong role and the right role would catch the "middleware not applied" mistake before it ships. The API in this post has no such tests yet.

Role-Based Authorization in an Express API