NestJS でアプリケーションを開発する際、認証（Authentication）と並んで重要なのが認可（Authorization）の設計です。「誰がログインしたか」を判断する認証に対して、認可は「ログインしたユーザーが特定のリソースに対して何をできるか」を制御します。

本記事では、NestJS における認可設計の主要なアプローチとして、RBAC（ロールベース）、ABAC（属性ベース）、そしてポリシーベース認可（CASL や oso）の実装方法を詳しく解説していきます。それぞれの特徴や使い分け、実装のベストプラクティスを理解することで、セキュアで拡張性の高いアプリケーションを構築できるでしょう。

背景

NestJS における認可の重要性

現代の Web アプリケーションでは、複数のユーザーロールが存在し、それぞれ異なる権限を持つことが一般的です。例えば、管理者は全てのデータにアクセスできる一方、一般ユーザーは自分のデータのみを閲覧・編集できるといった制御が必要になります。

NestJS は Guard（ガード）という仕組みを提供しており、ルートハンドラーの実行前に認可チェックを行えます。しかし、単純な Guard の実装だけでは複雑な権限管理には対応しきれません。

認可方式の進化

認可の設計手法は、シンプルなロールベースから、より柔軟な属性ベース、さらにポリシーベースへと進化してきました。それぞれのアプローチには適した用途があり、アプリケーションの要件に応じて選択する必要があります。

以下の図は、認証から認可へのフローを示しています。

mermaidCopy codeflowchart LR
  user["ユーザー"] -->|ログイン| auth["認証<br/>(Authentication)"]
  auth -->|トークン発行| token["JWTトークン"]
  token -->|リクエスト| guard["Guard"]
  guard -->|検証| authz["認可<br/>(Authorization)"]
  authz -->|許可| controller["コントローラー"]
  authz -->|拒否| forbidden["403 Forbidden"]
  controller -->|レスポンス| user

認証でユーザーを特定した後、Guard で認可チェックを行い、許可された場合のみコントローラーの処理が実行されることがわかります。

課題

シンプルな認可実装の限界

初期段階では、デコレーターと Guard を使ったシンプルなロールチェックで十分かもしれません。しかし、アプリケーションが成長するにつれて以下のような課題が発生します。

複雑な権限ルールへの対応困難

「管理者は全てのユーザーを編集できる」といったシンプルなルールは実装しやすいのですが、「ユーザーは自分が作成した記事のみを編集できる」「部門マネージャーは同じ部門のメンバーのデータを閲覧できる」といった条件付きの権限は、単純なロールベースでは表現が難しくなります。

コードの重複と保守性の低下

各エンドポイントで同じような権限チェックロジックを繰り返し書くと、コードの重複が発生します。権限ルールが変更された際、複数箇所を修正する必要があり、バグの温床となるでしょう。

テストの複雑化

権限ロジックがコントローラーやサービスに散在していると、テストケースが膨大になり、テストの保守が困難になります。

以下の図は、認可設計における主な課題を分類したものです。

mermaidCopy codeflowchart TD
  challenges["認可設計の課題"]
  challenges --> complexity["複雑性"]
  challenges --> maintenance["保守性"]
  challenges --> testability["テスタビリティ"]

  complexity --> cond["条件付き権限"]
  complexity --> dynamic["動的な権限"]

  maintenance --> duplication["コード重複"]
  maintenance --> scatter["ロジック分散"]

  testability --> cases["膨大なケース"]
  testability --> isolation["分離の困難"]

これらの課題を解決するには、適切な認可フレームワークやライブラリの選択が重要となります。

スケーラビリティの問題

ユーザー数やリソースの種類が増えると、権限の組み合わせが爆発的に増加します。すべての組み合わせをハードコーディングすることは現実的ではありません。柔軟で拡張可能な認可システムが必要です。

解決策

RBAC：ロールベースアクセス制御

RBAC は最もシンプルで理解しやすい認可方式です。ユーザーにロール（役割）を割り当て、ロールごとに権限を定義します。

RBAC の特徴

• シンプルで実装が容易
• ロールの階層化が可能
• 小〜中規模のアプリケーションに適している
• 静的な権限管理に向いている

RBAC の制限

一方で、リソースの所有者チェックなど、データに依存した動的な権限判定には不向きです。「このユーザーがこのリソースの所有者か」といった判定を行うには、追加のロジックが必要になります。

ABAC：属性ベースアクセス制御

