给别人做软件的网站,wordpress算术验证,微信如何开通公众号,怎么创建公众号赚钱【答疑解惑】| 作者 / Edison Zhou这是恰童鞋骚年的第267篇原创内容之前有同事问为何要用基于JWT令牌的认证架构#xff0c;然后近期又有童鞋在后台留言问微服务安全认证架构的实践#xff0c;因此我决定花两篇推文来解答一下。为了答好这个话题#xff0c;我们先来看看微服… 【答疑解惑】| 作者 / Edison Zhou这是恰童鞋骚年的第267篇原创内容之前有同事问为何要用基于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中的会话和状态管理传送门https://docs.microsoft.com/zh-cn/aspnet/core/fundamentals/app-state?viewaspnetcore-3.12单块阶段下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来说也可以采用高可用集群方案业界也有很多可扩展的实践案例。画外音虽然是单块时代发展出来的技术但是无状态会话和集中状态会话却是微服务安全认证架构的基础。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.客户端向后台微服务发请求会带上刚刚得到的TokenStep4.微服务接收到用户请求时首先会向AuthService发出一个请求对这个Token进行合法性校验Step5.AuthService校验Token通过后会返回该用户的详情信息如果微服务需要的话可以拿到用户的一些比如角色之类的信息Step6.微服务进行自己的逻辑处理最终返回数据给客户端画外音v2.0版本可以看做是v1.5的一个升级改造专门针对微服务架构的场景进行了扩展可以应对微服务架构存在的挑战。它把登录认证、令牌颁发等工作封装在了AuthService中其他微服务统一共用AuthService经过扩展还可以实现SSO单点登录。4微服务架构阶段下v2.0认证架构虽然可以解决问题但是又引发了另外的问题首先每个微服务都需要实现部分认证鉴权的逻辑使得微服务开发方无法聚焦于业务逻辑的开发。其次认证鉴权逻辑分散在每个微服务当中一方面会带来不规范容易出错的问题另一方面也会有潜在的安全风险比如某些开发人员可能会忘记校验令牌。为了解决上面提到的问题同时考虑到微服务拆分后引入微服务API网关MyShop技术团队设计了下图所示的v2.5认证架构TokenGateway结合方式MyShop v2.5版本-基于TokenGateway的认证从上图可以看出该架构将每个微服务都要进行的部分认证鉴权的逻辑从微服务转移到了网关中。即网关处负责拿到令牌向AuthService进行鉴权通过后再将请求转发到后端的微服务微服务不再包含任何认证鉴权的逻辑。总体上通过引入网关进行令牌的鉴权之后大大减少了后端微服务开发方的职责使得他们更专注于微服务的业务逻辑的开发。此外引入网关之后网关可以统一处理登录客户端的校验也便于实现SSO单点登录也为MyShop后续的微服务化和业务成长提供了基础。画外音v2.5版本应该是目前大多数团队所采用的一种认证架构了。对我司也是不过Token类型使用的是JWT。5小结本文通过一个MyShop的案例的演化介绍了微服务的安全认证架构是如何演进而来的但是v2.5版本TokenGateway方式总体上还是比较重每个请求都还是需要到AuthService上去做认证鉴权的操作这对于AuthService来说算是压力比较大。针对这个问题业界广泛采用JWT这种轻量级的解决方案来重构安全认证架构。那么问题来了JWT是什么原理实现方式下一期骚年快答为你解答这几个问题。往期骚年快答技术中台与业务中台有啥联系微服务架构中的BFF到底是个啥为何微服务项目都爱用单体仓库专注于开发技术与个人成长分享做对你有用的公众号????点个赞/在看如何
