专栏首页ThoughtWorks微服务下的身份认证和令牌管理

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

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

背景

我们的系统是使用微服务架构开发并打包到容器中,这些系统部署在 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携带令牌请求后端微服务
问题和挑战

从耦合性,复杂性,可复用性,可维护性四个维度来看,现在的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

如上图所示,当服务消费者需要请求服务提供者时,

  1. 服务消费者请求OAuth服务器获得访问服务端的令牌
  2. 服务消费者携带令牌调用服务端,该API请求会先经过API网关
  3. API网关的身份认证服务获取公钥对令牌进行验证
  4. 如果令牌有效,那么请求将流向相关的服务提供者

相比于微服务系统自身鉴权,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。整体的流程:

  1. Ingress sidecar启动时从OAuth服务器中获取公钥或者证书,服务消费者请求OAuth服务器获得访问后端Service的令牌
  2. 服务消费者携带令牌调用Service
  3. 服务消费者的请求会通过Secure API会流入到ingress sidecar来验证令牌。如果令牌验证失败,则sidecar拒绝该请求
  4. 如果令牌有效,那么请求将流向Service

此外,Service中还有一个用于运行状况检查的Health check API。我们可以看到ingress sidecar的特性:

  1. Service中不需要authentication SDK了
  2. Sidecar启动时首先获取公钥并缓存起来,sidecar可以基于本地缓存的公钥对令牌进行验证,而不是通过网络访问OAuth服务器进行验证

Outbound Authentication Sidecar

左半部分是系统自身鉴权系统出站请求流程,首先Service从OAuth服务器获取令牌,然后携带令牌调用其他后端微服务。右半部分是authentication sidecar的authentication token的管理。基础设施级别: Kubernetes的Pod有一个egress sidecar负责获取出站令牌,authentication SDK从Service分离并放入egress sidecar。整体的流程:

  1. Service的请求先流向egress sidecar
  2. 如果egress sidecar缓存中没有令牌,则sidecar获取令牌并将其缓存起来。当token过期时,它支持自动刷新token
  3. 如果sidecar缓存中有令牌,则不需要请求OAuth服务器。然后将API请求携带令牌路由到其他后端微服务

我们可以看到egress sidecar的特性:

  1. Service中的authentication SDK是不需要的
  2. 当Service调用下游时,egress sidecar会向API请求头添加令牌。因为令牌存储在sidecar缓存中,不需要每次都调用OAuth 服务器。当令牌过期时,自动刷新令牌。

Authentication sidecar的全景图

上面是整个请求的全景图,上游可以是前端或后端服务消费者,Service是自己团队的应用程序,下游是服务提供者。Ingress和egress sidecar有独立的容器,和service容器一样都位于同一个Pod。

Authentication Sidecar的好处