ABAC は、ユーザーの属性、リソースの属性、環境の属性などを組み合わせて権限を判定します。RBAC よりも細かい制御が可能です。

ABAC の特徴

• 柔軟で詳細な権限制御
• 動的な条件に基づく判定
• 複雑なビジネスルールに対応
• スケーラビリティが高い

ABAC の課題

実装が複雑になりやすく、ポリシーの定義と管理に注意が必要です。また、デバッグが難しくなる可能性があります。

ポリシーベース認可：CASL と oso

ポリシーベース認可は、権限ルールを宣言的に定義し、一箇所で管理するアプローチです。NestJS では、CASL と oso という 2 つの主要なライブラリが利用できます。

CASL の特徴

• JavaScript ネイティブなライブラリ
• TypeScript との統合が優れている
• フロントエンドとバックエンドで同じルールを共有可能
• 直感的な DSL（ドメイン固有言語）

oso の特徴

• Polar という宣言的なポリシー言語を使用
• 複雑なポリシーロジックを簡潔に記述
• マルチ言語対応（Python、Ruby、Java、Node.js）
• データフィルタリング機能

以下の図は、各認可方式の適用範囲を示しています。

mermaidCopy codeflowchart TD
  start["認可方式の選択"]
  start --> simple["シンプルな<br/>権限管理?"]

  simple -->|はい| rbac["RBAC"]
  simple -->|いいえ| dynamic["動的な<br/>条件判定?"]

  dynamic -->|はい| attribute["属性ベース<br/>判定?"]
  dynamic -->|いいえ| rbac

  attribute -->|はい| abac["ABAC"]
  attribute -->|いいえ| complex["複雑な<br/>ポリシー?"]

  complex -->|はい| policy["ポリシーベース<br/>(CASL/oso)"]
  complex -->|いいえ| abac

  rbac --> result1["Guard + Decorator"]
  abac --> result2["条件付きGuard"]
  policy --> result3["CASL or oso"]

アプリケーションの要件に応じて、最適な認可方式を選択することが重要です。

具体例

RBAC 実装例

まず、NestJS でシンプルな RBAC を実装する方法を見ていきましょう。

ロール定義

最初にロールの列挙型を定義します。

typescriptCopy code// roles.enum.ts
export enum Role {
  USER = 'user',
  ADMIN = 'admin',
  MODERATOR = 'moderator',
}

この列挙型により、アプリケーション全体で一貫したロール管理が可能になります。

ロールデコレーター

次に、エンドポイントに必要なロールを指定するカスタムデコレーターを作成します。

typescriptCopy code// roles.decorator.ts
import { SetMetadata } from '@nestjs/common';
import { Role } from './roles.enum';

// メタデータキーの定義
export const ROLES_KEY = 'roles';

// ロールを設定するデコレーター
export const Roles = (...roles: Role[]) =>
  SetMetadata(ROLES_KEY, roles);

このデコレーターを使うことで、各エンドポイントに必要なロールを宣言的に指定できます。

RolesGuard 実装

Guard でロールのチェックを行います。

typescriptCopy code// roles.guard.ts
import {
  Injectable,
  CanActivate,
  ExecutionContext,
} from '@nestjs/common';
import { Reflector } from '@nestjs/core';
import { Role } from './roles.enum';
import { ROLES_KEY } from './roles.decorator';

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

  canActivate(context: ExecutionContext): boolean {
    // メタデータから必要なロールを取得
    const requiredRoles = this.reflector.getAllAndOverride<
      Role[]
    >(ROLES_KEY, [
      context.getHandler(),
      context.getClass(),
    ]);

    // ロールが指定されていない場合は許可
    if (!requiredRoles) {
      return true;
    }

    // リクエストからユーザー情報を取得
    const { user } = context.switchToHttp().getRequest();

    // ユーザーのロールが必要なロールに含まれているかチェック
    return requiredRoles.some((role) =>
      user.roles?.includes(role)
    );
  }
}

Reflector を使用してメタデータから必要なロールを取得し、ユーザーのロールと照合しています。

コントローラーでの使用

実際のエンドポイントでの使用例です。

typescriptCopy code// users.controller.ts
import {
  Controller,
  Get,
  Post,
  UseGuards,
} from '@nestjs/common';
import { RolesGuard } from './roles.guard';
import { Roles } from './roles.decorator';
import { Role } from './roles.enum';
import { JwtAuthGuard } from './jwt-auth.guard';

