AuthX 正式更名 GrantForge：我们重新做了一遍权限管理系统

beta900

做开源项目有时候最难的，不是增加一个功能。

而是你做到某个阶段以后，突然意识到：

原来的架构，已经装不下你真正想做的东西了。

AuthX 就经历了这样一个阶段。

最开始，我们希望它能够解决最常见的用户、角色、菜单、按钮、API 权限问题。

但随着功能不断增加，我们开始越来越频繁地面对一些问题：

•
一个用户拥有多个角色时，最终到底拥有哪些权限？

•
为什么这个用户能访问这个接口？

•
为什么他能看到这条数据，而另一个人不能？

•
某个字段能不能只允许部分角色查看？

•
能不能让用户临时申请一个角色？

•
两个冲突角色能不能禁止同时授予？

•
权限修改以后，怎么知道它到底影响了谁？

•
外部系统是否可以复用同一套授权能力？

•
Hadoop、HDFS 这类数据基础设施，能不能也接入同一个授权体系？



这些问题已经远远超过了一个简单的后台管理系统。

所以，我们决定做一件更彻底的事情：

重新开始。

--------------------------------
AuthX 正式更名为 GrantForge

项目现在正式从 AuthX 更名为：
GrantForge

这个名字由两个词组成：

Grant + Forge

Grant 是授权。

Forge 是锻造。

我们希望它表达的是：

Forge Your Access.

权限不应该只是数据库里几张 user_role、role_permission 表。

真正成熟的权限系统，需要把身份、资源、角色、策略、数据、审计、授权决策以及外部系统连接起来。

这也是 GrantForge 接下来希望解决的问题。

因此，这次不仅仅是一次 Rename。

我们几乎把整个项目重新做了一遍。

--------------------------------
一、后端重新开始：Spring Boot 4.1

旧版本后端已经被替换。

新的 GrantForge 后端重新基于 Spring Boot 4.1 构建。

这次重构没有简单地把原来的代码搬过去，而是重新建立整个项目的工程基础。

包括：

•
Spring Boot 4.1

•
Hibernate

•
Liquibase

•
OpenAPI

•
RFC 9457 Problem Details

•
Request ID

•
TSID 主键

•
乐观锁

•
多租户数据隔离

•
国际化

•
Prometheus Metrics

•
Health Probe



数据库 Schema 也重新进行了可移植性设计。

目前针对：

•
PostgreSQL

•
MySQL

•
MariaDB

•
Oracle

•
SQL Server



进行了兼容处理。

数据库升级则统一通过 Liquibase 管理。

换句话说，我们不再把 GrantForge 当成一个“能跑起来的后台项目”。

而是开始按照一个长期维护的基础设施项目去建设它。

--------------------------------
二、前端也重新做了一遍

后端重写以后，旧 Console 同样没有继续保留。

新的管理端重新使用：

Vue 3 + Tailwind CSS

构建。

同时移除了浏览器原生控件，重新建立了一套统一的主题组件。

新的 Console 支持中英文界面，并根据当前登录用户真正拥有的权限动态展示页面和操作。

这里有一个我们非常在意的原则：

看不到，不代表没有权限；后端拒绝，才是真的没有权限。

所以 GrantForge 的权限控制并不只存在于前端。

页面、按钮和 API 都拥有自己的权限定义。

服务器启动时会自动注册 API Endpoint 与对应权限，Console 也维护自己的 Permission Manifest。

CI 会进一步检查：

API、Console 与权限清单是否一致。

这样可以减少非常常见的一类问题：

前端隐藏了按钮，但接口其实谁都能调。

--------------------------------
三、重新构建 RBAC

GrantForge 的基础仍然是 RBAC。

但是我们希望把 RBAC 做得更加完整。

现在系统已经围绕：

User → Role → Permission

建立了完整的授权体系。

角色可以授予：

•
用户

•
用户组

•
部门

•
职位



一个用户最终的 Effective Permission，则由所有角色共同计算得到。

权限覆盖：

•
页面

•
按钮

•
API



同时支持：
角色继承

角色之间可以建立继承关系。

比如：

1. 
   
2. 普通员工
   
3.    ↓
   
4. 部门管理员
   
