認可とロール — RBAC のサンプルコード — NestJS

1認証と認可の違い

「誰か(認証)」と「何をしてよいか(認可)」の違いをコメントで整理した例です。認可は本人が確定して初めて成立するため、必ず認証の後に行う、という順序関係を押さえます。

// 認証(Authentication)と認可(Authorization)は別物
//
//   認証 … 「あなたは誰か」を確かめる
//          例: トークンが正しいか → user = { id: 1, role: "viewer" }
//
//   認可 … 「その人が何をしてよいか」を判定する
//          例: この削除APIは admin だけ → viewer は 403
//
// 順序が大事: 認証(誰か)が決まらないと認可(権限)は判定できない
//   ① JWT 等でユーザーを特定  → ② そのロールで許可/拒否を決める

2@Roles デコレータでロールを宣言する

ハンドラに必要なロールを宣言するカスタムデコレータ @Roles の作り方です。SetMetadata で要求ロールをメタデータとして埋め込み、後段のガードがそれを読み取る、という分業の前半部分を示します。

import { SetMetadata } from "@nestjs/common";

export type Role = "admin" | "editor" | "viewer";

// @Roles("admin") でハンドラに「必要なロール」を埋め込む
export const ROLES_KEY = "roles";
export const Roles = (...roles: Role[]) => SetMetadata(ROLES_KEY, roles);

// 使う側(宣言するだけ。判定はガードが行う)
// @Roles("admin")
// @Delete(":id")
// remove(@Param("id") id: string) { ... }

3ロール判定ロジックを再現する

ガードの核心である「要求ロールとユーザーのロールの突き合わせ」をプレーン TypeScript で再現した例です。要求ロールが無ければ全員許可、有れば1つでも持てば通過、という最も基本的な OR 判定を示します。

TypeScript

// RBAC のロール判定: ユーザーのロールが要求ロールに含まれるか
type Role = "admin" | "editor" | "viewer";
type CurrentUser = { id: string; roles: Role[] };

// ガードの本質: 要求ロールが無ければ全員許可、有れば1つでも持てば通過
function canActivate(user: CurrentUser, required: Role[]): boolean {
  if (required.length === 0) return true; // 制限なし
  return required.some((r) => user.roles.includes(r));
}

const admin: CurrentUser = { id: "u1", roles: ["admin"] };
const viewer: CurrentUser = { id: "u2", roles: ["viewer"] };

console.log("admin が削除(admin要求): " + canActivate(admin, ["admin"]));
console.log("viewer が削除(admin要求): " + canActivate(viewer, ["admin"]));
console.log("viewer が閲覧(制限なし): " + canActivate(viewer, []));

if (!canActivate(viewer, ["admin"])) {
  console.log("403 Forbidden: 権限が不足しています");
}

4ロール階層を再現する

admin > editor > viewer のように上位ロールが下位の権限も満たす「階層型」RBAC をプレーン TypeScript で再現した例です。ロールにレベルを与えて比較するだけで、上位は下位の操作を自動的に許可できます。

TypeScript

// ロール階層を持つ RBAC: 上位ロールは下位の権限も満たす
// admin > editor > viewer のように「レベル」で包含関係を表す
type Role = "admin" | "editor" | "viewer";

const rank: Record<Role, number> = { viewer: 1, editor: 2, admin: 3 };

// ユーザーのロールが要求ロール以上のレベルなら許可
function meetsRequirement(userRole: Role, required: Role): boolean {
  return rank[userRole] >= rank[required];
}

const cases: Array<[Role, Role]> = [
  ["admin", "editor"],
  ["editor", "editor"],
  ["viewer", "editor"],
];

for (const pair of cases) {
  const ok = meetsRequirement(pair[0], pair[1]);
  console.log(pair[0] + " は " + pair[1] + " 相当の操作ができる? " + ok);
}

console.log("--- editor を要求するエンドポイント ---");
console.log("viewer は拒否 → 403 Forbidden");

5RolesGuard でエンドポイントを保護する

@Roles のメタデータを Reflector で読み取り、ログインユーザーのロールと突き合わせる実務の RolesGuard です。JWT でユーザーを特定した後にこのガードを通すことで、ロール別のエンドポイント保護が完成します。

import { CanActivate, ExecutionContext, Injectable } from "@nestjs/common";
import { Reflector } from "@nestjs/core";
import { ROLES_KEY, Role } from "./roles.decorator";

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

  canActivate(context: ExecutionContext): boolean {
    // @Roles(...) で埋めた要求ロールを取り出す
    const required = this.reflector.getAllAndOverride<Role[]>(ROLES_KEY, [
      context.getHandler(),
      context.getClass(),
    ]);
    if (!required || required.length === 0) return true; // 制限なし

    // JWT 認証済みの request.user(先に認証が必要)
    const { user } = context.switchToHttp().getRequest();
    return required.some((role) => user.roles.includes(role));
  }
}
// @UseGuards(JwtAuthGuard, RolesGuard) の順で適用する

サンプルコードで身につける: 認可とロール — RBAC

1認証と認可の違い

2@Roles デコレータでロールを宣言する

3ロール判定ロジックを再現する

4ロール階層を再現する

5RolesGuard でエンドポイントを保護する