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

背景

单体应用在向微服务化架构演进时,需要考虑如何解决服务认证授权的问题。如果处理不好,会引发架构的混乱,带来安全、性能、难以维护的问题。 以最典型的包含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。如今微服务架构已经成为事实上的标准,我们希望微服务一定是无状态的,专注于处理业务流程和规则,而鉴权认证的逻辑应交给专门的技术组件来负责,因此让网关来统一处理鉴权是一个更优雅的方案。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码

)">
< <上一篇
下一篇>>