5.    ↓
   
6. 平台管理员
   

复制代码

上层角色可以继承下层角色已经拥有的能力。

这可以明显减少大型组织中的重复授权。

--------------------------------
四、权限不再停留在「菜单和按钮」

这是这次 GrantForge 重构中，我个人非常重视的一部分。

很多所谓的 RBAC 系统做到最后，解决的其实只有：

这个按钮能不能点。

但真实业务里，最复杂的问题通常不是按钮。

而是：

点击按钮以后，他到底能看到什么数据？

所以 GrantForge 开始加入真正的数据权限体系。

--------------------------------
数据行级权限

现在角色可以配置数据策略。

应用中的实体可以声明自己受到 Data Permission 管理。

GrantForge 根据当前用户的权限条件，对数据进行过滤。

例如：

销售人员：

1. 
   
2. 只能查看自己负责的客户
   

复制代码

部门负责人：

1. 
   
2. 可以查看自己部门的数据
   

复制代码

区域管理员：

1. 
   
2. region = EAST
   

复制代码

平台管理员：

1. 
   
2. ALL
   

复制代码

最终，同一个 API：

1. 
   
2. GET /customers
   

复制代码

不同用户调用后看到的数据可以完全不同。

这也是我们希望实现的：

Row-Level Security。

--------------------------------
五、字段级权限

有些情况下，控制“哪一行能看”仍然不够。

例如员工信息：

1. 
   
2. {
   
3.   "name": "张三",
   
4.   "phone": "138",
   
5.   "salary": 30000
   
6. }
   

复制代码

普通员工也许可以看到姓名。

HR 可以看到手机号。

但是工资字段只有特定角色才能查看。

GrantForge 因此进一步加入了：

Field-Level Permission

字段策略可以决定：

•
Visible

•
Hidden

•
Masked

•
Read Only



例如：

1. 
   
2. salary → Hidden
   
3. phone  → Masked
   
4. email  → Visible
   

复制代码

而且不仅影响查询结果。

对于只读保护字段，服务器也会拒绝非法修改。

--------------------------------
六、告诉你「为什么有这个权限」

权限系统发展到一定规模以后，会出现一个非常现实的问题：

这个用户为什么有这个权限？

比如某个员工突然拥有：

1. 
   
2. customer.delete
   

复制代码

到底来自：

•
直接角色？

•
用户组？

•
部门？

•
职位？

•
角色继承？



如果只能看到最终结果，排查权限问题会非常痛苦。

所以 GrantForge 增加了：

Effective Permission Explain

除了告诉你：

1. 
   
2. ALLOW
   

复制代码

还希望能够解释：

1. 
   
2. WHY ALLOW
   

复制代码

管理员可以查看一个用户最终拥有哪些权限，以及这些权限是如何得到的。

这对于复杂组织中的权限排查非常重要。

--------------------------------
七、修改权限之前，先看看会发生什么

权限属于高风险配置。

所以有些修改不能简单地：

点保存 → 生效 → 出问题再回滚。

GrantForge 增加了权限模拟能力。

你可以在真正修改之前查看：

What If?

例如：

1. 
   
2. 如果给 Alice 增加 FinanceAdmin 角色会怎样？
   

复制代码

系统可以模拟 Alice：

新增哪些权限。

失去哪些权限。

哪些资源将受到影响。

然后管理员再决定是否真正执行。

--------------------------------
八、临时权限申请

现实中的权限并不总是永久的。

例如：

某个开发人员需要临时查看生产环境日志。

财务人员月底临时需要高级权限。

运维工程师需要临时进入某个系统排查问题。

传统系统通常只有一个办法：

1. 
   
2. 管理员手动加角色
   
3. ↓
   
4. 使用完成
   
5. ↓
   
6. 希望管理员还记得删
   

复制代码

于是 GrantForge 开始支持：

Role Request

用户可以申请角色。

审批人审核后，可以只授予一段时间。

例如：

1. 
   
2. ProductionViewer
   
3. 
   
4. 有效时间：
   
5. 
   
6. 2026-10-05 10:00
   
7.         ↓
   
8. 2026-10-05 18:00
   

复制代码

