微服务架构下的认证鉴权解决方案

背景单体应用在向微服务化架构演进时,需要考虑如何解决服务认证授权的问题 。如果处理不好,会引发架构的混乱,带来安全、性能、难以维护的问题 。以最典型的包含WEB页面的具备登录态管理的系统为例 。在最初阶段,登录鉴权一般通过cookie+redis分布式session来实现 。

微服务架构下的认证鉴权解决方案

文章插图
 
在服务化过程中,单体系统会拆分为多个微服务,这时微服务间会出现相互调用 。对于使用Dubbo、Grpc等RPC协议的系统而言,由于给web页面提供的是HTTP接口,而给微服务间调用提供的RPC接口,架构比较清晰 。而对于Springcloud技术体系,微服间调用和页面都是通过HTTP RESTFUL接口,这时候要解决两个问题:
  1. web页面的登录校验
  2. 微服务之间的鉴权
解决方案透传cookie反模式这种方案希望保持单体架构时的调用方式,微服务间调用接口复用了提供给WEB页面的接口 。为了解决登录鉴权问题,微服务间调用时,会将WEB页面的cookie透传至其他服务,这样鉴权逻辑可以保持不动 。很显然,该方案虽然看上去能很好work,但它是一种反模式设计,完全违背了微服务的初衷,微服务一定是无状态的!
微服务架构下的认证鉴权解决方案

文章插图
 
内外接口分离模式很显然,上述方案是不合理的 。如果想继续保持服务间调用使用RESTFUL域名,则可以将面向前端的接口与面向微服务的接口区分开,实现方式是为两者加上不同的URL前缀,如/inner、/outer 。外部接口是给WEB页面调用的,内部接口是专门给微服务间调用的 。在认证鉴权时,仅针对外部接口进行鉴权,而内部接口直接放行 。该方案的问题是,内部接口存在安全隐患,可以被外界肆意攻击 。如果要缓解该问题,可通过如下方式:
  1. 申请一个额外的生产网段的域名(需做七网隔离,外网/办公网/生产网段无法互相访问),专门用于服务间调用 。
  2. 在Nignx侧增加配置,对于原有的域名,只放行以outer前缀开始的请求 。

微服务架构下的认证鉴权解决方案

文章插图
 
web和服务分离模式上述方案的另外一个变种,仍是将对外接口和对内接口分开,但是划分的更加彻底,新增了一个专门提供面向前端提供web接口的服务,如下图所示 。该方案的优点:
  1. 微服务不需要关心如何校验session,所有认证都在web服务做 。这个微服务是真正无状态的 。
  2. 微服务间的调用不做鉴权 。
  3. 微服务是高度通用的,只需要处理领域核心逻辑,不用关心如何和前端页面适配,这点对于平台型服务尤其如此 。
对于该方案中因内部接口调用产生的安全问题,可参考上个方案,申请一个额外的生产网段的域名 。
微服务架构下的认证鉴权解决方案

文章插图
 
网关鉴权对于有中台的技术团队而言,一般都会有提供一个通用的平台网关 。我们希望在网关解决所有登录鉴权的问题,这使得登录鉴权问题对业务服务完全透明 。而对于服务间调用的问题,可使用rpc、类rpc方式(ServiceMesh)、内部域名来实现,而这些调用方式都是零信任无鉴权的 。对于这种方案,微服务的api有很大的通用性和灵活性,接口设计不需要区分接口使用的场景,是目前业界比较推荐的做法 。
微服务架构下的认证鉴权解决方案

文章插图
 
总结本文介绍了服务在从单体演进到微服务架构过程中,对于服务认证鉴权遇到的问题,并提供了开发人员可能会用到的解决方案 。除方案1外(不大合理、属于野路子),其他方案在具体实践过程中都有较多的case 。如今微服务架构已经成为事实上的标准,我们希望微服务一定是无状态的,专注于处理业务流程和规则,而鉴权认证的逻辑应交给专门的技术组件来负责,因此让网关来统一处理鉴权是一个更优雅的方案 。
来源:
https://juejin.cn/post/7171729686936944654

【微服务架构下的认证鉴权解决方案】


    推荐阅读