この記事は「ビギナーズ Advent Calendar 2025」の25日目の記事です。
はじめに
システム開発において「誰が」「何を」「どこまで操作できるか」を制御する「認可(Authorization)」は、欠かせない要素です。ユーザーごとの権限や共有範囲が複雑になると、従来の仕組みでは表現しきれない場面も出てきます。
たとえば、
- 同じグループのメンバーは編集可能、それ以外は閲覧のみ
- あるユーザーが作成したデータを、同じ組織のメンバーにだけ共有したい
といったケースは、ロールや属性だけでは捉えにくくなってきます。
今回、携わっている案件で認可技術を学ぶ機会があり、OpenFGA（Open Fine-Grained Authorization）という最新の認可基盤について学びました。OpenFGAでは従来のRBAC（Role-Based Access Control）やABAC（Attribute-Based Access Control）では扱いづらかった「人とリソースの関係性」に基づくReBAC（Relationship-Based Access Control）という考え方を、手軽に実装できます。
この記事では、認可初心者の自分がOpenFGAを学んだ内容を整理しています。
認可ってそもそも何？
まず、良く混同される「認証」と「認可」について整理します。
| 用語 | 意味 | 例 |
|---|---|---|
| 認証（Authentication） | あなたは誰？を確認 | ログイン（ID・パスワード） |
| 認可（Authorization） | あなたは何ができる？を決定 | 管理者のみ削除可能、など |
認可は、ユーザーが「どの操作をできるか」を判断する仕組みです。
3種類の認可モデル
認可モデルには主に以下の3つがあります。
RBAC（Role-Based Access Control）
ロール（役割）単位で権限を管理する方式。
シンプルだが、ユーザー間の共有ルールや複雑な条件が増えると破綻しやすい。
ABAC（Attribute-Based Access Control）
ユーザーやリソースの属性で柔軟に制御できる。
ただし、ポリシーが肥大化し、管理が難しくなることがある。
ReBAC（Relationship-Based Access Control）
ユーザーとリソースの「関係性」に着目したモデル。
「この会社に所属しているなら閲覧可能」「この組織のメンバーであれば編集可能」といったルールを自然に扱えるのが特徴です。
OpenFGAについて
OpenFGA（Open Fine-Grained Authorization）はReBACを簡単に扱えるオープンソースの認可基盤です。
特徴は以下の3ステップに集約されます。
- モデル定義（どんなリソースと関係があるかを定義）
- Tuple登録（ユーザーとリソースの関係性を登録）
- 認可判断（ユーザーが操作できるかの確認）
APIで操作でき、マイクロサービス環境にも導入しやすい点が魅力です。
OpenFGAでAPI単位の認可制御を設計してみる
今回は、会社・組織といった階層構造を持つシステムで、API単位の細かなアクセス制御を実現することを想定して認可モデルを組みました。
モデル定義
OpenFGAでは「誰が（user）」「どのリソース（company:X, organization:Yなど）」「どんな関係（member, viewer, ...）」をモデルとして定義します。
例：
type user
type company
relations
define member: [user]
define viewer: member
type organization
relations
define member: [user]
define parent_company: [company]
define viewer: member or parent_company->viewer
type api
relations
define resource_organization: [organization]
define resource_campany: [company]
define can_access: resource_organization->viewr or resource_campany->viewer
Tuple登録（関係性の登録）
Tupleとは「ユーザーとリソースの関係を表すデータ」のことで、認可判断のベースとなる情報です。
例として以下のような関係性を設定します。
| ユーザ | api:get/company01_info | api:get/orgA_info |
|---|---|---|
| user:alice | 利用可能 | 利用可能 |
| user:bob | 利用不可 | 利用可能 |
実際のTupleは以下のように定義します。
user:alice is member of company:company01
user:bob is member of organization:orgA
company:company01 is parent_company of organization:orgA
organization:orgA is resource_organization of api:get/orgA_info
company:company01 is resource_company of api:get/company01_info
認可判断（Java/Spring例）
リクエストユーザーが対象APIを呼んだ際に、関係性として"can_access"を持っているかどうかで認可判断を行います。
// 例: /get/conpany01_info にアクセスする場合
boolean allowed = fgaClient.check(
"user:alice", "can_access", "api:get/conpany01_info"
);
if (!allowed) {
throw new ForbiddenException();
}
運用時に気をつけたいこと
実際に触ってみて感じたポイントを3つ挙げておきます。
- モデルやTupleが複雑になりすぎないよう、階層や継承（parent_companyなど）を活用すると管理しやすくなる
- API単位だけでなく、リソース単位で抽象化するなど粒度調整が大事
最後に重要な注意点を挙げると、
OpenFGAのストアにモデル登録する際にPOST /stores/{store_id}/authorization-modelsの形でAPIを呼ぶのですが、存在しないstore_idを指定しても、エラーにならずモデルが登録されてしまうので、注意が必要です。この問題はIssueでも報告されています。
さいごに
認可はシステムを安全に運用するための重要な要素です。
OpenFGAとReBACは、関係性という自然な概念で複雑な権限管理を整理できる強力なアプローチでした。
試してみたい方は、OpenFGAの認可モデル設計をブラウザ上で体験できるPlaygroundをオススメします！ReBACの認可設計について直感的に理解することができます。
NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。