NestJS authentication guards

[EliasGit117]

I would like to know what is the way to handle role based protection for routes? For example I want to let only admin to be able to get list of users. I should just use nestjs guards to set roles with decorators and check it with auth guard? Or I only should set metadata and use auth middleware which will validate role?

[dosubot[bot]]

Hi @EliasGit117! I'm Dosu and I’m helping the orpc team.

The standard and recommended way to handle role-based route protection in NestJS is to use custom decorators (like @Roles('admin')) together with guards (such as a RolesGuard). The decorator sets metadata on the route, and the guard reads this metadata to enforce access control. This approach is idiomatic, integrates well with NestJS features, and keeps your authorization logic clean and reusable.

Example:

// roles.decorator.ts
import { SetMetadata } from '@nestjs/common';
export const Roles = (...roles: string[]) => SetMetadata('roles', roles);

// roles.guard.ts
import { CanActivate, ExecutionContext, Injectable } from '@nestjs/common';
import { Reflector } from '@nestjs/core';

@Injectable()
export class RolesGuard implements CanActivate {
  constructor(private reflector: Reflector) {}

  canActivate(context: ExecutionContext): boolean {
    const requiredRoles = this.reflector.getAllAndOverride<string[]>('roles', [
      context.getHandler(),
      context.getClass(),
    ]);
    if (!requiredRoles) return true;
    const { user } = context.switchToHttp().getRequest();
    return requiredRoles.some((role) => user?.roles?.includes(role));
  }
}

Then, in your controller:

@UseGuards(AuthGuard, RolesGuard)
@Roles('admin')
@Get('users')
findAllUsers() { ... }

This pattern is widely used and supported in the NestJS ecosystem.

You can also use middleware to set user context (e.g., from a JWT or session) before guards run, which is a common pattern in both NestJS and orpc. Middleware is great for authentication (setting req.user), while guards are best for authorization (checking roles/permissions) because they have access to route metadata and are designed for this purpose in NestJS.

If you are using orpc with NestJS, you can still use standard NestJS guards and decorators around your handlers, or you can implement RBAC in middleware by attaching user/role info to the context and checking it before the handler runs. Both approaches are valid, but using guards and decorators is the most idiomatic for NestJS projects, while middleware-based RBAC is more common in orpc-style codebases and can be more flexible for complex scenarios¹².

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

Footnotes

1. Example of decorated middleware and metadata for RBAC ↩

2. orpc middleware docs ↩

[EliasGit117]

Shouldn't user data be i context of the request?

[dosubot[bot]]

Yes, user data should be in the context of the request. This is the standard and recommended pattern in both NestJS and orpc. In NestJS, authentication middleware or guards typically attach user info to req.user, which is then accessed by guards or handlers for authorization. In orpc, middleware injects user data (like a user object or session) into the context, making it available to all downstream middleware and handlers for things like role checks or RBAC logic. This approach enables clean, reusable, and secure access control logic throughout your app [orpc middleware docs] [discussion]. If you want a code example for either framework, let me know!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}