@Controller('users')
@UseGuards(JwtAuthGuard, RolesGuard)
export class UsersController {
  // 管理者のみアクセス可能
  @Get('admin')
  @Roles(Role.ADMIN)
  getAdminData() {
    return { message: '管理者データ' };
  }

  // 管理者またはモデレーターがアクセス可能
  @Get('moderation')
  @Roles(Role.ADMIN, Role.MODERATOR)
  getModerationData() {
    return { message: 'モデレーションデータ' };
  }

  // 全てのログインユーザーがアクセス可能
  @Get('profile')
  getProfile() {
    return { message: 'ユーザープロフィール' };
  }
}

@Rolesデコレーターで必要なロールを指定するだけで、簡潔に権限管理ができます。

ABAC 実装例

次に、属性ベースの認可を実装してみましょう。ここでは、リソースの所有者チェックを含む例を示します。

ポリシーハンドラーインターフェース

typescriptCopy code// policy-handler.interface.ts
export interface IPolicyHandler {
  handle(
    user: any,
    resource?: any
  ): boolean | Promise<boolean>;
}

// 関数型のポリシーハンドラー
export type PolicyHandlerCallback = (
  user: any,
  resource?: any
) => boolean | Promise<boolean>;

ポリシーハンドラーは、ユーザーとリソースを受け取り、アクセス可否を返します。

ポリシー Guard

typescriptCopy code// policies.guard.ts
import {
  Injectable,
  CanActivate,
  ExecutionContext,
} from '@nestjs/common';
import { Reflector } from '@nestjs/core';
import {
  IPolicyHandler,
  PolicyHandlerCallback,
} from './policy-handler.interface';

export const CHECK_POLICIES_KEY = 'check_policies';

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

  async canActivate(
    context: ExecutionContext
  ): Promise<boolean> {
    // メタデータからポリシーハンドラーを取得
    const policyHandlers =
      this.reflector.get<
        (IPolicyHandler | PolicyHandlerCallback)[]
      >(CHECK_POLICIES_KEY, context.getHandler()) || [];

    const { user, resource } = context
      .switchToHttp()
      .getRequest();

    // 全てのポリシーハンドラーを実行
    return policyHandlers.every((handler) => {
      return this.execPolicyHandler(
        handler,
        user,
        resource
      );
    });
  }

  private execPolicyHandler(
    handler: IPolicyHandler | PolicyHandlerCallback,
    user: any,
    resource?: any
  ) {
    if (typeof handler === 'function') {
      return handler(user, resource);
    }
    return handler.handle(user, resource);
  }
}

複数のポリシーハンドラーを順次実行し、全てが true を返した場合のみアクセスを許可します。

ポリシーデコレーター

typescriptCopy code// policies.decorator.ts
import { SetMetadata } from '@nestjs/common';
import {
  IPolicyHandler,
  PolicyHandlerCallback,
} from './policy-handler.interface';
import { CHECK_POLICIES_KEY } from './policies.guard';

export const CheckPolicies = (
  ...handlers: (IPolicyHandler | PolicyHandlerCallback)[]
) => SetMetadata(CHECK_POLICIES_KEY, handlers);

このデコレーターでポリシーハンドラーを指定します。

具体的なポリシー実装

リソースの所有者チェックを行うポリシーです。

typescriptCopy code// resource-owner.policy.ts
import { IPolicyHandler } from './policy-handler.interface';

export class ResourceOwnerPolicy implements IPolicyHandler {
  handle(user: any, resource: any): boolean {
    // 管理者は全てのリソースにアクセス可能
    if (user.roles?.includes('admin')) {
      return true;
    }

    // リソースが存在しない場合は拒否
    if (!resource) {
      return false;
    }

    // ユーザーがリソースの所有者かチェック
    return resource.userId === user.id;
  }
}

管理者権限または所有者であることを確認しています。

コントローラーでの使用

typescriptCopy code// articles.controller.ts
import {
  Controller,
  Get,
  Param,
  UseGuards,
  Request,
} from '@nestjs/common';
import { PoliciesGuard } from './policies.guard';
import { CheckPolicies } from './policies.decorator';
import { ResourceOwnerPolicy } from './resource-owner.policy';
import { ArticlesService } from './articles.service';

@Controller('articles')
@UseGuards(PoliciesGuard)
export class ArticlesController {
  constructor(private articlesService: ArticlesService) {}

