Spring Cloud认证和授权

微服务安全与权限流程

我们发送请求到负载均衡软件，负载均衡发到微服务网关上，网关进行用户认证后，解析出用户的基本信息，通过认证后，携带用户标识到后台微服务，微服务根据标识进行相应的鉴权，这样就形成一个完整的权限链路。

• 认证：通俗来讲，就是验证这个用户是谁。
• 鉴权：通俗来讲，就是了解这个用户能做什么事。

Spring Cloud认证和授权方案

微服务下SSO单点登陆方案

由于服务被拆分成很多细小的服务，这种情况下，需要为每个服务进行每个用户的SSO动作，那么每个服务都需要做用户的认证和授权，可能保存用户信息或者每个用户都会和鉴权服务打交道，这种情况会带来非常大的网络消耗和性能损耗，也可能会造成数据不一致，所有不太建议用这种方案。

分布式Session与网关结合方案

分布式Session方案在使用上很广泛，业界很多项目都使用了这样的方案。大体流程如下：

1. 用户在网关进行SSO登陆，进行用户认证，检查用户是否存在和有效。
2. 如果认证通过，则将用户的信息存储在第三方部件中，如MySQL，Redis。
3. 后端微服务可以从共享存储中拿到用户的数据。

很多场景下，这种方案是推荐的，因为很方便同时可以扩展，也可以保证高可用。缺点是依赖第三方部件，且这些部件需要做高可用，并且需要增加安全的控制，实现起来由一定复杂度。

客户端Token与网关结合方案

实现步骤如下：

1. 客户端持有一个Token，通常可用JWT或者其他加密的算法实现自己的一种Token，然后通过Token保存了用户的信息。
2. 发起请求并携带Token,Token传到网关层后，网关层进行认证和校验。
3. 校验通过，携带Token到后台的微服务中，可以进行具体的接口或者url验证。
4. 如果涉及用户大量数据的存放，则Token可能不太合适，或者和上面的分布式Session一样，使用第三方部件来存储这些信息。但对应Token来说，它的注销会由一定的麻烦，需要在网关层进行注销。

浏览器Cookie与网关结合方案

和上面的类似，不同的是把用户的信息放在Cookie里，然后通过网关来解析Cookie，从而获取用户的信息。这种方式适合老系统改造。

网关与Token和服务间鉴权结合

对于有些项目而言，本身网络和外部隔离，加上其他的安全手段，只需要在网关进行认证和授权就行，后台服务间的调用，不需要做权限的控制。但某些时候，还是需要对服务间的调用进行鉴权，知道某个用户是否有权限调用某个接口。这时的方案如下：

• 在网关层做认证，通过用户校验后，传递用户信息到header中，后台服务在收到header后进行解析，解析完后看是否有调用此服务或某个url的权限，完成鉴权。
• 从服务内部发送的请求，在出去时进行拦截，把用户信息保存在header中，然后传出去，被调用方获取到header后进行解析和鉴权。