日本語

rbac
ロール設計
rbac実装

実践での RBAC: アプリケーションにおける安全な認可の実装

ロールベースアクセス制御 (RBAC) の完全ガイド: 権限設計、ロール管理、安全な認可を実践的な CMS 実装でマスターする。

Yijun

Developer

2/17/2025

ユーザー認証に何週間も費やすのはもうやめましょう

Logto でより速く安全なアプリをリリース。数分で認証を統合し、コア製品に集中できます。

始めましょう

アプリケーションに対して安全でスケーラブルな認可システムの実装に苦労していますか？ロールベースアクセス制御 (RBAC) はユーザー権限管理の業界標準ですが、正しく実装するのは困難な場合があります。このチュートリアルでは、実用的なコンテンツ管理システム (CMS) の例を使用して堅牢な RBAC システムを構築する方法を示します。

このガイドをフォローすることで学ぶこと:

✨ 細かく制御可能な権限設計と実装方法
🔒 意味のあるロールに権限を整理するベストプラクティス
👤 資源所有を効果的に処理する手法
🚀 認可システムをスケーラブルかつメンテナンス可能にする方法
💡 実用的な CMS 例による実装

このチュートリアルの完全なソースコードは GitHub にあります。

RBAC の基本を理解する

ロールベースアクセス制御はユーザーに権限を与えるだけではありません。セキュリティとメンテナンス性のバランスを取るための構造化されたアプローチの構築です。

RBAC とはについて Auth Wiki で学ぶことができます。

私たちの実装で従う主な原則は以下の通りです:

細かい権限設計

細かい権限は、システム内でユーザーが何をできるかを正確に制御することを可能にします。「管理者」や「ユーザー」といった広範なアクセスレベルではなく、ユーザーが資源に対して行うことができる具体的なアクションを定義します。例えば:

read:articles - システム内の任意の記事を閲覧
create:articles - 新しい記事を作成
update:articles - 既存の記事を修正
publish:articles - 記事の公開ステータスを変更

資源の所有とアクセス制御

資源の所有は、CMS の認可設計における基本概念です。RBAC が異なるロールが実行できるアクションを定義しながら、所有はアクセス制御にパーソナルな次元を追加します:

著者は作成した記事に自動的にアクセスできます
この自然な所有モデルにより、著者は常に自分のコンテンツを表示して編集できます
記事操作を処理する際、システムはロール権限または所有を確認します
例えば、update:articles 権限がなくても、著者は自分の記事を編集できます
この設計は、追加のロール権限の必要性を減らしながら、セキュリティを維持します

この二重層のアプローチ (ロール + 所有) により、より直観的で安全なシステムが構築されます。発行者と管理者はロール権限を通じてすべてのコンテンツを管理できますが、著者は自分の作業をコントロールできます。

安全な API の設計

まず、API エンドポイントを通じて CMS の基本機能を設計しましょう:

API のアクセス制御の実装

各エンドポイントで、アクセス制御の 2 つの側面を考慮する必要があります:

資源の所有 - ユーザーはこの資源を所有しているか？
ロールベースの権限 - ユーザーのロールはこの操作を許可しているか？

各エンドポイントのアクセス処理方法は次の通りです:

エンドポイント	アクセス制御ロジック
GET /api/articles	- `list:articles` 権限を持つ者、または著者が自分の記事を閲覧可能
GET /api/articles/:id	- `read:articles` 権限を持つ者、または記事の著者
POST /api/articles	- `create:articles` 権限を持つ者
PATCH /api/articles/:id	- `update:articles` 権限を持つ者、または記事の著者
DELETE /api/articles/:id	- `delete:articles` 権限を持つ者、または記事の著者
PATCH /api/articles/:id/published	- `publish:articles` 権限を持つユーザーのみ

スケールする権限システムの構築

API アクセス要件に基づいて、これらの権限を定義できます:

権限	説明
list:articles	システム内のすべての記事のリストを表示
read:articles	任意の記事のフルコンテンツを読む
create:articles	新しい記事を作成
update:articles	任意の記事を修正
delete:articles	任意の記事を削除
publish:articles	公開ステータスを変更

これらの権限は、自分が所有していないリソースにアクセスする場合にのみ必要です。記事の所有者は自動的に:

自分の記事を表示 ( read:articles 必要なし)
自分の記事を編集 ( update:articles 必要なし)
自分の記事を削除 ( delete:articles 必要なし)

効果的なロールの構築

API と権限が定義されたので、それらの権限を論理的にグループ化するロールを作成できます:

権限/ロール	👑 管理者	📝 発行者	✍️ 著者
説明	コンテンツ管理のためのフルシステムアクセス	すべての記事を閲覧し、公開ステータスを制御可能	システム内で新しい記事を作成可能
list:articles	✅	✅	❌
read:articles	✅	✅	❌
create:articles	✅	❌	✅
update:articles	✅	❌	❌
delete:articles	✅	❌	❌
publish:articles	✅	✅	❌

注: 著者は自身の記事について、ロール権限にかかわらず自動的に読み取り/更新/削除権限を持ちます。

各ロールは特定の責任を念頭に置いて設計されている:

管理者: CMS 全体、特にすべての記事操作を完全にコントロールします
発行者: コンテンツレビューと公開管理に集中します
著者: コンテンツ作成に特化しています

このロール構造は関心の分離を明確にします:

著者はコンテンツ作成に集中します
発行者はコンテンツの質と可視性を管理します
管理者は全体のシステムコントロールを維持します

Logto での RBAC 設定