  // 記事の所有者または管理者のみ編集可能
  @Get(':id/edit')
  @CheckPolicies(new ResourceOwnerPolicy())
  async editArticle(
    @Param('id') id: string,
    @Request() req
  ) {
    // リクエストにリソースを添付（インターセプターなどで実装）
    const article = await this.articlesService.findOne(id);
    req.resource = article;

    return { message: '記事編集ページ' };
  }
}

実際のアプリケーションでは、インターセプターを使ってリソースの取得を自動化することが推奨されます。

CASL 実装例

CASL を使用したポリシーベース認可の実装を見ていきます。

CASL のインストール

bashCopy codeyarn add @casl/ability @casl/prisma

Prisma を使用している場合は、@casl​/​prismaパッケージも追加すると便利です。

Ability 定義

アプリケーション全体の権限ルールを定義します。

typescriptCopy code// ability.factory.ts
import { Injectable } from '@nestjs/common';
import {
  Ability,
  AbilityBuilder,
  AbilityClass,
  ExtractSubjectType,
  InferSubjects,
} from '@casl/ability';

// アクションの型定義
type Actions =
  | 'create'
  | 'read'
  | 'update'
  | 'delete'
  | 'manage';

// サブジェクト（リソース）の型定義
export type Subjects =
  | InferSubjects<typeof Article | typeof User>
  | 'all';

// Abilityの型定義
export type AppAbility = Ability<[Actions, Subjects]>;

@Injectable()
export class AbilityFactory {
  createForUser(user: any) {
    // AbilityBuilderを使用してルールを構築
    const { can, cannot, build } =
      new AbilityBuilder<AppAbility>(
        Ability as AbilityClass<AppAbility>
      );

    if (user.role === 'admin') {
      // 管理者は全てのアクションが可能
      can('manage', 'all');
    } else {
      // 一般ユーザーは全ての記事を読める
      can('read', Article);

      // 自分の記事のみ更新・削除可能
      can('update', Article, { authorId: user.id });
      can('delete', Article, { authorId: user.id });

      // 記事の作成が可能
      can('create', Article);
    }

    return build({
      // サブジェクトの型を判別する関数
      detectSubjectType: (item) =>
        item.constructor as ExtractSubjectType<Subjects>,
    });
  }
}

宣言的な DSL で権限ルールを記述できるため、可読性が高くなります。

エンティティクラス定義

typescriptCopy code// entities/article.entity.ts
export class Article {
  id: number;
  title: string;
  content: string;
  authorId: number;
  published: boolean;

  constructor(partial: Partial<Article>) {
    Object.assign(this, partial);
  }
}

CASL はクラスベースのエンティティと組み合わせて使用します。

CASLGuard 実装

typescriptCopy code// casl.guard.ts
import {
  Injectable,
  CanActivate,
  ExecutionContext,
  ForbiddenException,
} from '@nestjs/common';
import { Reflector } from '@nestjs/core';
import { AbilityFactory } from './ability.factory';

// メタデータのインターフェース
interface RequiredRule {
  action: string;
  subject: any;
}

export const CHECK_ABILITY = 'check_ability';

@Injectable()
export class CaslGuard implements CanActivate {
  constructor(
    private reflector: Reflector,
    private abilityFactory: AbilityFactory
  ) {}

  async canActivate(
    context: ExecutionContext
  ): Promise<boolean> {
    // メタデータから必要な権限を取得
    const rules =
      this.reflector.get<RequiredRule[]>(
        CHECK_ABILITY,
        context.getHandler()
      ) || [];

    const { user } = context.switchToHttp().getRequest();

    // ユーザーのAbilityを作成
    const ability = this.abilityFactory.createForUser(user);

    // 全てのルールをチェック
    for (const rule of rules) {
      if (ability.cannot(rule.action, rule.subject)) {
        throw new ForbiddenException('権限がありません');
      }
    }

    return true;
  }
}

Ability を使用して権限チェックを行い、権限がない場合は 403 エラーを返します。

デコレーター

typescriptCopy code// check-ability.decorator.ts
import { SetMetadata } from '@nestjs/common';
import { CHECK_ABILITY } from './casl.guard';

export const CheckAbility = (
  action: string,
  subject: any
) => SetMetadata(CHECK_ABILITY, [{ action, subject }]);

シンプルなデコレーターで権限チェックを指定できます。

コントローラーでの使用

typescriptCopy code// articles.controller.ts
import {
  Controller,
  Get,
  Post,
  Put,
  Delete,
  Body,
  Param,
  UseGuards,
} from '@nestjs/common';
import { CaslGuard } from './casl.guard';
import { CheckAbility } from './check-ability.decorator';
import { Article } from './entities/article.entity';
import { ArticlesService } from './articles.service';

