Go 项目实战：用 MLiev IAM 落地企业认证中心

企业后台系统增加以后，账号体系很容易变成"每个系统一套"。开发阶段这样做最快，上线后却会留下三个麻烦：登录入口分散，权限回收困难，审计链路不完整。

MLiev IAM 可以作为企业认证中心的工程起点。仓库地址：

https://cnb.cool/mliev/iam/mliev-iam

1. 项目定位

MLiev IAM 是基于 Go 的身份认证与访问管理系统，采用 Controller-Service-DAO 分层架构。仓库 README 中列出的技术栈包括：

• Gin
• GORM
• MySQL/PostgreSQL/SQLite
• Redis
• Viper
• Zap
• JWT、OAuth2.0、OIDC
• Docker

这类项目的重点不是"登录表单"，而是把用户、应用、角色、权限、部门和审计放到统一模型里。

2. 快速启动

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

容器验证：

docker build -t mliev-iam .
docker run -p 8080:8080 mliev-iam

基础检查：

curl http://localhost:8080/health
curl http://localhost:8080/health/simple
curl http://localhost:8080/api/admin/system/info

3. 应用管理：从 OIDC Client 到 Application

仓库实施状态文档里有一个重要变化：管理端从 /api/admin/oidc/clients 调整到 /api/admin/applications。

这代表系统不再只把接入方看成 OIDC Client，而是抽象为 Application。当前主线仍然是 OIDC，SAML/CAS/OAuth2 属于扩展结构或后续方向。

应用接入时，核心配置包括：

• 应用名称
• 协议类型
• client_id
• client_secret
• 回调地址
• 授权类型
• Scope
• PKCE 策略

4. OIDC 端点

MLiev IAM 的公开 OIDC 端点包括：

/.well-known/openid-configuration
/api/oidc/authorize
/api/oidc/token
/api/oidc/userinfo
/api/oidc/introspect
/api/oidc/revoke
/api/oidc/jwks

典型授权码流程：

1. 业务系统把用户重定向到 /api/oidc/authorize。
2. IAM 完成登录和授权确认。
3. IAM 携带 code 回跳业务系统回调地址。
4. 业务系统请求 /api/oidc/token 换取令牌。
5. 业务系统请求 /api/oidc/userinfo 获取用户身份。
6. 业务系统根据用户身份建立自己的业务会话。

如果是内部工具接入，优先验证 Authorization Code Flow 和 PKCE。服务间调用再考虑 Client Credentials Flow。

5. RBAC 模型

RBAC 主关系：

User -> UserRole -> Role -> RolePermission -> Permission

角色可以描述职责，权限可以描述菜单、按钮、API、数据动作，用户角色关系可以承载生效范围和时效控制。

权限设计时，不建议把所有能力都塞进一个"管理员"角色。可以先拆成：

• 系统管理员：系统配置、应用管理、角色维护。
• 部门管理员：部门内成员和数据范围管理。
• 审计员：只读查看审计、登录和授权记录。
• 普通成员：只访问自己需要的业务资源。

6. 部门与数据范围

部门接口支持 CRUD、部门树、根部门、子部门、后代部门、部门移动、状态更新、批量操作和层级校验。

组织结构可以按这个方式理解：

公司 -> 事业部 -> 部门 -> 团队

结合 RBAC 后，权限不再只是"允许/拒绝"，还可以带上数据范围：

• 全部数据
• 本部门数据
• 本部门及下级数据
• 仅本人数据

这部分非常关键。很多后台越权不是认证失败，而是数据范围没有收住。

7. 审计与运维端点

认证中心上线前，建议把这些动作纳入审计：

• 登录成功与失败。
• 应用创建和配置变更。
• 回调地址变化。
• 角色授权和回收。
• 用户角色绑定和解绑。
• 部门移动和负责人变化。
• 令牌撤销。
• 配置重载。

同时保留健康检查和系统信息端点：

GET /health
GET /health/simple
GET /api/admin/system/info
POST /api/admin/system/reload

8. 落地建议

不要一上来就接所有系统。比较稳的顺序是：

1. 跑通服务和数据库迁移。
2. 接入一个低风险内部应用。
3. 跑通 OIDC 授权码流程。
4. 建立基础用户、部门和角色。
5. 把菜单、按钮、API 和数据范围逐步映射到权限资源。
6. 把授权、撤权、应用配置变更纳入审计。

这样落地，MLiev IAM 就不是一个孤立登录服务，而是企业后台系统的身份控制层。