时间结束以后，权限自动失效。

--------------------------------
九、职责分离：有些角色不能同时拥有

企业权限系统中还有一个很重要的问题：

Separation of Duties

职责分离。

例如：

1. 
   
2. 付款申请人
   

复制代码

和：

1. 
   
2. 付款审批人
   

复制代码

理论上不应该是同一个人。

GrantForge 因此加入了角色冲突约束。

可以定义：

1. 
   
2. Role A
   
3.     ✕
   
4. Role B
   

复制代码

禁止同一个账号同时持有两个互斥角色。

相比单纯 RBAC，这开始更接近真实企业权限治理场景。

--------------------------------
十、加入 Access Review

权限系统运行时间越长，权限只会越来越多。

员工换部门。

岗位变化。

项目结束。

临时权限忘记回收。

最终很容易出现：

Permission Creep

权限膨胀。

所以 GrantForge 增加了周期性：

Access Review

管理员可以重新检查：

谁还拥有这些角色？

以及：

这些授权现在是否仍然合理？

这也是权限治理中非常重要的一部分。

--------------------------------
十一、登录能力开始完整起来

GrantForge 同样重新建设了身份认证体系。

除了本地账号，现在已经加入：
OpenID Connect

可以通过 OIDC Provider 登录。
LDAP

可以连接企业 LDAP Directory。
Two-Factor Authentication

支持基于 Authenticator App 的二步验证。

同时 Console Session 改成数据库 Session 管理。

管理员可以查看并结束登录 Session。

登录历史也会记录到审计系统。

--------------------------------
十二、Audit Log

任何权限平台最终都绕不开：

审计。

GrantForge 会记录权限变化，并保持 Audit Log 的追加式存储。

管理员可以搜索和导出审计日志。

这样以后遇到：

1. 
   
2. 谁改了这个权限？
   

复制代码

1. 
   
2. 什么时候改的？
   

复制代码

1. 
   
2. 之前是什么？
   

复制代码

这类问题时，不需要再去服务器翻日志。

--------------------------------
十三、GrantForge 不只是给自己用

这是整个项目非常重要的一次方向变化。

以前 AuthX 更像：

一套带权限能力的后台管理系统。

现在 GrantForge 希望逐渐变成：

可以为其他应用提供授权能力的基础设施。

所以我们开始增加应用集成能力。

--------------------------------
Spring Boot Starter

Java / Spring Boot 应用可以通过 Starter 接入 GrantForge。

应用可以询问：

1. 
   
2. 这个用户能不能执行这个操作？
   

复制代码

例如：

1. 
   
2. grantForge.can(
   
3.     user,
   
4.     "order",
   
5.     "delete"
   
6. );
   

复制代码

--------------------------------
JavaScript Client

同时提供 JavaScript Client。

Vue 应用可以通过 Directive 控制界面能力。

例如：

1. 
   
2. <button v-permission="'user.delete'">
   
3.   删除用户
   
4. </button>
   

复制代码

--------------------------------
OAuth / OpenID Connect

应用可以注册 OAuth Client。

用户可以通过 GrantForge 登录应用。

这样 GrantForge 开始同时承担：

Authentication + Authorization

两部分能力。

--------------------------------
十四、授权决策开始独立出来

除了传统 RBAC，GrantForge 还开始构建更加独立的授权决策能力。

应用可以直接询问：

1. 
   
2. Alice 能不能读取 Resource X？
   

复制代码

系统返回：

1. 
   
2. ALLOW
   

复制代码

或者：

1. 
   
2. DENY
   

复制代码

同时可以进一步解释：

为什么。

这意味着以后业务系统不一定需要自己实现复杂权限逻辑。

授权决策可以逐渐交给 GrantForge。

--------------------------------
十五、开始进入数据基础设施权限

这次更新里还有一个非常重要、但可能不是所有人第一眼都会注意到的方向：

Service Plugin + Agent

GrantForge 定义了 Service Type Plugin API。

不同的数据基础设施可以通过插件接入。

每个 Plugin 运行在自己的 ClassLoader 中。

系统负责：

•
注册服务

•
保存服务凭据

•
管理 Policy

•
下发 Policy Snapshot

•
Agent 执行授权

