浅述微服务安全管理机制

在微服务架构中一个应用通常会被拆分成一系列的微服务，这些微服务需要对访问者进行身份认证及鉴权，而此时进行应用安全管理，针对的不仅仅是用户请求，还包含其他微服务的调用。这时候安全管理由原来单一的“用户-服务”场景，变成了“用户-服务”“服务-服务”的多种场景。而且对于微服务架构而言，动辄就要面对数十个乃至上百个微服务之间的调用，那么该如何为这些调用提供高效安全的身份认证及鉴权呢？而且，当这些微服务面对外部用户请求时，如何提供细粒度的安全管控方案也是一个极为重要的问题。

在进行单体架构应用开发时最常使用的安全管理机制就是基于用户会话（Session）的认证，用户登录成功后，服务器就会将用户相关数据及权限信息存储到 Session 中。通常 Session 会直接保存在应用服务器中，仅将 Session 的 ID 返回到客户端，并存储在浏览器的 Cookie 中（对于 Java 应用来说就是 jsessionid），当下次访问时就可以通过该 ID 获取到相应的会话信息。当使用服务器集群时，可以通过 Session 复制或 Session 粘滞的方法来保障服务器可以获取到相应的 Session 数据。

在微服务架构下，安全解决方案所要解决的不仅是用户与微服务之间的请求，还包括微服务与微服务之间的调用，以上单体架构下的解决方案明显会感到非常吃力。针对微服务架构下的安全新挑战，下面来了解一下 4 种解决方案。

1. 单点登录（SSO）方案

单击登录方案是最常见的解决方案，但单点登录需要每个与用户交互的服务都必须与认证服务进行通信，这不但会造成重复，也会产生大量琐碎的网络流量；

2. 分布式会话（Session）方案

通过将用户会话信息存储在共享存储中，如 Redis，并使用用户会话的 ID 作为 key 来实现分布式哈希映射。当用户访问微服务时，会话数据就可以从共享存储中获取。该解决方案在高可用和扩展方面都很好，但是由于会话信息保存在共享存储中，所以需要一定的保护机制保护数据安全，因此在具体的实现中会具有比较高的复杂度。

3. 客户端令牌（Token）方案

令牌由客户端生成，并由认证服务器签名。在令牌中会包含足够的信息，客户端在请求时会将令牌附加在请求上，从而为各个微服务提供用户身份数据。此方案解决了分布式会话方案的安全性问题，但如何及时注销用户认证信息则是一个大问题，虽然可以使用短期令牌并频繁地与认证服务器进行校验，但并不可以彻底解决。JWT（JSON Web Tokens）是非常出名的客户端令牌解决方案，它足够简单，并且对各种环境支持程度也比较高。

4. 客户端令牌与 API 网关结合

通过在微服务架构中实施 API 网关，可以将原始的客户端令牌转换为内部会话令牌。一方面可以有效地隐藏微服务，另一方面通过 API 网关的统一入口可以实现令牌的注销处理。

随着近几年云服务应用的发展，基于令牌（Token）的认证使用范围也越来越广。对于基于令牌认证通常包含下面几层含义：

• 令牌是认证用户信息的集合，而不仅仅是一个无意义的 ID。

• 在令牌中已经包含足够多的信息，验证令牌就可以完成用户身份的校验，从而减轻了因为用户验证需要检索数据库的压力，提升了系统性能。

• 因为令牌是需要服务器进行签名发放的，所以如果令牌通过解码认证，我们就可以认为该令牌所包含的信息是合法有效的。

• 服务器会通过 HTTP 头部中的 Authorization 获取令牌信息并进行检查，并不需要在服务器端存储任何信息。

• 通过服务器对令牌的检查机制，可以将基于令牌的认证使用在基于浏览器的客户端和移动设备的 App 或是第三方应用上。

• 可以支持跨程序调用。基于 Cookie 是不允许垮域访问的，而令牌则不存在这个问题。

综上所述，基于令牌的认证由于会包含认证用户的相关信息，因此可以通过验证令牌来完成用户身份的校验，完全不同于之前基于会话的认证。因此，基于令牌的这个优点，像微信、支付宝、微博及 GitHub 等，都推出了基于令牌的认证服务，用于访问所开放的 API 及单点登录。