上图是系统自身鉴权到authentication sidecar的架构演进, 从耦合性,复杂性,重复实现,可维护性四个维度来看:

  1. 耦合性:解除了业务系统和authentication的耦合,消除了应用Service中的关于身份认证和authentication token管理的重复实现,每个业务Service无需实现相同的身份验证流程,只需在kurbernets 的配置文件中对其进行配置。
  2. 复杂性:降低应用系统的复杂性,它将authentication委派给与业务系统部署在同一Pod中的进程外sidecar,这样自己的业务系统可以更专注于自身的业务。
  3. 可复用性:身份认证和token管理标准化,与编程语言无关。每个Service不需要实现相同的认证流程。企业内的团队都可以轻松复用该sidecar来进行身份认证和token的管理。
  4. 可维护性:只有一个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洞见(TW-Insights),作者:刘勇智

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-07-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 微服务架构下的统一身份认证和授权

    本文讨论基于微服务架构下的身份认证和用户授权的技术方案,在阅读之前,最好先熟悉并理解以下几个知识点:

    matinal
  • 基于STS和JWT的微服务身份认证

    自 Martin Fowler 提出微服务架构的概念后,这个名词就一直比较流行,总是成为众多技术论坛和公众号的讨论热点。很多互联网和软件公司都在将原有的整体架构...

    牛嗷嗷
  • 微服务架构下的身份认证与鉴权

    阿杜
  • 边缘认证和与令牌无关的身份传播

    翻译自Edge Authentication and Token-Agnostic Identity Propagation。通过本文可以了解到Netflix是...

    charlieroro
  • 从五个方面入手,保障微服务应用安全

    随着计算机、互联网技术的飞速发展,信息安全已然是一个全民关心的问题,也是各大企业非常重视的问题。企业一般会从多个层次着手保障信息安全,如:物理安全、网络安全、系...

    yuanyi928
  • 深入聊聊微服务架构的身份认证问题

    随着微服务架构的兴起,传统的单体应用场景下的身份认证和鉴权面临的挑战越来越大。单体应用体系下,应用是一个整体,一般针对所有的请求都会进行权限校验。请求一般会通过...

    lyb-geek
  • 微服务[学成在线] day16:基于Spring Security Oauth2开发认证服务

    要想掌握学生的学习情况就需要知道用户的身份信息,记录哪个用户在什么时间学习什么课程;如果用户要购买课程也需要知道用户的身份信息。所以,去管理学生的学习过程最基本...

    LCyee
  • 【全栈修炼】OAuth2 修炼宝典

    > 开放授权(OAuth)是一个开放标准,允许用户让第三方应用访问该用户在某一网站上存储的私密的资源(如照片,视频,联系人列表),而无需将用户名和密码提供给第三...

    pingan8787
  • 【全栈修炼】396- OAuth2 修炼宝典

    严格来说,OAuth2 不是一个标准协议,而是一个安全的授权框架。其详细描述系统中不同角色,用户,服务前端应用(如 API )以及客户端(如网站或APP)之间如...

    pingan8787
  • 微服务[学成在线] day17:基于Zuul网关实现路由转发、过滤器

    前端请求资源服务需要携带两个token,一个是cookie中的身份令牌,一个是http header中的jwt令牌

    LCyee
  • 微服务实践分享与探讨

    服务调用关系 ? API网关优缺点 简化沟通方式 API网关对所有微服务提供单一的访问点 安全性 对客户端隐藏了服务发现和服务版本 阻止大规模攻击,包括S...

    牛嗷嗷
  • 微服务架构下的安全认证与鉴权

    本文目录: 一、单体应用 VS 微服务 二、微服务常见安全认证方案 三、JWT介绍 四、OAuth 2.0 介绍 五、思考总结 从单体应用架构到分布式应用架构再...

    yuanyi928
  • 微服务架构下的鉴权,怎么做更优雅?

    从单体应用架构到分布式应用架构再到微服务架构,应用的安全访问在不断的经受考验。为了适应架构的变化、需求的变化,身份认证与鉴权方案也在不断的变革。面对数十个甚至上...

    Bug开发工程师
  • 微服务架构下的安全认证与鉴权

    从单体应用架构到分布式应用架构再到微服务架构,应用的安全访问在不断的经受考验。为了适应架构的变化、需求的变化,身份认证与鉴权方案也在不断的变革。面对数十个甚至上...

    java思维导图
  • 8种至关重要OAuth API授权流与能力

    在本文中,Curity的Daniel Lindau概述了重要的OAuth授权流程和能力。

    yuanyi928
  • 保护微服务(第一部分)

    面向服务的体系结构(SOA)引入了一种设计范式,该技术讨论了高度分离的服务部署,其中服务间通过标准化的消息格式在网络上通信,而不关心服务的实现技术...

    用户1196457
  • 跟着大公司学安全架构之云IAM架构

    云环境由于各种应用的发展以及来自不同设备和用户的访问,导致身份管理和访问安全成为一个关键问题。典型的安全问题是未授权访问、账户被盗、内部恶意等。因此需要一个可靠...

    网络安全观
  • 如何在微服务架构中实现安全性?

    导读:网络安全已成为每个企业都面临的关键问题。几乎每天都有关于黑客如何窃取公司数据的头条新闻。为了开发安全的软件并远离头条新闻,企业需要解决各种安全问题,包括硬...

    Bug开发工程师
  • 如何在微服务架构中实现安全性?

    网络安全已成为每个企业都面临的关键问题。几乎每天都有关于黑客如何窃取公司数据的头条新闻。为了开发安全的软件并远离头条新闻,企业需要解决各种安全问题,包括硬件的物...

    用户1516716

扫码关注云+社区

领取腾讯云代金券