微服务系统中，分别有后台系统管理员和 APP 用户两种类型的用户，该如何做认证？

[lcq]

如题，是把他们认为都是用户整合在一个表里还是应该做两套认证，求各位大佬给个建议

[kop1989]

都可以。
但理论上讲分表更好。
因为很有可能面向管理人员和面向 c 端的登录不是一个服务。（ c 端和 b 端隔离）。

[ffLoveJava]

我更想知道权限怎么控制 ？ 例如 PC 端有一套操作权限(菜单、页面、按钮) ，APP 有一套权限(页面、按钮)。那怎么分贝控制权限？
@kop1989 @lcq

[securityCoding]

我个人理解是不用分表, 可以独立出几张不同的认证源表
t_user, t_user_oauth_pw, t_user_oauth_wechat, t_user_oauth_qq, t_user_login_flow
用户表(公共属性:uid,类型等等)
认证表-用户名密码
认证表-微信登录
认证表-qq 登录

专门的账户服务,提供不同方式的登录 api
BUserLoginByPw();
CUserLoginByWechat();

网关: 登录态验证收拢到网关统一处理,业务微服务不用管登录态,直接从上下文获取相关的用户属性就行了

[securityCoding]

@ffLoveJava 权限资源的管理模型就是 rbac, 账户创建的时候会结合业务同步初始化权限资源 , 登录后前端直接查询菜单 api 渲染即可

[lcq]

@kop1989 是的，这两个是不同的服务，只是都用到了 oauth2.0 授权机制，如果分表，app 已经认证的用户怎么杜绝使用 token 去请求管理后台的接口，网关校验吗？ 然后 c 端和 b 端具体怎么做到隔离，微服务小白，求大佬支招

[lcq]

@securityCoding 谢谢 有考虑过用这种方式，按我现在的系统就是一个用户公共表 一个 APP 用户表 一个管理系统用户表，公共表中区分用户类型这样吗

[lcq]

@ffLoveJava 可以再登录的时候初始化用户操作权限

[damai0419]

应该有一张统一的用户表，收拢后台系统系统和前台系统的公共属性，例如账号，密码，性别等。然后再分出来两张表，后台员工表和 app 用户表，分别存储差异化信息。

[damai0419]

@damai0419 登陆在网关统一处理，鉴权的话就分两套逻辑处理。

[luvroot]

RBA jwt

[securityCoding]

@lcq 是这样的,同一个领域对象的数据不要强行分割

[securityCoding]

@lcq token 校验肯定是不同的,网关根据不同的校验配置去请求相应的认证接口

[lcq]

@damai0419 然后如何避免一个已经认证的用户携带 token 请求另一个系统的接口，是在网关做检验吗

[lcq]

@securityCoding 好的 get 到了 谢谢

[chinvo]

@securityCoding #3 理论上更科学的设计方法是 微信登录 的 openid 和 QQ 登录 的 userid 都属于 user token, 那么就都放到 user_tokens 表里面, 用一个字段区分 token 类型.

用户表里放 用户名 /账号、手机号、邮箱、手机号验证状态、邮箱验证状态、密码、账号状态 等

[chinvo]

然后有一个 user_profiles 表放普通用户的“profile”, 有个其他表放内部用户的 profile

用 user_role 表放 多对多 的 用户 - 角色 关系

具体业务系统里用 角色 或 权限 限制特定用户群

[securityCoding]

@chinvo 是的,对于相同认证类型可以放一张表,用户量大了还是推荐分表存储

[Hanggi]

嗯嗯，同意不分开用户，RBAC 控制权限，可以应付大部分情况。
permission 部分使用 resource 和 operation (命名可能不同)，区分用户操作权限是后台还是 APP 。
把 permission 分配给相应的 Role，再把 Role 分配给用户就好了。

[gz911122]

两套比较好.
一个是面向公司内部人员的. 一个是面向用户的.
二者基本没啥关联的.

[h123123h]

做两套

[chihiro2014]

做两套更好，处理起来也简单

[jeffh]

这是两种不同用户，最好两套表，app 面向用户可能会保存地址等信息，admin 面向后台用户，可能有岗位的信息。同时 admin 也有权限的控制。不能认为这两种用户是一样的。

[devswork]

我也遇到这个问题了，来看下大家意见