微服务常见认证、鉴权方案（学习总结）

参考地址：https://blog.csdn.net/u014203449/article/details/120487310

1.SecurityOauth2

微服务的话可以选择在网关进行登录鉴权,但子服务之间相互调用无法有效鉴权

2.各服务自定义拦截器

不依赖框架,但写起来麻烦

3.Cas单点登录

新建一个服务去做鉴权,但写起来也比较麻烦,并且在分布式中可能出现网络问题

4.微服务间鉴权

如果只在网关鉴权，则微服务内部之间就没能鉴权。比如微服务A是订单服务，微服务B是支付服务，本来用户只有访问订单服务的权限，但订单服务有个接口内部访问了支付服务，就会导致用户能够间接访问到支付服务。

如果只在微服务内部鉴权，又浪费了网关鉴权。

我的看法是，微服务发出的请求加一个请求头service-name标识发出请求的服务名，包括网关也加，微服务加拦截器 拦截发现请求者是网关就不鉴权，因为在网关鉴权过了，如果请求者不是网关就鉴权。

也可以把鉴权粒度加粗，比如支付服务只允许订单服务访问，其他服务就直接不能访问，能粗粒度的控制一些。

5.关于令牌的存储方式

无状态和有状态令牌只和令牌存储有关，和前面鉴权的方案不等价。

有状态令牌，指令牌对应的内容在服务端有存储，如服务端session存用户信息，校验令牌即校验是否有对应存储，注销令牌就是把服务端存储删除。这种方式实现方便，缺点是需要存储，如果涉及分布式，往往不能再放内存，要第三方存储。

无状态令牌，如JWT，是把用户信息都放在了令牌中，校验令牌只要能解密令牌即令牌有效，如果令牌有效校验要通过服务端存储才能校验，则违反了无状态。这种方式服务端不需要存储，节省资源，但注销令牌需要额外设计。

方案设计适合功能就好，不必追求框架，以上几种常见做法也可以结合起来做，不必拘泥于一种

总结:

最理想的状态是在网关进行统一处理,但子服务间可能会出现用户越权限访问资源的问题,需要搭配其他方案进行处理

另起服务进行鉴权,感觉上是一个好方案,但在分布式的情况下网络因素不可控制.

令牌的形式感觉可以,只需要编写公共方法然后调用即可,有状态可使用redis.