Casbin 与 OpenFGA 对比

OpenFGA 和 Casbin 回答的都是“这个用户能否对那个对象做这件事？”但两者的构建方式截然不同。 OpenFGA 是一个仿照 Google Zanzibar 论文实现的服务器。 Casbin 是一个运行在你的应用内部的库。

总结

	Casbin	OpenFGA
形态	在你的进程内作为库运行	独立的服务器，通过 HTTP 或 gRPC 调用
核心思想	PERM 模型：请求、策略、效果、匹配器	关系元组和授权模型
访问控制方式	ACL、RBAC、带域的 RBAC、ABAC、ReBAC 等	ReBAC；角色和属性通过关系和条件表达
规则存储	通过适配器放在你自己的数据库中	OpenFGA 的数据存储（PostgreSQL、MySQL 或 SQLite）
一次检查的开销	一次函数调用	一次网络往返，加上服务器端的图解析
切换语言	Go、Java、Node.js、Python、.NET、PHP、Rust、C++ 等语言的原生实现	多种语言的 SDK，调用服务器
列出用户能访问什么	GetImplicitPermissionsForUser、BatchEnforce 等 API	ListObjects 和 ListUsers API
治理	Apache 软件基金会（孵化中）	云原生计算基金会（CNCF）

库与服务

使用 OpenFGA，你要运行和运维另一个服务：服务器、数据库、升级和监控。作为回报，公司里每个应用无论用什么语言编写，都能向同一个服务问同样的问题，关系数据也集中在一处。

使用 Casbin，不需要额外部署任何东西。加一个依赖，加载模型和策略，调用 Enforce() 即可。每次检查都在内存中运行，没有网络延迟，也不会引入新的故障点。如果以后需要一个中心化服务，可以自己把 Casbin 包装成 API，或使用 Casbin Server。

建模

OpenFGA 从关系出发。你声明类型和关系，例如“文档有所有者、编辑者和查看者，父文件夹的编辑者也是文档的编辑者”，然后写入元组，例如 user:alice 是 document:budget 的 editor。这非常适合共享功能、嵌套文件夹和组织层级。

Casbin 从你配置的模型出发。通常从 RBAC 开始：

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[role_definition]
g = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act

在此基础上，同一个引擎可以覆盖租户（带域的 RBAC）、资源层级和按资源的角色（ReBAC），以及 r.sub == r.obj.Owner 这样的属性规则（ABAC）。匹配器还可以调用 内置或自定义函数 做路径和 IP 匹配。

如果你的规则大多是“角色 X 可以对资源类型 Z 做 Y”，Casbin 的模型更短、更易读。如果你的规则大多是“通过一连串关系与这个对象相关的用户可以访问它”，OpenFGA 的模型表达得更直接。

规模

Casbin 把策略加载到内存中。这正是检查快的原因，也意味着一个应用的策略集要能放进内存。对于大型或多租户的数据集，用 加载策略子集 只加载进程需要的部分，并用 watcher 让各实例保持一致。

OpenFGA 把元组存在数据库中，每次检查都在服务器端解析。它是为很多应用共享的超大量元组设计的，代价是每次检查都要一次网络调用和服务器端求值。

如何选择

如果授权在你的组织中是一项共享的平台服务、你的规则大多是关系链，或者元组数量大到应用内存放不下，选 OpenFGA。

如果你想在应用内部做授权、不引入新的基础设施，规则基于角色、租户或属性，希望策略放在现有的数据库中，或者需要原生支持某种 OpenFGA 只能通过远程调用覆盖的语言，选 Casbin。

试用 Casbin

把上面的模型粘贴到 在线编辑器，或跟着 Go、Node.js、Python 或 Java 教程操作。

另见 对比概览。