一个 Go 后台如果已经有用户表、角色、菜单和按钮权限，后面又要接公司 SSO 、CAS 、LDAP 或企业微信，本地用户表到底该不该继续存在？我现在的判断是：应该存在，但要退成“映射层”，别再把自己当身份主系统。
我说的不是登录页上多一个按钮。认证入口可以交给外部系统，外部系统负责判断这个人是谁、能不能进公司系统、属于哪个组织。后台本地更适合保留角色、菜单、按钮、接口权限、数据范围和操作日志。原因很土：公司的 SSO 通常不理解某个后台里的“导出订单”“批量删除”“重置密码”这些业务动作。硬塞回统一权限中心，后面很容易变成谁都不敢改的黑盒。
比较稳的切法是中间留一张映射：provider 、external_subject 、local_user_id 、tenant 或 org 。第一次登录创建本地映射，之后按登录事件或定时任务同步禁用、离职、部门调整这类字段。不要直接拿外部账号 ID 当后台 user_id ，不然后面从 CAS 换到企业微信，权限表、日志和历史数据都会跟着疼。
这个方向也来自真实维护问题。2026-08-28 核验时，XYGo Admin 的 GitHub Issue #10 问过 caslogin 单点登录； Tag 已到 v1.4.9 ，但正式 Release 页还停在 v1.4.6 。项目现在主要还是 GoFrame + Vue3 + 本地 RBAC ，权限拦截能在 `server/internal/middleware/admin_permission.go` 这类位置看到，生成器字段同步在 `server/internal/logic/gencodes/sync_fields.go` 附近。它们更像本地业务权限边界，不适合被 SSO 直接吞掉。
所以我不太想把开源后台做成“内置万能 SSO”。适合做的是预留认证入口、用户映射接口、禁用同步和权限归属边界；不适合替每家公司决定 CAS 、OIDC 、LDAP 、企业微信到底谁是主。项目上下文只放一个链接： https://github.com/z312193608/xygo-admin
想问问 V 友的实际做法：你们接企业统一登录时，本地用户表会保留到什么程度？角色和菜单权限放后台本地，还是统一放到公司权限中心？开源 Go 后台如果要预留 SSO ，你们希望它做到哪一步就停？
我说的不是登录页上多一个按钮。认证入口可以交给外部系统，外部系统负责判断这个人是谁、能不能进公司系统、属于哪个组织。后台本地更适合保留角色、菜单、按钮、接口权限、数据范围和操作日志。原因很土：公司的 SSO 通常不理解某个后台里的“导出订单”“批量删除”“重置密码”这些业务动作。硬塞回统一权限中心，后面很容易变成谁都不敢改的黑盒。
比较稳的切法是中间留一张映射：provider 、external_subject 、local_user_id 、tenant 或 org 。第一次登录创建本地映射，之后按登录事件或定时任务同步禁用、离职、部门调整这类字段。不要直接拿外部账号 ID 当后台 user_id ，不然后面从 CAS 换到企业微信，权限表、日志和历史数据都会跟着疼。
这个方向也来自真实维护问题。2026-08-28 核验时，XYGo Admin 的 GitHub Issue #10 问过 caslogin 单点登录； Tag 已到 v1.4.9 ，但正式 Release 页还停在 v1.4.6 。项目现在主要还是 GoFrame + Vue3 + 本地 RBAC ，权限拦截能在 `server/internal/middleware/admin_permission.go` 这类位置看到，生成器字段同步在 `server/internal/logic/gencodes/sync_fields.go` 附近。它们更像本地业务权限边界，不适合被 SSO 直接吞掉。
所以我不太想把开源后台做成“内置万能 SSO”。适合做的是预留认证入口、用户映射接口、禁用同步和权限归属边界；不适合替每家公司决定 CAS 、OIDC 、LDAP 、企业微信到底谁是主。项目上下文只放一个链接： https://github.com/z312193608/xygo-admin
想问问 V 友的实际做法：你们接企业统一登录时，本地用户表会保留到什么程度？角色和菜单权限放后台本地，还是统一放到公司权限中心？开源 Go 后台如果要预留 SSO ，你们希望它做到哪一步就停？
Select Language