微服务下的身份认证和令牌管理

分布式和微服务架构已经越来越多的应用在企业中，服务间的身份认证和令牌管理是其必不可少的部分。

我们的团队在构建一站式门户站点时，需要集成多个后端微服务，每一个服务需要访问不同的系统来完成对应的业务场景 (比如：订单系统，偏好推荐系统，产品系统等）。我们需要将这些系统有机的进行整合，通过在项目中的不断实践，配置恰当的身份认证和令牌管理，我们总结了一些微服务间的身份认证、令牌管理的架构演进与最佳实践。

背景

我们的系统是使用微服务架构开发并打包到容器中，这些系统部署在 Kubernetes（它是用于自动化部署，扩展和管理容器化应用程序的开源系统。它将组成应用程序的容器分组为逻辑单元，以便于管理和发现）。在这些站点中，前端系统需要携带令牌访问不同服务，每一个服务需要携带令牌访问不同的下游服务来完成相应的业务场景，所以这个过程涉及到各个服务之间的身份认证和令牌管理。

系统架构涉及到多个微服务，这些微服务系统由不同的团队维护，我们引进了不同的方案来解除各个系统在鉴权上的耦合，降低系统的复杂性，提高鉴权的可复用性和可维护性。

本文我们将结合项目中引进的系统自身鉴权，API网关鉴权和authentication sidecar模式，介绍整个上下游服务之间的身份认证、令牌管理的架构演进与最佳实践。

系统自身鉴权

系统自身鉴权，就是每个应用系统自己进行身份认证和令牌管理，下面我们就从Inbound Authentication和Outbound Authentication来分析。

Inbound Authentication

上图是入站身份验证流程，服务消费者调用Service时，Service作为服务提供者需要对消费者的令牌进行验证。具体流程如下：

1. 服务消费者从OAuth服务器获取令牌
2. 服务消费者携带令牌调用Service
3. API 请求流入Service中
4. Service从OAuth服务器获取公钥，验证令牌是否有效。公钥用于验证令牌数字签名。如果令牌有效，则在Service中进行业务处理

Outbound Authentication

这是本地的出站请求流程，Service作为服务消费者携带令牌访问其他后端服务。具体流程如下：

1. Service通过client id和client secret调用OAuth服务器获得令牌
2. Service携带令牌请求后端微服务

问题和挑战

从耦合性，复杂性，