多个业务系统，如何共用登录与权限：JetAuth 实践
以基于 Casdoor 的 JetAuth 二次开发为例，区分统一登录与业务授权，记录接入企业系统时需要考虑的边界。
开源二次开发 · 基于 Casdoor
账号统一，只是第一步
企业增加业务系统后，员工经常需要多套账号。将登录集中起来，可以减少重复管理，但仍需要回答谁能访问哪个应用、谁能操作某条业务记录。
JetAuth 是基于 Casdoor 的统一认证与授权二次开发项目。仓库明确记录了上游来源，也提供了与上游的改动说明。这里分享的是公开开发实践，不是特定客户的上线案例。
分清认证与业务授权
认证确认用户身份；授权决定身份可以执行的业务动作。不同应用还需要一致的组织与角色信息，以及可以核验的操作记录。
- 确认身份
- 映射组织与角色
- 判断资源权限
- 记录业务操作
- 先梳理组织、人员与应用，明确账号的来源和离职停用流程。
- 按应用条件选择登录协议与接入方式，而不是让每套系统自行保存一套密码。
- 业务权限需要在服务端校验，前端隐藏按钮不能替代权限判断。
- 跨组织数据、角色继承和资源权限应单独设计并验证。
JetAuth 的二次开发方向
公开文档记录了基于 React、Vite 与 Tailwind CSS 的新管理前端，以及围绕应用授权进行的功能扩展。近期提交覆盖权限模块的改进与测试。
改动说明还记录了独立应用权限表、角色继承、跨租户写入校验，以及邮件发送模块的重构。这些工作反映的是系统集成、管理界面和业务权限实现能力；具体协议与功能的采用仍需要按接入系统验证。
落地前先做接入清单
统一认证项目应先确认应用是否支持标准协议、旧账号怎样迁移、哪些业务权限由中心管理、哪些规则留在业务系统。
实施交付可以包括账号与应用梳理、试点系统接入、权限模型、管理界面、联调测试及交接文档。验收应覆盖登录、退出、停用、权限变化和跨组织访问等关键路径。