内部系统做多以后，最容易被低估的是账号体系。
每个系统自己维护用户表，短期看开发快；长期看会变成权限治理问题：账号分散，角色重复，离职回收靠人工，出了越权问题也很难还原授权链路。
IAM 的本质不是登录页，而是身份控制层。
MLiev IAM 仓库：cnb.cool/mliev/iam/m…
这个项目适合怎么看
MLiev IAM 是一个 Go 项目，技术栈包括 Gin、GORM、Redis、Viper、Zap、JWT、OAuth2.0/OIDC 和 Docker。它的重点不是单个登录接口，而是把这些东西连起来：
- 用户身份
- 组织部门
- 业务应用
- OIDC 登录
- RBAC 权限
- 数据范围
- 审计和运维入口
这正好覆盖了企业内部认证中心的核心路径。
先跑服务
git clone https://cnb.cool/mliev/iam/mliev-iam
cd mliev-iam
cp config.yaml.example config.yaml
go mod download
go run main.go
第一轮验证看这几个端点：
GET /health
GET /health/simple
GET /api/admin/system/info
如果服务、数据库、Redis 和配置都正常，再进入应用接入。
应用接入用 OIDC 做主线
仓库当前的管理路径是：
/api/admin/applications
这比单纯的 OIDC Client 更合理，因为业务系统在 IAM 中应该被当作“应用”管理。
OIDC 公开端点：
/.well-known/openid-configuration
/api/oidc/authorize
/api/oidc/token
/api/oidc/userinfo
/api/oidc/introspect
/api/oidc/revoke
/api/oidc/jwks
接入一个后台系统时，优先跑通授权码流程：
业务系统 -> IAM authorize -> 登录/授权 -> 回调 code -> token -> userinfo -> 业务会话
这条链路跑通，业务系统就不用自己持有一整套登录逻辑。
RBAC 不要只做“管理员/普通用户”
MLiev IAM 的 RBAC 可以按这条关系理解：
User -> UserRole -> Role -> RolePermission -> Permission
实际使用时，建议把权限拆成三层。
第一层是角色。比如系统管理员、部门管理员、审计员、普通成员。
第二层是权限资源。比如菜单、按钮、API、数据动作。
第三层是数据范围。比如全部、本部门、本部门及下级、仅本人。
很多后台系统的风险，不是登录没做，而是登录以后权限过大。RBAC 真正要解决的是这个问题。
部门树负责组织边界
企业系统里，权限经常和组织关系绑定。MLiev IAM 的部门接口支持部门 CRUD、部门树、根部门、子部门、后代部门、部门移动、状态变更和层级校验。
简单说，部门树让权限有了组织上下文：
公司 -> 事业部 -> 部门 -> 团队
当角色和部门数据范围结合起来，权限就能从“这个人能不能访问”进一步细化到“这个人能访问哪个组织范围内的数据”。
审计是 IAM 的最后一环
认证中心不能只负责发令牌，还要能回答问题。
需要记录的动作包括：登录成功与失败、账号禁用、应用配置变更、回调地址调整、角色授权、用户角色绑定、部门移动、令牌撤销、配置重载。
这样出现问题时，团队能回到一条完整链路：身份、应用、权限、数据范围、动作记录。
落地顺序
我的建议是：
- 先跑通 MLiev IAM 服务。
- 接一个低风险内部应用。
- 用 OIDC 授权码流程完成统一登录。
- 建基础角色和部门树。
- 拆菜单、按钮、API 和数据权限。
- 把授权和应用配置变更纳入审计。
这比直接写一个登录页慢一点，但后续每多接一个系统，收益都会更明显。