@Controller('articles')
@UseGuards(CaslGuard)
export class ArticlesController {
  constructor(private articlesService: ArticlesService) {}

  // 記事作成（ログインユーザーのみ）
  @Post()
  @CheckAbility('create', Article)
  create(@Body() createDto: any) {
    return this.articlesService.create(createDto);
  }

  // 記事更新（所有者または管理者のみ）
  @Put(':id')
  @CheckAbility('update', Article)
  async update(
    @Param('id') id: string,
    @Body() updateDto: any
  ) {
    const article = await this.articlesService.findOne(+id);
    // ここでarticleの所有者チェックがCASLによって行われる
    return this.articlesService.update(+id, updateDto);
  }

  // 記事削除（所有者または管理者のみ）
  @Delete(':id')
  @CheckAbility('delete', Article)
  async remove(@Param('id') id: string) {
    return this.articlesService.remove(+id);
  }
}

デコレーターを使って簡潔に権限を指定でき、ビジネスロジックと権限管理が分離されています。

oso 実装例

最後に、oso ライブラリを使用した実装を見ていきましょう。

oso のインストール

bashCopy codeyarn add oso

Node.js 用の oso パッケージをインストールします。

Polar ポリシーファイル

oso では、Polar 言語でポリシーを記述します。

polarCopy code# authorization.polar

# 管理者は全てのアクションが可能
allow(user: User, action, _resource) if
  user.role = "admin";

# 記事の読み取り
allow(_user: User, "read", article: Article);

# 記事の作成
allow(user: User, "create", article: Article) if
  user.id = article.authorId;

# 記事の更新（所有者のみ）
allow(user: User, "update", article: Article) if
  user.id = article.authorId;

# 記事の削除（所有者のみ）
allow(user: User, "delete", article: Article) if
  user.id = article.authorId;

# 公開済み記事のみ読み取り可能（特定条件）
allow(user: User, "read", article: Article) if
  article.published = true;

Polar 言語は宣言的で読みやすく、複雑なロジックも簡潔に表現できます。

Oso サービス

typescriptCopy code// oso.service.ts
import { Injectable } from '@nestjs/common';
import { Oso } from 'oso';
import { readFileSync } from 'fs';
import { join } from 'path';

@Injectable()
export class OsoService {
  private oso: Oso;

  constructor() {
    // Osoインスタンスを作成
    this.oso = new Oso();

    // クラスを登録
    this.oso.registerClass(User);
    this.oso.registerClass(Article);

    // Polarポリシーをロード
    const policyPath = join(
      __dirname,
      'authorization.polar'
    );
    const policyContent = readFileSync(policyPath, 'utf-8');
    this.oso.loadStr(policyContent);
  }

  // 権限チェック
  async isAllowed(
    user: any,
    action: string,
    resource: any
  ): Promise<boolean> {
    return this.oso.isAllowed(user, action, resource);
  }

  // 許可されたアクションの取得
  async allowedActions(
    user: any,
    resource: any
  ): Promise<string[]> {
    const actions = ['read', 'create', 'update', 'delete'];
    const allowed = [];

    for (const action of actions) {
      if (await this.isAllowed(user, action, resource)) {
        allowed.push(action);
      }
    }

    return allowed;
  }
}

Oso サービスを通じて、Polar ポリシーに基づいた権限チェックを行います。

OsoGuard 実装

typescriptCopy code// oso.guard.ts
import {
  Injectable,
  CanActivate,
  ExecutionContext,
  ForbiddenException,
} from '@nestjs/common';
import { Reflector } from '@nestjs/core';
import { OsoService } from './oso.service';

interface OsoCheck {
  action: string;
  resourceGetter?: (request: any) => any | Promise<any>;
}

export const OSO_CHECK = 'oso_check';

@Injectable()
export class OsoGuard implements CanActivate {
  constructor(
    private reflector: Reflector,
    private osoService: OsoService
  ) {}

  async canActivate(
    context: ExecutionContext
  ): Promise<boolean> {
    // メタデータを取得
    const check = this.reflector.get<OsoCheck>(
      OSO_CHECK,
      context.getHandler()
    );

    if (!check) {
      return true;
    }

    const request = context.switchToHttp().getRequest();
    const { user } = request;

    // リソースを取得
    let resource;
    if (check.resourceGetter) {
      resource = await check.resourceGetter(request);
    }

    // osoで権限チェック
    const allowed = await this.osoService.isAllowed(
      user,
      check.action,
      resource
    );

    if (!allowed) {
      throw new ForbiddenException(
        'このアクションを実行する権限がありません'
      );
    }

    return true;
  }
}