•
收集授权决策



--------------------------------
第一个 Service Plugin：HDFS

GrantForge 已经加入 HDFS Service Type Plugin。

同时增加了 Hadoop NameNode Agent。

Agent 可以获得签名后的 Policy Snapshot。

然后对访问请求执行授权判断。

默认策略采用：

Default Deny

也就是说：

没有明确允许，就拒绝。

这套设计和普通 Web 后台中的 RBAC 已经有明显区别。

它开始尝试解决：

数据基础设施中的统一权限治理问题。

--------------------------------
十六、插件化意味着什么？

我们不希望把所有系统的逻辑全部写死在 GrantForge Core 中。

未来不同的数据系统，都可以有自己的 Service Plugin。

例如理论上可以继续扩展：

1. 
   
2. HDFS
   
3. Hive
   
4. Kafka
   
5. Iceberg
   
6. Object Storage
   
7. Database
   
8. ……
   

复制代码

GrantForge Core 负责：

1. 
   
2. Identity
   
3. Policy
   
4. Authorization
   
5. Audit
   

复制代码

具体服务 Plugin 负责理解：

1. 
   
2. Resource
   
3. Action
   
4. Service
   

复制代码

Agent 则负责：

1. 
   
2. Enforcement
   

复制代码

这会让整个架构更容易扩展。

--------------------------------
十七、百万账户规模测试

权限系统在数据量很小的时候，几乎什么实现都能跑。

真正的问题是：

1. 
   
2. 10 个用户
   

复制代码

和：

1. 
   
2. 1,000,000 个用户
   

复制代码

完全不是同一个问题。

因此我们也开始针对：

百万账户规模

对 Authorization 和 List API 进行 Benchmark。

同时围绕权限计算做了一些优化：

•
Permission Cache

•
Prepared Catalog

•
Read-only Transaction

•
Indexed Pagination

•
PostgreSQL Trigram Search



权限缓存会一直保留，直到它依赖的数据发生变化。

目标是尽量避免每一个请求都重新计算整棵权限关系。

--------------------------------
十八、完整的工程质量体系

这次重构还有大量工作其实用户根本看不到。

但我认为它们对于一个长期维护的开源项目同样重要。

GrantForge 现在在 CI 中加入了大量自动化检查。

包括：

1. 
   
2. Checkstyle
   
3. PMD
   
4. SpotBugs
   
5. ArchUnit
   
6. JaCoCo
   
7. ShellCheck
   
8. CodeQL
   
9. Dependency Review
   
10. Secret Scan
    
11. CycloneDX SBOM
    
12. License Check
    
13. Commit Message Check
    

复制代码

同时要求：

每个 Source File 都存在对应 Unit Test File。

并对每个模块设置：

1. 
   
2. Line Coverage
   
3. Branch Coverage
   

复制代码

质量门禁。

--------------------------------
十九、多数据库测试

支持多个数据库写在 README 里很容易。

真正困难的是：

每个版本都保证它真的还能运行。

因此 GrantForge 建立了共享的 Multi-Database Test Harness。

持久层会针对不同数据库执行测试。

包括：

•
PostgreSQL

•
MySQL

•
MariaDB

•
Oracle

•
SQL Server



Liquibase Changelog 也增加了 CI 检查。

避免加入只在某一种数据库中有效的 Column Type。

--------------------------------
二十、完整的 E2E 测试

除了单元测试以外，GrantForge 也开始构建完整的 Full Stack Acceptance Test。

测试直接针对打包后的 Server 运行。

Web 端进一步覆盖：

•
View

•
Router Guard

•
Auth Store

•
Bootstrap

•
Shared Components

•
Toast

•
Formatter



这意味着测试对象不再只是某几个核心 Service。

而是在逐渐覆盖真正交付给用户的整个系统。

--------------------------------
二十一、部署方式也完整起来了

GrantForge 现在开始提供多种部署方式。

包括：

1. 
   
2. Docker
   
3. Docker Compose
   
4. Helm
   

复制代码

Release 也可以通过版本 Tag 自动发布。

Maven Artifact 同样加入 Release Pipeline。

