微服务,认证,鉴权,授权 机制如何设计比较通用合理.

[dnjat]

查了些资料. 大多都是网关 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

授权

• 注册权限

  微服务中定义权限,自动注册到权限模块.

• 授权 权限模块,统一分配

---

这些只是一些构思,还没有去实现,肯定有不合理的地方,也有些问题还没考虑到.

欢迎大家指点一二. 让我能有机会一次性比较全面的完成这个模块.

[anonydmer]

1. 网关对内外处理的数据结构不一样是很常见的做法，比如外部认证用 cookie ，然后转成 jwt 传给内部微服务，这个过程要附带什么信息随你
2. 权限列表到处跑有什么问题？大多数网关到微服务都是内部调用；不存在带宽和性能瓶颈
3. 微服务自己做鉴权，依赖一个 jwt 中权限信息也没啥大不了的，这一步完全可以做到只需要离线验证 jwt 合法就可以，不需要去调用认证服务
4. 退一步讲，实在要在微服务中去认证服务实时获取权限项也不是什么大问题，微服务的一个好处是单个服务的性能可以优化到极致，只需要把你的认证服务性能优化到足够好就可以了，经典的方法如用缓存

[retanoj]

是不是感觉引入一个较成熟的，可配置的鉴权组件比较好？

[dnjat]

@anonydmer
权限列表到处跑,有点大,放到 header 中,得生成一个比如 base64 的块(或其它方式,反正自己解析就好了),如果权限越多,这个字符串块越大. 或者放到 post 参数中.这个又有点涉及到入侵了.
离线验证是不不错的想法.
用户权限列表是放在 redis 中,这过程倒不是很复杂,只是网关层获取了一次,跑到微服务中又获取一次,感觉有点多余了.
谢谢老兄的分析,看了你的分析,大概明白我想要的结构了

[dnjat]

@retanoj jwt,spring security shiro 这些吗

[retanoj]

@dnjat
casbin 这种可配置的吧，可能还有更好的

spring security/shiro 感觉还是有一定的开发量

[retanoj]

@dnjat
我见过的设计方案，是网关和基础的认证&授权是在一起的，也算避免了所谓的授权服务独立后，网关查一次，下游服务查一次的问题
如果下游服务还有特殊授权要求，那下游服务可以自己做额外功

[dnjat]

@retanoj 我了解下 casbin,说不定很适合我的场景.
我也查了些资料,大部分都是在网关做认证,授权的. 但务业权限,数据权限.网关就控制不了. 还是需要在下游服务中再鉴权一次. 如果有服务调用服务,就得多加载几次权限了