这是一个创建于 960 天前的主题，其中的信息可能已经有所发展或是发生改变。
是不是不应该呀？
我感觉微服务中的鉴权中心就负责跟网关配合好发 token 就可以了
但是我不太敢确定,所以来请教一下大家
 |
1
freeup 2022-03-23 11:27:51 +08:00  1
应该要吧 鉴权中心连用户都不晓得 那鉴了个寂寞呀
至于说的整合不清楚是代码层面的整合还是远程调用用户服务 我们系统是鉴权服务远程调用用户服务查询用户信息 然后进行鉴权 |
 |
3
5200721 2022-03-23 12:17:15 +08:00 1
鉴权肯定得校验账号密码吧，那肯定得调用户服务的 RPC 吧，拿到 Token 后，后续就可以直接网关校验了
|
|
4
5200721 2022-03-23 12:17:38 +08:00
当然如果网关要鉴权可能还是需要拿权限信息
|
|
5
5200721 2022-03-23 12:18:00 +08:00
@ouyanglong721 说错了，认证得校验账号密码
|
 |
6
ifane 2022-03-23 14:53:30 +08:00
鉴权应当和用户信息分离，鉴权应当只关注用户是否有权限操作资源。
|
 |
7
qqlyatt 2022-03-23 15:08:20 +08:00 2
我认为大概是这样的结构：前端页面，前端服务器，网关，授权服务器，业务资源服务器也就是 API 服务器。流程大概是这样的：用户点击某些简单功能时，不需要知道用户是谁，也就不用登录；当用户点击某些重要功能是，要知道用户是谁，有没有请求这个功能 API 的权限。用 OAUTH2+JWT 模式的话，这时候就要前端服务器就要携带授权类型 header 和 redirect_uriheader 跳转到授权服务器的登录页面，让用户输入身份信息（一般是用户名密码），授权服务器验证完用户的身份信息，验证失败就返回 401 未认证成功响应，验证成功就返回授权码。前端服务器再拿着授权码并携带自己的身份信息 client_id 和 client_secret ，redirect_uri 向授权服务器请求 Token ，授权服务器验证成功，响应 Token 。||||前端服务器保存 Token 。||||当用户点击业务功能 API 时，前端服务器为这个 request 携带上 Token ，请求到网关，由于网关启动时已经从授权服务器获取了验证 Token 的公钥，这时候就验证这个 Token 可用性和未被修改就行了，验证成功后，网关放行跳转到指定的业务资源 API ，资源服务器给出业务响应。这样整个流程就结束了。
|
 |
9
7911364440 2022-03-23 17:37:12 +08:00
@ifane 不拿到用户信息怎么判断用户是否有权限操作资源呢
|
 |
10
libook 2022-03-23 18:16:58 +08:00 1
没有啥应该不应该，都是看整合了成本和收益如何、拆分了成本和收益如何。
我个人的习惯是，不到有充分理由的情况下不拆成单独服务，但要具备能随时拆的设计。 我做的项目用户信息管理是个底层公共服务，很多表层服务都会依赖这个服务的 API ，所以拆了出来，使得运维上更容易做性能优化，以及更方便做一些信息安全方面的合规设计。 |
 |
11
shanguiyao OP @freeup 谢谢您的解答。嗯，我跟您的想法差不多，认同远程调用，问题没描述清楚😂
|
|
12
shanguiyao OP @ouyanglong721 谢谢您的解答。嗯，我也觉得调用户服务是合理的。
|
|
13
shanguiyao OP @libook 先谢谢您的解答。对，一切得根据实际情况来看拆不拆，我还是喜欢拆一点😂
|
|
14
shanguiyao OP |
 |
15
xuanbg 2022-03-23 19:40:42 +08:00 1
我分了 6 个服务：资源、用户、租户、组织机构、角色、身份认证
|
|
16
xuanbg 2022-03-23 19:41:42 +08:00
鉴权是在网关做的，加上这个 7 个服务了
|
|
17
shanguiyao OP @xuanbg 先谢谢您的解答。角色也要跟用户服务拆分开吗？
|
Select Language