より堅牢な認可モデルについては、「Fine-Grained Authorization（FGA）」に記載されている属性ベースと関係ベースの認可を参照してください。
RBACの利点
ロールの要件さえ厳密に守っていれば、RBACによってアクセス管理の作業がより簡単になります。RBACを使用すると：- 反復して適用できる体系的な権限の割り当てを作成できる
- ユーザーの権限を手軽に監査し、特定した問題を解決できる
- ロールを素早く追加・変更して、各種のAPIに実装できる
- ユーザー権限を割り当てる際の潜在的なエラーが低減する
- 予め定義したロールを使ってサードパーティのユーザーを統合できる
- 守秘義務やプライバシーに関する規制や法的要件がより効果的に順守される
RBACのモデル
ロール
ロールとは、本質的に、ユーザーに適用できる権限の集まりです。ロールを利用することで、権限をユーザーに個別に割り当てる場合よりも、権限の追加・削除・調整を素早く処理できます。ユーザーベースの規模と複雑性が増すにつれて、ロールは特に便利になります。 さまざまなAPIに定義された許可を集めるのに、ロールを使用することもできます。たとえば、ユーザーが顧客にニュースレターを作成して配信できるマーケティングモジュールがあるとします。マーケティングコンテンツの専門企業がすべてのニュースレターを作成して、配信の準備をします。同様に、ユーザーがイベント登録を作成、公開して管理できるイベントモジュールがあるとします。イベントを制作するのは、イベントコーディネーターです。マーケティング部のVPがニュースレターとイベントを承認すると、VPのアシスタントがイベントについて公表してニュースレターを配信します。この事例では、ニュースレターAPIにdistribute:newsletters 権限を、イベントAPIにpublish:events権限を付与できます。そして、これらの権限を併せ持つ「Marketing Publisher」という名前のロールを作成し、このロールをマーケティング部VPのアシスタントに割り当てます。
さらに、組織固有のさまざまなロールを組織メンバーに追加して、エンドユーザーがログインに使用する組織を基に、それらのロールをアプリケーションでのアクセス許可に使用します。これは、あるユーザーが1つの組織では権限があるのに、他の組織では権限がないことがあるような、複数テナントのSaaSモデルでは特に便利です。
重複するロールの割り当て
RBACは加法モデルであるため、ロールの割り当てが重複した場合、有効な権限は、ロールの割り当ての和集合になります。 たとえば、イベントアプリケーションにデータを提供するAPIがあるとします。「Organizer」というロールを作成して、イベントの表示、作成、編集の権限を割り当てます。また「Registrant」というロールを作成して、イベントの表示と登録の権限を割り当てます。「Organizer」と「Registrant」の両方のロールがあるユーザーには、イベントの表示、作成、編集、そして登録の権限があることになります。
Auth0でのRole-based Access Control（RBAC）
現在、Role-based Access Control（RBAC）の実装に2つの方法を提供しており、API独自の内部アクセス制御システムの代わりに、または、それとの組み合わせで、これらの方法を使用することができます。 Authorization Extension（認可拡張機能）の機能性と同等になるように、Authorization Core（認可コア）の機能セットの拡張を進めているところです。新しいコアのRBAC実装は、性能と拡張性を向上しながら、究極的にはAuthorization Extension（認可拡張機能）よりも柔軟なRBACシステムを提供する計画です。 現時点では、どちらもRBACの主要な機能を実装し、APIに定義したカスタムのスコープを、権限としてユーザーに割り当てたスコープに制約できるようにします。比較については、「認可コアと認可拡張機能」をお読みください。Authorization Core（認可コア）の機能セットとAuthorization Extension（認可拡張機能）は完全に別途の機能です。グループ、ロール、権限を管理するには、それらの作成に使用した方の機能を使う必要があります。
Delegated Administration Extension（DAE：委任管理拡張機能）とAuthorization Core（認可コア）は全く別の機能ですが、Authorization Core（認可コア）機能セットを使用すると、ActionsでDAEのロールを作成し、管理することができます。方法については、「サンプルユースケース：認可のあるアクション」を参照してください。