リフレクションでメタデータを取得し、oso サービスで権限チェックを実行しています。

デコレーター

typescriptCopy code// oso-check.decorator.ts
import { SetMetadata } from '@nestjs/common';
import { OSO_CHECK } from './oso.guard';

export const OsoCheck = (
  action: string,
  resourceGetter?: (request: any) => any
) => SetMetadata(OSO_CHECK, { action, resourceGetter });

アクションとリソース取得関数を指定できるデコレーターです。

コントローラーでの使用

typescriptCopy code// articles.controller.ts
import {
  Controller,
  Get,
  Put,
  Delete,
  Param,
  UseGuards,
} from '@nestjs/common';
import { OsoGuard } from './oso.guard';
import { OsoCheck } from './oso-check.decorator';
import { ArticlesService } from './articles.service';

@Controller('articles')
@UseGuards(OsoGuard)
export class ArticlesController {
  constructor(private articlesService: ArticlesService) {}

  // 記事更新
  @Put(':id')
  @OsoCheck('update', async (req) => {
    // リソースを動的に取得
    const article = await this.articlesService.findOne(
      req.params.id
    );
    return article;
  })
  update(@Param('id') id: string) {
    return this.articlesService.update(+id);
  }

  // 記事削除
  @Delete(':id')
  @OsoCheck('delete', async (req) => {
    const article = await this.articlesService.findOne(
      req.params.id
    );
    return article;
  })
  remove(@Param('id') id: string) {
    return this.articlesService.remove(+id);
  }
}

デコレーターでアクションとリソース取得ロジックを指定することで、コントローラーをシンプルに保てます。

各アプローチの比較表

以下の表で、各認可方式の特徴を比較します。

#	方式	実装難易度	柔軟性	パフォーマンス	適用規模
1	RBAC	★☆☆	★☆☆	★★★	小〜中規模
2	ABAC	★★☆	★★☆	★★☆	中〜大規模
3	CASL	★★☆	★★★	★★☆	中〜大規模
4	oso	★★★	★★★	★★☆	中〜大規模

星の数が多いほど、その項目の評価が高いことを示します。

使い分けの指針

以下の基準で認可方式を選択すると良いでしょう。

RBAC を選ぶ場合

• シンプルなロールベースの権限管理で十分
• 開発スピードを優先したい
• チームメンバーの学習コストを抑えたい

ABAC を選ぶ場合

• リソースの属性に基づいた動的な権限判定が必要
• 既存の Guard 機構を拡張したい
• 外部ライブラリへの依存を最小限にしたい

CASL を選ぶ場合

• TypeScript との統合を重視する
• フロントエンドとバックエンドで権限ロジックを共有したい
• 直感的な DSL でポリシーを記述したい

oso を選ぶ場合

• 非常に複雑なポリシーロジックを扱う
• 宣言的なポリシー言語で可読性を高めたい
• マイクロサービス間で統一的な認可機構を構築したい

まとめ

本記事では、NestJS における認可設計の主要なアプローチとして、RBAC、ABAC、そして CASL と oso を使用したポリシーベース認可の実装方法を解説しました。

それぞれのアプローチには長所と短所があり、アプリケーションの規模や要件に応じて適切な方式を選択することが重要です。小規模なアプリケーションではシンプルな RBAC から始め、要件が複雑化するにつれて ABAC やポリシーベースへ移行するという段階的なアプローチも有効でしょう。

重要なのは、認可ロジックをビジネスロジックから分離し、一箇所で管理することです。これにより、保守性、テスタビリティ、セキュリティが向上します。

また、認可設計は一度実装したら終わりではなく、アプリケーションの成長とともに継続的に見直しと改善が必要です。定期的なセキュリティレビューを行い、適切な権限管理が維持されているか確認しましょう。

本記事で紹介した実装パターンを参考に、セキュアで拡張性の高い NestJS アプリケーションを構築していただければ幸いです。

関連リンク

• NestJS 公式ドキュメント - Authorization
• CASL 公式サイト
• oso 公式サイト
• NestJS Guards
• RBAC vs ABAC: 権限管理の選択肢
• TypeScript Decorators