参考地址:微服务常见认证、鉴权方案_微服务鉴权方案-CSDN博客
1.SecurityOauth2
微服务的话可以选择在网关进行登录鉴权,但子服务之间相互调用无法有效鉴权
2.各服务自定义拦截器
不依赖框架,但写起来麻烦
3.Cas单点登录
新建一个服务去做鉴权,但写起来也比较麻烦,并且在分布式中可能出现网络问题
4.微服务间鉴权
如果只在网关鉴权,则微服务内部之间就没能鉴权。比如微服务A是订单服务,微服务B是支付服务,本来用户只有访问订单服务的权限,但订单服务有个接口内部访问了支付服务,就会导致用户能够间接访问到支付服务。
如果只在微服务内部鉴权,又浪费了网关鉴权。
我的看法是,微服务发出的请求加一个请求头service-name标识发出请求的服务名,包括网关也加,微服务加拦截器 拦截发现请求者是网关就不鉴权,因为在网关鉴权过了,如果请求者不是网关就鉴权。
也可以把鉴权粒度加粗,比如支付服务只允许订单服务访问,其他服务就直接不能访问,能粗粒度的控制一些。
5.关于令牌的存储方式
无状态和有状态令牌只和令牌存储有关,和前面鉴权的方案不等价。
有状态令牌,指令牌对应的内容在服务端有存储,如服务端session存用户信息,校验令牌即校验是否有对应存储,注销令牌就是把服务端存储删除。这种方式实现方便,缺点是需要存储,如果涉及分布式,往往不能再放内存,要第三方存储。
无状态令牌,如JWT,是把用户信息都放在了令牌中,校验令牌只要能解密令牌即令牌有效,如果令牌有效校验要通过服务端存储才能校验,则违反了无状态。这种方式服务端不需要存储,节省资源,但注销令牌需要额外设计。
方案设计适合功能就好,不必追求框架,以上几种常见做法也可以结合起来做,不必拘泥于一种
总结:
最理想的状态是在网关进行统一处理,但子服务间可能会出现用户越权限访问资源的问题,需要搭配其他方案进行处理
另起服务进行鉴权,感觉上是一个好方案,但在分布式的情况下网络因素不可控制.
令牌的形式感觉可以,只需要编写公共方法然后调用即可,有状态可使用redis.