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

随着单体应用向微服务化演进,认证鉴权成为关键问题。本文分析了透传cookie反模式、内外接口分离模式、web和服务分离模式及网关鉴权四种解决方案,强调微服务应保持无状态,推荐使用网关统一处理鉴权,以确保安全性和可维护性。
摘要由CSDN通过智能技术生成

背景

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

在服务化过程中,单体系统会拆分为多个微服务,这时微服务间会出现相互调用。对于使用Dubbo、Grpc等RPC协议的系统而言,由于给web页面提供的是HTTP接口,而给微服务间调用提供的RPC接口,架构比较清晰。而对于Springcloud技术体系,微服间调用和页面都是通过HTTP RESTFUL接口,这时候要解决两个问题:

  1. web页面的登录校验

  2. 微服务之间的鉴权

解决方案

透传cookie反模式

这种方案希望保持单体架构时的调用方式,微服务间调用接口复用了提供给WEB页面的接口。 为了解决登录鉴权问题,微服务间调用时,会将WEB页面的cookie透传至其他服务,这样鉴权逻辑可以保持不动。 很显然,该方案虽然看上去能很好work,但它是一种反模式设计,完全违背了微服务的初衷,微服务一定是无状态的!

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值