对于 Java 开发者来说，后续可以更加方便地直接集成 GrantForge 的 SDK / Starter，而不需要从源码构建。

--------------------------------
二十二、文档站也重新做了

项目文档站重新使用：

Next.js + Tailwind CSS

构建。

README 也重新整理为英文版和中文版。

项目名称、仓库链接、Logo、Brand 等内容，都已经开始统一迁移到 GrantForge。

对我来说，这也是一个比较重要的信号：

GrantForge 不再只是 AuthX 换了一个名字。

我们正在重新定义这个项目到底是什么。

--------------------------------
为什么要做这么多？

有人可能会问：

现在已经有很多：

1. 
   
2. IAM
   
3. RBAC
   
4. SSO
   
5. OAuth
   
6. Policy Engine
   

复制代码

开源项目。

为什么还要继续做 GrantForge？

这个问题其实我自己也想过很多次。

后来我的答案变得越来越简单：

因为我自己需要这样一套东西。

在开发不同产品的时候，我反复遇到：

1. 
   
2. 用户管理再写一次
   
3. 角色管理再写一次
   
4. 菜单权限再写一次
   
5. 按钮权限再写一次
   
6. API 权限再写一次
   
7. 数据权限再写一次
   
8. OAuth 再接一次
   
9. 审计再做一次
   

复制代码

每一个项目都在重复。

而当系统越来越复杂以后，又开始需要：

1. 
   
2. LDAP
   
3. OIDC
   
4. 2FA
   
5. Field Permission
   
6. Row Permission
   
7. Access Review
   
8. Temporary Grant
   
9. Policy Explain
   
10. Audit
    

复制代码

再往数据平台走，还会遇到：

1. 
   
2. HDFS
   
3. Hive
   
4. Kafka
   
5. Database
   
6. Object Storage
   

复制代码

的授权问题。

所以我希望最终能有一个东西：

应用负责业务，GrantForge 负责权限。

这就是现在 GrantForge 想走的方向。

--------------------------------
GrantForge 还远没有完成

这次重构做了很多事情。

但是我仍然不认为 GrantForge 已经“完成”。

恰恰相反。

现在可能只是刚刚建立好了真正的地基。

接下来还有大量问题值得继续研究。

例如：

1. 
   
2. 更复杂的 Policy Model
   
3. 更完整的 ABAC
   
4. Service Plugin
   
5. Agent
   
6. Policy Distribution
   
7. Authorization Performance
   
8. Multi-Region
   
9. High Availability
   
10. 更多数据基础设施集成
    

复制代码

以及如何让这些复杂能力保持：

足够简单。

这是我认为最难的一件事情。

--------------------------------
最后

从 AuthX 到 GrantForge，对我来说并不是一次普通的版本升级。

它更像是一次重新开始。

我们把旧后端替换掉了。

把前端重新做了。

把权限模型重新梳理了。

把数据权限、字段权限、审计、权限解释、临时授权、职责分离、OIDC、LDAP、2FA、Plugin、Agent、HDFS 等能力一点一点重新搭起来。

然后重新思考：

一个真正可以长期使用的开源权限平台，到底应该是什么样子？

现在我还没有最终答案。

但至少 GrantForge 已经开始朝这个方向走了。

如果你也正在做：

•
SaaS

•
企业后台

•
数据平台

•
微服务

•
权限中心

•
IAM

•
统一认证

•
数据权限



或者你也曾经被复杂的 RBAC、数据权限和授权逻辑折磨过。

欢迎关注 GrantForge。

也欢迎参与项目，一起把它继续做下去。

GrantForge

Forge Your Access.

让应用专注业务。

把授权交给 GrantForge。

原文链接

hub_beta_72

GrantForge这个方向确实热度不减，不过坑也不少，楼主总结得很及时。

lunar443

支持一下，希望后面多写写正式更名相关的实战内容。

salmon_neo_86

签到留名，好帖子不能沉，正式更名顶上去。

misty_quantum

这篇干货浓度很高，AuthX和正式更名两个点都讲到位了。

tiger_nova_17

先马后看，正式更名的资料太散了，这篇梳理得挺清楚。

orca_zen_33

先马后看，正式更名的资料太散了，这篇梳理得挺清楚。