这是一个创建于 816 天前的主题，其中的信息可能已经有所发展或是发生改变。
查了些资料. 大多都是网关 Gateway,做认证.鉴权. 也有根据实际情况,在 gateway 做认证和部份鉴权+单微服务内做业务鉴权. 我觉得自己的比较合适第二种,gateway+单微服务这种方式.但还有几点疑惑还在犹豫中
环境: spring cloud gateway,nacos,openfeign,(认证.鉴权,授权未使用三方库)
gateway 层
-
认证没有什么问题.
-
鉴权部分的话,应该只能做根据 url 的鉴权. 配置 url+权限这种方式.这种方式需与 api 做协调,一边加了 url,也需要在 gateway 层配置这个 url+允许权限+拒绝权限.
单个微服务层
-
需要在业务鉴权,比如管理员,发布者,拥有同样的功能,甚至比发布者更多功能.为了减低相同逻辑的维护成本, 所有觉得用鉴权这种方式比较合适一点.
-
鉴权方式 1,gateway 到 auth 服务加载权限列表,再回 gateway 做鉴权
因为 gateway 加载过这个权限列表,所以在转发时带上这个权限列表,在单个微服务内,直接拿这个权限列表做鉴权,这种方式需要带着权限列表跑.这种方式避免多次加载权限列表,微服务将脱离 auth 依赖,缺点是需要带着这个列表到处跑.
-
鉴权方式 2,gateway 只到 auth 服务做鉴权,返回鉴权结果
这种方式需要多次鉴权,gateway 跑 auth 鉴权,微服务跑 auth 鉴权. 所有需要鉴权的服务都依赖 auth
授权
-
注册权限
微服务中定义权限,自动注册到权限模块.
-
授权 权限模块,统一分配
这些只是一些构思,还没有去实现,肯定有不合理的地方,也有些问题还没考虑到.
欢迎大家指点一二. 让我能有机会一次性比较全面的完成这个模块.
 | 1 anonydmer 2023-07-25 15:06:40 +08:00 1. 网关对内外处理的数据结构不一样是很常见的做法，比如外部认证用 cookie ，然后转成 jwt 传给内部微服务，这个过程要附带什么信息随你 2. 权限列表到处跑有什么问题？大多数网关到微服务都是内部调用；不存在带宽和性能瓶颈 3. 微服务自己做鉴权，依赖一个 jwt 中权限信息也没啥大不了的，这一步完全可以做到只需要离线验证 jwt 合法就可以，不需要去调用认证服务 4. 退一步讲，实在要在微服务中去认证服务实时获取权限项也不是什么大问题，微服务的一个好处是单个服务的性能可以优化到极致，只需要把你的认证服务性能优化到足够好就可以了，经典的方法如用缓存 |
 | 2 retanoj 2023-07-25 15:55:21 +08:00 是不是感觉引入一个较成熟的，可配置的鉴权组件比较好？ |
 | 3 dnjat OP @anonydmer 权限列表到处跑,有点大,放到 header 中,得生成一个比如 base64 的块(或其它方式,反正自己解析就好了),如果权限越多,这个字符串块越大. 或者放到 post 参数中.这个又有点涉及到入侵了. 离线验证是不不错的想法. 用户权限列表是放在 redis 中,这过程倒不是很复杂,只是网关层获取了一次,跑到微服务中又获取一次,感觉有点多余了. 谢谢老兄的分析,看了你的分析,大概明白我想要的结构了 |
| 6 retanoj 2023-07-26 08:54:23 +08:00 |
Select Language