日本語
実践での RBAC: アプリケーションにおける安全な認可の実装
ロールベースアクセス制御 (RBAC) の完全ガイド: 権限設計、ロール管理、安全な認可を実践的な CMS 実装でマスターする。
Yijun
Developer
Developer
ロールベースアクセス制御 (RBAC) の完全ガイド: 権限設計、ロール管理、安全な認可を実践的な CMS 実装でマスターする。
アプリケーションに対して安全でスケーラブルな認可システムの実装に苦労していますか？ロールベースアクセス制御 (RBAC) はユーザー権限管理の業界標準ですが、正しく実装するのは困難な場合があります。このチュートリアルでは、実用的なコンテンツ管理システム (CMS) の例を使用して堅牢な RBAC システムを構築する方法を示します。
このガイドをフォローすることで学ぶこと:
このチュートリアルの完全なソースコードは GitHub にあります。
ロールベースアクセス制御はユーザーに権限を与えるだけではありません。セキュリティとメンテナンス性のバランスを取るための構造化されたアプローチの構築です。
RBAC とはについて Auth Wiki で学ぶことができます。
私たちの実装で従う主な原則は以下の通りです:
細かい権限は、システム内でユーザーが何をできるかを正確に制御することを可能にします。「管理者」や「ユーザー」といった広範なアクセスレベルではなく、ユーザーが資源に対して行うことができる具体的なアクションを定義します。例えば:
read:articles - システム内の任意の記事を閲覧create:articles - 新しい記事を作成update:articles - 既存の記事を修正publish:articles - 記事の公開ステータスを変更資源の所有は、CMS の認可設計における基本概念です。RBAC が異なるロールが実行できるアクションを定義しながら、所有はアクセス制御にパーソナルな次元を追加します:
update:articles 権限がなくても、著者は自分の記事を編集できますこの二重層のアプローチ (ロール + 所有) により、より直観的で安全なシステムが構築されます。発行者と管理者はロール権限を通じてすべてのコンテンツを管理できますが、著者は自分の作業をコントロールできます。
まず、API エンドポイントを通じて CMS の基本機能を設計しましょう:
各エンドポイントで、アクセス制御の 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 | ✅ | ✅ | ❌ |
注: 著者は自身の記事について、ロール権限にかかわらず自動的に読み取り/更新/削除権限を持ちます。
各ロールは特定の責任を念頭に置いて設計されている:
このロール構造は関心の分離を明確にします:
始める前に、Logto Cloud にアカウントを作成する必要があります。あるいは Logto OSS バージョン を使用してセルフホストの Logto インスタンスを使用することもできます。
しかし、このチュートリアルのために、シンプルさのために Logto Cloud を使用します。
list:articlesread:articlescreate:articlesupdate:articlespublish:articlesdelete:articles
Logto コンソールのロールで、次の CMS 用ロールを作成します
read:articles, list:articles, publish:articles付きcreate:articles付き
Logto コンソールの「ユーザー管理」セクションに移動してユーザーを作成します。
ユーザー詳細の「ロール」タブでユーザーにロールを割り当てることができます。
私たちの例では、次のロールを持つ 3 人のユーザーを作成します:
Logto に RBAC を設定しましたので、フロントエンドに統合し始めましょう。
まず、Logto Quick Starts をフォローして、アプリケーションに Logto を統合します。
例では React を使用してデモを行います。
アプリケーションに Logto を設定した後、Logto が機能するために RBAC 設定を追加する必要があります。
既にサインインしている場合は、サインアウトし再度サインインしてこの変更を有効にすることを忘れないでください。
ユーザーが Logto でサインインし、上記の指定された API リソースのアクセス トークンをリクエストするとき、Logto はユーザーのロールに関連するスコープ (権限) をアクセス トークンに追加します。
useLogto フックから getAccessTokenClaims を使用して、アクセス トークンからスコープを取得できます。
そして userScopes を使用して、ユーザーがリソースにアクセスする権限を持っているかどうかを確認できます。
次は、Logto RBAC をバックエンドに統合する時です。
まず、ユーザー権限をチェックし、ユーザーがログインしているかどうかを確認し、それらが特定の API にアクセスするための必要な権限を持っているかどうかを判断するためのミドルウェアをバックエンドに追加する必要があります。
ご覧の通り、このミドルウェアでは、フロントエンドリクエストが有効なアクセストークンを含んでいるかどうかを確認し、アクセストークンのオーディエンスが Logto コンソールで作成した API リソースと一致しているかどうかを確認します。
API リソースを検証する理由は、API リソースが実際に CMS バックエンドのリソースを表しており、すべての CMS 権限がこの API リソースに関連付けられているためです。
この API リソースが Logto における CMS リソースを表しているため、フロントエンドコードでは、バックエンドへの API リクエストを行う際に対応するアクセストークンを含めています:
これで requireAuth ミドルウェアを使用して API エンドポイントを保護できます。
特定の権限を持つユーザーのみがアクセスできる API には、ミドルウェアに直接制限を追加できます。たとえば、記事作成 API は create:articles 権限を持つユーザーのみがアクセスできます:
権限と資源の所有の両方を確認する必要がある API には、hasScopes 関数を使用できます。たとえば、記事リスト API では、list:articles 権限を持つユーザーはすべての記事にアクセス可能ですが、著者は自分が作成した記事のみアクセス可能です:
この時点で、RBAC の実装が完了しました。完全実装を確認するためには完全なソースコードをご覧ください。
次に、作成した 3 人のユーザーを使用して CMS RBAC 実装をテストしましょう。
まず、Alex と Charlie としてそれぞれサインインしていくつかの記事を作成してみましょう。
Alex は管理者ロールを持っているので、記事の作成、削除、更新、公開、すべての記事の表示が可能です。
Charlie は著者ロールを持っているので、自分自身の記事のみを作成でき、自分が所有する記事のみを表示、更新、および削除できます。
Bob は発行者ロールを持っており、すべての記事を表示および公開できますが、作成、更新、または削除することはできません。
おめでとうございます！アプリケーションに堅牢な RBAC システムを実装する方法を学びました。
複雑なシナリオ、たとえばマルチテナントアプリケーションを構築する場合、Logto は包括的な組織サポートを提供します。組織全体のアクセス制御の実装については、ガイド「マルチテナント SaaS アプリケーションを構築する: 設計から実装までの完全なガイド」をご覧ください。
コーディングを楽しんでください！🚀