Auth0 FGA で ReBAC（Relationship-Based Access Control）を試してみた

はじめに

ITシステムにおいて、認証（Authentication）と認可（Authorization）はあらゆるところに組み込まれています。

認可のアプローチとしては RBAC（Role-Based Access Control）や ABAC（Attribute-Based Access Control）が一般的ですが、より複雑なアクセス制御が必要になると、ReBAC（Relationship-Based Access Control）の出番です。

有名なユースケースは Google Drive。ユーザー・グループ・フォルダー・ファイルの関係性に基づいたきめ細かいアクセス制御が実現されています。

Auth0 FGA（Fine-Grained Authorization）を使えば、こういったリレーションベースの認可システムを構築できます。今回は実際に Auth0 FGA を触って、ReBAC の基本的な動きを確認してみます。

今回やること

シンプルなケースで ReBAC の仕組みを理解するために、以下の3つを確認します。

• あるユーザー（user）がグループのメンバー（group#member）であること
• そのグループに所属するメンバー（group#member）は、特定のドキュメント（doc）を読めること
• グループに所属していないユーザー（user）は、そのドキュメント（doc）を読めないこと

Auth0 FGA のアカウント登録

まずは Auth0 FGA のアカウントを作成します。無料で試せるので、以下の URL からサインアップしてみてください。

https://dashboard.fga.dev/

Auth0 FGA は通常の Auth0 テナントとは別のプロダクトです。独立したアカウント登録が必要になるので注意してください。

Auth0 FGA のダッシュボードについて

Auth0 FGA のダッシュボードでは、主に以下の3つのステップで認可の設定・検証を行います。

1. Model Explorer: 認可モデルの定義（type とリレーションの構造を設計する）
2. Tuple Management: 関係データの作成（実際の「誰が何に対してどんな関係か」を登録する）
3. Developer Mode: 認可のテスト（Assertion で権限判定が正しいか検証する）

今回もこの流れに沿って進めていきます。

デフォルトのモデルを確認する

アカウント作成後、ダッシュボードの Model Explorer を開くと、デフォルトの認可モデルが用意されています。右側にはリレーションのグラフがプレビューされていて、type 同士の関係が視覚的にわかるようになっています。

model
  schema 1.1

type user

type group
  relations
    define member: [user]

type folder
  relations
    define can_create_file: owner
    define owner: [user]
    define parent: [folder]
    define viewer: [user, user:*, group#member] or owner or viewer from parent

type doc
  relations
    define can_change_owner: owner
    define owner: [user]
    define parent: [folder]
    define can_read: viewer or owner or viewer from parent
    define can_share: owner or owner from parent
    define viewer: [user, user:*, group#member]
    define can_write: owner or owner from parent

このモデルには4つの type が定義されています。それぞれ解説していきます。

user

操作を行う主体です。リレーションは定義されていません。

group

グループです。member リレーションを持ち、user をメンバーとして追加できます。

folder

フォルダーです。以下のリレーションを持ちます。

• owner: フォルダーのオーナー（user を指定可能）
• parent: 親フォルダー（folder を指定可能）。フォルダーの入れ子構造を表現できます
• can_create_file: ファイル作成権限。owner のみ
• viewer: フォルダーを閲覧できるユーザー。以下のいずれかに該当すれば viewer です
  • 直接 viewer として指定された user
  • user:*（全ユーザー＝パブリックアクセス）
  • group#member（特定グループのメンバー）
  • owner（フォルダーのオーナー）
  • viewer from parent（親フォルダーの viewer。権限が階層的に継承される）

doc

ドキュメントです。以下のリレーションを持ちます。

• owner: ドキュメントのオーナー
• parent: 所属するフォルダー
• viewer: 直接指定されたユーザー、全ユーザー（user:*）、またはグループメンバー
• can_read: viewer or owner or viewer from parent（親フォルダーの viewer から継承）
• can_write: owner or owner from parent
• can_share: owner or owner from parent
• can_change_owner: owner のみ。親フォルダーからの継承はありません。オーナー変更は慎重を要する操作なので、直接の owner だけに限定されています

このモデルのポイント

この認可モデルのポイントは主に3つです。

1. 階層的な権限継承（viewer from parent）: 親フォルダーの権限が子フォルダーやドキュメントに引き継がれます。Google Drive のフォルダー共有と同じ考え方です
2. グループベースのアクセス（group#member）: 個別ユーザーではなく、グループ単位でアクセス権を付与できます。チームやロールでの権限管理に便利です
3. 派生権限: can_read のような権限は直接付与するのではなく、viewer や owner などの他のリレーションから自動的に計算されます

今回はこのモデルの中から、最小限の関係性に絞って試してみます。具体的には グループのメンバーがドキュメントを読める というシンプルな関係だけを作って、ReBAC の動きを確認していきます。

Relationship Tuple を作成する

モデルを確認したら、次は実際のデータ（Relationship Tuple）を作成します。

Tuple は 誰が、何に対して、どんな関係を持つか を定義するもので、認可判定の元データになります。サイドバーの Tuple Management ページから追加していきます。

Tuple 1: game_center のメンバーは ff7_game_guide_book の viewer

まず、game_center グループのメンバーが ff7_game_guide_book というドキュメントを閲覧できるようにします。

User に group:game_center#member を指定しています。これは「game_center グループの member リレーションを持つすべてのユーザー」を意味する userset の表記です。

Auth0 FGA では type:id#relation の形式で userset を参照します。ここで : ではなく # を使うのがポイントです（: は type と id の区切り文字として予約されているため、3つ目の : を使うとエラーになります）。

Tuple 2: alice は game_center のメンバー

次に、ユーザー alice を game_center グループのメンバーとして登録します。

2つの Tuple を作成すると、以下のようになります。

これで、alice → game_center の member → ff7_game_guide_book の viewer、というリレーションチェーンが完成しました。

Developer Mode でテストする

作成した Tuple に基づいて、認可が正しく動くかテストしてみましょう。

サイドバーの Developer Mode を開くと、Model・Tuple・Assertion を一画面で確認・操作できます。

Assertion はテストケースのようなもので、「このユーザーはこのリソースに対してこの操作ができるか？」を検証できます。

テスト 1: alice は ff7_game_guide_book を読めるか

alice は game_center のメンバーなので、can_read の結果は TRUE になるはずです。

テスト 2: bob は ff7_game_guide_book を読めるか

bob はどのグループにも所属していないので、can_read の結果は FALSE のはずです。
ここではあえて Expectation を TRUE にして、Assertion が FAIL することで bob にアクセス権がないことを確認します。

テスト結果

結果は想定通りです。

• alice の Assertion → PASS（alice は game_center のメンバーなので ff7_game_guide_book を読める）
• bob の Assertion → FAIL（bob は game_center のメンバーではないので ff7_game_guide_book を読めない。Expectation を TRUE にしたので Assertion としては FAIL）

Auth0 FGA の ReBAC モデルが、グループメンバーシップに基づいたアクセス制御を正しく行えていることが確認できました。

おわりに

以上、Auth0 FGA を使った ReBAC の基本的な使い方の紹介でした。

今回はシンプルなグループメンバーシップとドキュメントの閲覧権限だけを試しましたが、Auth0 FGA のモデルにはフォルダー階層の継承やオーナー権限の管理など、もっと高度なアクセス制御を構築できる仕組みが備わっています。

きめ細かい認可システムに興味がある方は、ぜひ一度触ってみてください。