始める前に、Logto Cloud にアカウントを作成する必要があります。あるいは Logto OSS バージョンを使用してセルフホストの Logto インスタンスを使用することもできます。

しかし、このチュートリアルのために、シンプルさのために Logto Cloud を使用します。

アプリケーションの設定

Logto コンソールの「アプリケーション」で新しいリアクトアプリケーションを作成します
- アプリケーション名: コンテンツ管理システム
- アプリケーションタイプ: 伝統的なウェブアプリケーション
- リダイレクト URI: http://localhost:5173/callback

CMS React application

API リソースと権限の設定

Logto コンソールの「API リソース」で新しい API リソースを作成します
- API 名: CMS API
- API 識別子: https://api.cms.com
- API リソースに権限を追加
  - list:articles
  - read:articles
  - create:articles
  - update:articles
  - publish:articles
  - delete:articles

CMS API resource details

ロールの作成

Logto コンソールのロールで、次の CMS 用ロールを作成します

管理者
- すべての権限付き
発行者
- read:articles, list:articles, publish:articles付き
著者
- create:articles付き

Admin role

Publisher role

Author role

ユーザーへのロールの割り当て

Logto コンソールの「ユーザー管理」セクションに移動してユーザーを作成します。

ユーザー詳細の「ロール」タブでユーザーにロールを割り当てることができます。

私たちの例では、次のロールを持つ 3 人のユーザーを作成します:

Alex: 管理者
Bob: 発行者
Charlie: 著者

User management

User details - Alex

フロントエンドへの Logto RBAC の統合

Logto に RBAC を設定しましたので、フロントエンドに統合し始めましょう。

まず、Logto Quick Starts をフォローして、アプリケーションに Logto を統合します。

例では React を使用してデモを行います。

アプリケーションに Logto を設定した後、Logto が機能するために RBAC 設定を追加する必要があります。

既にサインインしている場合は、サインアウトし再度サインインしてこの変更を有効にすることを忘れないでください。

ユーザーが Logto でサインインし、上記の指定された API リソースのアクセストークンをリクエストするとき、Logto はユーザーのロールに関連するスコープ (権限) をアクセストークンに追加します。

useLogto フックから getAccessTokenClaims を使用して、アクセストークンからスコープを取得できます。

そして userScopes を使用して、ユーザーがリソースにアクセスする権限を持っているかどうかを確認できます。

バックエンドへの Logto RBAC の統合

次は、Logto RBAC をバックエンドに統合する時です。

バックエンド認可ミドルウェア

まず、ユーザー権限をチェックし、ユーザーがログインしているかどうかを確認し、それらが特定の API にアクセスするための必要な権限を持っているかどうかを判断するためのミドルウェアをバックエンドに追加する必要があります。

ご覧の通り、このミドルウェアでは、フロントエンドリクエストが有効なアクセストークンを含んでいるかどうかを確認し、アクセストークンのオーディエンスが Logto コンソールで作成した API リソースと一致しているかどうかを確認します。

API リソースを検証する理由は、API リソースが実際に CMS バックエンドのリソースを表しており、すべての CMS 権限がこの API リソースに関連付けられているためです。

この API リソースが Logto における CMS リソースを表しているため、フロントエンドコードでは、バックエンドへの API リクエストを行う際に対応するアクセストークンを含めています:

これで requireAuth ミドルウェアを使用して API エンドポイントを保護できます。

API エンドポイントの保護

特定の権限を持つユーザーのみがアクセスできる API には、ミドルウェアに直接制限を追加できます。たとえば、記事作成 API は create:articles 権限を持つユーザーのみがアクセスできます:

権限と資源の所有の両方を確認する必要がある API には、hasScopes 関数を使用できます。たとえば、記事リスト API では、list:articles 権限を持つユーザーはすべての記事にアクセス可能ですが、著者は自分が作成した記事のみアクセス可能です:

この時点で、RBAC の実装が完了しました。完全実装を確認するためには完全なソースコードをご覧ください。

CMS RBAC 実装のテスト

次に、作成した 3 人のユーザーを使用して CMS RBAC 実装をテストしましょう。

まず、Alex と Charlie としてそれぞれサインインしていくつかの記事を作成してみましょう。

Alex は管理者ロールを持っているので、記事の作成、削除、更新、公開、すべての記事の表示が可能です。

CMS dashboard - Alex

Charlie は著者ロールを持っているので、自分自身の記事のみを作成でき、自分が所有する記事のみを表示、更新、および削除できます。

CMS dashboard - Charles - Article list

Bob は発行者ロールを持っており、すべての記事を表示および公開できますが、作成、更新、または削除することはできません。

CMS dashboard - Bob

結論

おめでとうございます！アプリケーションに堅牢な RBAC システムを実装する方法を学びました。

複雑なシナリオ、たとえばマルチテナントアプリケーションを構築する場合、Logto は包括的な組織サポートを提供します。組織全体のアクセス制御の実装については、ガイド「マルチテナント SaaS アプリケーションを構築する: 設計から実装までの完全なガイド」をご覧ください。

コーディングを楽しんでください！🚀

RBAC の基本を理解する#

細かい権限設計#

資源の所有とアクセス制御#

安全な API の設計#

API のアクセス制御の実装#

スケールする権限システムの構築#

効果的なロールの構築#

Logto での RBAC 設定#

アプリケーションの設定#

API リソースと権限の設定#

ロールの作成#

ユーザーへのロールの割り当て#

フロントエンドへの Logto RBAC の統合#

バックエンドへの Logto RBAC の統合#

バックエンド認可ミドルウェア#

API エンドポイントの保護#

CMS RBAC 実装のテスト#

結論#