分布式和微服务架构已经越来越多的应用在企业中，服务间的身份认证和令牌管理是其必不可少的部分。
我们的团队在构建一站式门户站点时，需要集成多个后端微服务，每一个服务需要访问不同的系统来完成对应的业务场景 (比如：订单系统，偏好推荐系统，产品系统等）。我们需要将这些系统有机的进行整合，通过在项目中的不断实践，配置恰当的身份认证和令牌管理，我们总结了一些微服务间的身份认证、令牌管理的架构演进与最佳实践。
背景
我们的系统是使用微服务架构开发并打包到容器中，这些系统部署在 Kubernetes（它是用于自动化部署，扩展和管理容器化应用程序的开源系统。它将组成应用程序的容器分组为逻辑单元，以便于管理和发现）。在这些站点中，前端系统需要携带令牌访问不同服务，每一个服务需要携带令牌访问不同的下游服务来完成相应的业务场景，所以这个过程涉及到各个服务之间的身份认证和令牌管理。
系统架构涉及到多个微服务，这些微服务系统由不同的团队维护，我们引进了不同的方案来解除各个系统在鉴权上的耦合，降低系统的复杂性，提高鉴权的可复用性和可维护性。
本文我们将结合项目中引进的系统自身鉴权，API网关鉴权和authentication sidecar模式，介绍整个上下游服务之间的身份认证、令牌管理的架构演进与最佳实践。
系统自身鉴权
系统自身鉴权，就是每个应用系统自己进行身份认证和令牌管理，下面我们就从Inbound Authentication和Outbound Authentication来分析。
Inbound Authentication
上图是入站身份验证流程，服务消费者调用Service时，Service作为服务提供者需要对消费者的令牌进行验证。具体流程如下：
- 服务消费者从OAuth服务器获取令牌
- 服务消费者携带令牌调用Service
- API 请求流入Service中
- Service从OAuth服务器获取公钥，验证令牌是否有效。公钥用于验证令牌数字签名。如果令牌有效，则在Service中进行业务处理
Outbound Authentication
这是本地的出站请求流程，Service作为服务消费者携带令牌访问其他后端服务。具体流程如下：
- Service通过client id和client secret调用OAuth服务器获得令牌
- Service携带令牌请求后端微服务
问题和挑战
从耦合性，复杂性，可复用性，可维护性四个维度来看，现在的inbound和outbound authentication流程面临如下问题：
- 耦合性：Service高度依赖于authentication SDK。从Inbound authentication和OutBound authentication的流程中可以看到，每一个Service都依赖基于自己编程语言的authentication SDK验证和获取token
- 复杂性：Service还需要在自己的应用中关注服务间的身份认证和令牌的获取，增加了Service代码的复杂性
- 可复用性：微服务中会有很多业务domain和对应不同编程语言的Service，每个Service都需要实现相同的认证流程，这个authentication不可以复用
- 可维护性：如果OAuth协议需要升级，如企业要从Open ID Connect升级到Auth0，那么每个Service都需要更改自己领域服务的代码
如何来解决这些问题呢，API Gateway是选项。
API网关鉴权
什么是API网关
API网关位于客户端与各个微服务间，充当了反向代理的角色，将客户端请求路由到相应的微服务。与此同时，它可以完成安全，限流，缓存，日志，监控，重试，熔断等功能。API网关方式的核心要点是，所有的接入方和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。
身份认证作为API网关中的一个组件，可以以模块的方式运行，也可以用微服务的方式运行。
Inbound Authentication
如上图所示，当服务消费者需要请求服务提供者时，
- 服务消费者请求OAuth服务器获得访问服务端的令牌
- 服务消费者携带令牌调用服务端，该API请求会先经过API网关
- API网关的身份认证服务获取公钥对令牌进行验证
- 如果令牌有效，那么请求将流向相关的服务提供者
相比于微服务系统自身鉴权，API网关鉴权可以来进行Inbound Authentication，从耦合性，复杂性，可复用性，可维护性四个维度来看比系统自身鉴权都有所改善。
- 耦合性：Service Provider不需要高度依赖于authentication SDK进行身份认证，而是把其交给了API网关
- 复杂性：Service Provider不需要在自己的应用中关注服务间的身份认证
- 可复用性：所有的接入方和消费端都通过统一的网关接入Service，对于在API网关后面的Service来说，inbound authentication实现了复用
- 可维护性：如果OAuth协议需要升级，只需要更改API网关里面的鉴权服务的代码
问题和挑战
API网关没有处理Outbound Authentication，服务提供者还是需要在自己服务端获取令牌来访问其他服务，所以令牌管理的耦合性，复杂性，可复用性，可维护性问题没有解决。
另外如果API网关和服务提供者是通过网络通信，那么根据“零信任网络，永远不要信任网络并始终进行验证”原则，我们还是需要在API网关和服务提供者实施安全控制，增加了鉴权的复杂性。
针对这些问题，Thoughtworks技术雷达里面收录了一种处于试验阶段的方案sidecars-for-endpoint-security，后面我们就叫它authentication sidecar pattern。
Authentication Sidecar Pattern
什么是Sidecar Pattern
Sidecar模式是一种解耦的模式，比较适合系统运行在日益复杂的多云或混合云环境中，其中包含多个分布式组件和服务。如这些组件和服务是使用微服务架构开发并打包到容器中，部署在Kubernetes，Kubernetes将组成应用程序的容器分组为逻辑单元，以便于管理和发现。
如上图所示，sidecar附加到Service并为Service提供支持功能。Sidecar位于与Service相同的Kubernetes Pod中，并与Service共享相同的生命周期，与Service一起创建和淘汰。
Ingress sidecar用于处理到附加到Service的入站请求。Egress sidecar用于处理Service到下游Service的出站请求。
下面会通过对比系统自身鉴权和authentication sidecar模式，来对authentication sidecar进行分析。
Inbound Authentication Sidecar
上半部分的图是系统自身鉴权的入站身份认证流程，首先服务消费者从OAuth服务器获取令牌，然后携带令牌调用Service, Service验证令牌。下半部分的图是authentication sidecar的身份认证。
基础设施级别: Kubernetes的Pod有一个ingress sidecar负责验证入站的令牌，authentication SDK从Service分离并放入ingress sidecar。
整体的流程:
- Ingress sidecar启动时从OAuth服务器中获取公钥或者证书，服务消费者请求OAuth服务器获得访问后端Service的令牌
- 服务消费者携带令牌调用Service
- 服务消费者的请求会通过Secure API会流入到ingress sidecar来验证令牌。如果令牌验证失败，则sidecar拒绝该请求
- 如果令牌有效，那么请求将流向Service
此外，Service中还有一个用于运行状况检查的Health check API。
我们可以看到ingress sidecar的特性:
- Service中不需要authentication SDK了
- Sidecar启动时首先获取公钥并缓存起来，sidecar可以基于本地缓存的公钥对令牌进行验证，而不是通过网络访问OAuth服务器进行验证
Outbound Authentication Sidecar
左半部分是系统自身鉴权系统出站请求流程，首先Service从OAuth服务器获取令牌，然后携带令牌调用其他后端微服务。右半部分是authentication sidecar的authentication token的管理。
基础设施级别: Kubernetes的Pod有一个egress sidecar负责获取出站令牌，authentication SDK从Service分离并放入egress sidecar。
整体的流程:
- Service的请求先流向egress sidecar
- 如果egress sidecar缓存中没有令牌，则sidecar获取令牌并将其缓存起来。当token过期时，它支持自动刷新token
- 如果sidecar缓存中有令牌，则不需要请求OAuth服务器。然后将API请求携带令牌路由到其他后端微服务
我们可以看到egress sidecar的特性:
- Service中的authentication SDK是不需要的
- 当Service调用下游时，egress sidecar会向API请求头添加令牌。因为令牌存储在sidecar缓存中，不需要每次都调用OAuth 服务器。当令牌过期时，自动刷新令牌。
Authentication sidecar的全景图
上面是整个请求的全景图，上游可以是前端或后端服务消费者，Service是自己团队的应用程序，下游是服务提供者。Ingress和egress sidecar有独立的容器，和service容器一样都位于同一个Pod。
Authentication Sidecar的好处
上图是系统自身鉴权到authentication sidecar的架构演进， 从耦合性，复杂性，重复实现，可维护性四个维度来看：
- 耦合性：解除了业务系统和authentication的耦合，消除了应用Service中的关于身份认证和authentication token管理的重复实现，每个业务Service无需实现相同的身份验证流程，只需在kurbernets 的配置文件中对其进行配置
- 复杂性：降低应用系统的复杂性，它将authentication委派给与业务系统部署在同一Pod中的进程外sidecar。这样自己的业务系统可以更专注于自身的业务
- 可复用性：身份认证和token管理标准化，与编程语言无关。每个Service不需要实现相同的认证流程。企业内的团队都可以轻松复用该sidecar来进行身份认证和token的管理
- 可维护性：只有一个code base，使得该authentication sidecar可以成为企业内部的开源项目，易于进行OAuth服务的升级和替换，升级替换时只需要在authentication sidecar的code base进行改动就可以了
总结
本文分析了微服务间身份认证和令牌管理的系统自身鉴权，API网关鉴权和authentication sidecar的方案，痛点和好处。软件工程中不可能有任何“银弹” 解决软件的复杂度问题，这几种方案都有相关的条件和限制，下表是关于这三种方案的适用场景。
| 方案 | 适用场景 |
|---|---|
| 系统自身鉴权 | 单体应用或各系统间没有太多服务通讯；需要快速完成的系统 |
| API网关鉴权 | 所有的客户端和消费端都通过统一的网关接入微服务，只能进行Inbound Authentication |
| Authentication sidecar | 企业内有很多分布式微服务并有容器化的部署；Service Mesh架构 |
针对现在分布式，微服务，容器化架构的流行，许多系统运行在日益复杂的多云或混合云环境中，其中包含多个分布式组件和服务。通过引入authentication sidecar，使得各自团队负责的Service代码更加简洁，解除了业务Service和authentication服务的耦合，在每一个的Service中消除了重复的authentication代码，有利于分布式和微服务系统的快速构建，开启了分布式和微服务架构的新体验。
文/Thoughtworks刘勇智
原文链接：https://insights.thoughtworks.cn/microservices-authentication-token-management/
更多精彩洞见，请关注微信公众号：Thoughtworks洞见