微服务安全认证架构是如何演进而来的?

之前有同事问为何要用基于JWT令牌的认证架构,然后近期又有童鞋在后台留言问微服务平安认证架构的实践,因此我决议花两篇推文来解答一下。为了答好这个话题,我们先来看看微服务的平安认证架构是若何演进而来的,从而更好地明白。

微服务安全认证架构是如何演进而来的?

1 单块阶段(上)

首先,我们有需要再次了解下认证和授权这两个基本概念:

认证,Authentication,识别你是谁。即在网站上用来识别某个用户是否是注册过的正当用户。

授权,Authorization,识别你能做什么。即在网站上用来识别某个用户是否有某方面的权限。

然后,这里照样引用我在波波先生的《Spring Boot与K8s云原生应用开发》课程中学到的一个案例,来学习网站平安架构的演进。

假设我们把时间倒退回2006年,我们有一个叫做MyShop的网站,它的平安架构大概是下面这个样子,我们暂且称之为v1版本:

微服务安全认证架构是如何演进而来的?

MyShop v1版本的认证操作

可以看到,这个v1版本的传统平安认证架构,使用到了我们十分熟悉的Session + Cookie的模式来实现用户的认证。即当一个注册用户通过登录操作请求后,Web服务器通过向数据库举行校验用户名和密码,通事后就会向Session中添加一条纪录,然后返回给浏览器。在返回给浏览器的报文中,会将sessionId放在Cookie里头。

微服务安全认证架构是如何演进而来的?

MyShop v1版本的接见操作

这样一来,用户在登录之后再接见网站的时刻,就会将带有sessionId的Cookie传给Web服务器,而Web服务器就可以通过Cookie中的sessionId去Session纪录中检查,若是没有过时就以为其是认证的活跃用户。

在ASP.NET Core中,提供了一个治理Session的中间件,我们可以在StartUp中注册和使用这个中间件即可用来治理会话状态。

参考资料:有关ASP.NET Core中的会话和状态治理,这里是传送门

2 单块阶段(下)

v1版本上线测试之后,测试职员发现存在一个问题:登录用户会间歇性地退出登录,而且会话还没有超时。经由剖析后发现,原来的Session纪录只会在登录过的那台Web服务器上存在,而MyShop是以集群方式来部署的,由前置的Nginx代理服务器举行负载平衡地请求转发。
针对这个问题,MyShop设计了下图所示的v1.1版本的认证架构,又称为黏性Session架构。也就是说,不管哪一次请求,Nginx都市将对应的sessionId发给对应的Web服务器举行处置,而不是平衡地轮流转发。换句话说,Nginx服务器将会维护sessionId与各个Web服务器的Session之间的关联,以保证在会话时代的Session绑定。

微服务安全认证架构是如何演进而来的?

MyShop v1.1版本-黏性会话

就这样,一晃两三年又过了,MyShop v1.1的认证架构支持了它早期的快速生长。然则,随着营业和用户量的不停扩展,它也逐渐暴露出稳定性和扩展性方面的问题。这些问题,归根结底照样由黏性会话所造成的。

(1)稳定性:黏性会话会将用户会话绑定到某个服务器上,若是我们要对这个服务器举行一些升级或革新又或服务器延迟或宕机,那么此服务器上的一波认证用户信息就会瞬间消逝,用户必须重新登录。

(2)扩展性:黏性会话使得Web服务器和Nginx负载平衡服务器上都保留了状态,整体上属于一个有状态架构。随着流量的增进,这些状态同时给Web服务器和负载平衡器都市带来较大的压力。和无状态的应用架构比起来,这种有状态的应用架构对照难以扩展。

一般来说,常见的解决黏性会话的解决方案有以下几种:

(1)会话同步复制:即各个Web服务器之间同步Session,然则会引入复杂性,整体的性能较低。
(2)无状态会话:即Session数据不存在服务器端,而是存在浏览器端,然则存在数据泄露风险,且浏览器端对于Cookie的巨细有限制(4KB)。

(3)集中状态会话:即将Session集中存储在某个存储中,好比Memcached或Redis这种高性能缓存中。

因此,MyShop选择了集中状态会话的方式演进出了v1.5平安认证架构,如下图所示:

微服务安全认证架构是如何演进而来的?

MyShop v1.5版本-集中状态会话

在v1.5版本中,Web服务器和Nginx服务器不再存储会话状态,转而交由Redis举行统一存储,从而提高了稳定性和扩展性。对于Redis来说,也可以接纳高可用集群方案,业界也有许多可扩展的实践案例。

画外音:虽然是单块时代生长出来的手艺,然则无状态会话和集中状态会话却是微服务平安认证架构的基础。

2020年百度之星程序设计大赛-初赛二

3 微服务架构阶段(上)

时光飞逝,时间来到了2015年,这时代MyShop的营业量也迅速的飞涨,时代互联网的手艺也发生了大转变。微服务架构、无线应用、SPA应用雨后春笋般的泛起,MyShop的手艺团队也准备陆续应用实践,进一步厚实和扩展营业渠道,赋能营业端。然则,微服务架构的平安认证授权也存在着一些挑战:

微服务安全认证架构是如何演进而来的?

微服务认证授权挑战

(1)后台应用和服务众多,若何对每一个服务举行认证和鉴权?传统的用户名&密码以及Session/Cookie的方式还能够适用吗?
(2)前端的用户入口众多,若是每个入口都搞一套登录认证,显然成本高且难以扩展。有没有一种SSO单点登录的方案?经由MyShop手艺团队的剖析,传统的用户名&密码+Session/Cookie的方式无法直接套用在微服务架构上,然则可以借鉴之前的思绪,他们提出了面向微服务架构的v2.0平安认证系统,如下图所示:

微服务安全认证架构是如何演进而来的?

MyShop v2.0版本-基于Token的认证

v2.0平安认证系统最大的转变就在于,将上岸认证抽取为一个自力的API微服务AuthService,拥有一个自力的UserDB。这个服务统一负担上岸认证、用户校验、令牌发表等职责。此外,v2.0版本还引入了Token作为服务挪用认证鉴权的主要凭证。这里的话,v2.0接纳的是一个透明令牌(也称为引用令牌),即它是一个无意义的随机字符串。这个令牌跟Auth Service上的一次上岸会话相关联,后续也可以通过API去校验这个令牌的正当性。

画外音:实在这个Token令牌,就相当于一个SessionId。每个微服务拿到令牌,都可以去AuthService举行认证鉴权。

总结下来,v2.0的平安认证系统的步骤如下:

Step1.用户通过某种客户端(Web/SPA/H5/App等)举行上岸,AuthService通过比对用户数据库举行校验;

Step2.AuthService校验通事后会确立一个用户会话Session(此Session和之前版本的类似,存在一个过时时间,可以存储在AuthService所在的服务器上也可以存在Redis中),然后发表一个Token给客户端;

Step3.客户端向后台微服务发请求,会带上刚刚获得的Token;

Step4.微服务接收到用户请求时,首先会向AuthService发出一个请求对这个Token举行正当性校验;

Step5.AuthService校验Token通事后会返回该用户的详情信息(若是微服务需要的话,可以拿到用户的一些好比角色之类的信息);
Step6.微服务举行自己的逻辑处置,最终返回数据给客户端;

画外音:v2.0版本可以看做是v1.5的一个升级革新,专门针对微服务架构的场景举行了扩展,可以应对微服务架构存在的挑战。它把登录认证、令牌发表等事情封装在了AuthService中,其他微服务统一共用AuthService,经由扩展还可以实现SSO单点登录。

4 微服务架构阶段(下)

v2.0认证架构虽然可以解决问题,然则又引发了另外的问题:首先,每个微服务都需要实现部门认证鉴权的逻辑,使得微服务开发方无法聚焦于营业逻辑的开发。其次,认证鉴权逻辑涣散在每个微服务当中,一方面会带来不规范容易失足的问题,另一方面也会有潜在的平安风险(好比某些开发职员可能会遗忘校验令牌)。为了解决上面提到的问题,同时考虑到微服务拆分后引入微服务API网关,MyShop手艺团队设计了下图所示的v2.5认证架构:Token+Gateway连系方式

微服务安全认证架构是如何演进而来的?

MyShop v2.5版本-基于Token+Gateway的认证

从上图可以看出,该架构将每个微服务都要举行的部门认证鉴权的逻辑从微服务转移到了网关中。即网关处卖力拿到令牌向AuthService举行鉴权,通事后再将请求转发到后端的微服务,微服务不再包罗任何认证鉴权的逻辑。总体上,通过引入网关举行令牌的鉴权之后,大大减少了后端微服务开发方的职责,使得他们更专注于微服务的营业逻辑的开发。此外,引入网关之后,网关可以统一处置登录客户端的校验,也便于实现SSO单点登录,也为MyShop后续的微服务化和营业发展提供了基础。

画外音:v2.5版本应该是现在大多数团队所接纳的一种认证架构了。对,我司也是,不外Token类型使用的是JWT。

5 小结

本文通过一个MyShop的案例的演化先容了微服务的平安认证架构是若何演进而来的,然则v2.5版本(Token+Gateway方式)总体上照样对照重,每个请求都照样需要到AuthService上去做认证鉴权的操作,这对于AuthService来说算是压力对照大。针对这个问题,业界普遍接纳JWT这种轻量级的解决方案来重构平安认证架构。那么问题来了,JWT是什么?原理?实现方式?下一期骚年快答,为你解答这几个问题。

参考资料

杨波,《Spring Boot与K8s云原生应用开发》(极客时间课程,推荐学习)

杨波,《微服务架构160讲》(极客时间课程,推荐学习)

Microsoft,《ASP.NET Core中的会话状态治理

晓晨,《IdentityServer4 中文文档与实战

 

微服务安全认证架构是如何演进而来的?

作者:周旭龙

出处:https://edisonchou.cnblogs.com

本文版权归作者和博客园共有,迎接转载,但未经作者赞成必须保留此段声明,且在文章页面显著位置给出原文链接。

原创文章,作者:28x29新闻网,如若转载,请注明出处:https://www.28x29.com/archives/24866.html