微服务架构中的安全管理

微服务架构中的安全管理

在微服务中,我们一般都会有一个网关,网关背后有很多个微服务,所有的请求都是首先到达网关,再由网关转发到不同的服务上去。另外我们可能会搭建一个统一认证中心,简化的架构图如下:
在这里插入图片描述
在这个微服务架构中,我们的鉴权流程是这样:

1.客户端携带用户名密码发送登录请求到网关。
2.网关收到请求之后,将请求路由到统一认证中心。
3.统一认证中心确认用户的身份没有问题之后,将返回一个 access_token 给网关。
4.网关将 access_token 转发到客户端。
5.客户端将获取到的 access_token 放在请求头中去请求真正的微服务,当然这个操作依然会被网关拦下。
6.网关将客户端的请求路由到微服务上,接下来微服务需要根据 access_token 鉴定用户身份。
7.微服务可以调用统一认证中心去检验用户身份,如果我们采用了 JWT 的话,这一步实际上可以省略。
8.微服务确认了用户身份和权限之后,就可以根据实际情况返回数据给用户了。

这是我们一个大致的认证流程。

OAuth2 中的授权服务器在校验的时候,实际上是有两个方面的校验工作,一方面是校验客户端信息,另一方面是校验用户信息,微服务 A 和 微服务 B 都在处理业务上的事情,实际上没有必要和客户端关联起来,所以我们可以在网关上先初步校验客户端信息,然后在微服务上再去校验用户身份信息。

网关还有另外一个身份就是资源服务器,当请求到达网关之后,如果是去往统一认证中心的请求,则直接转发即可;如果请求是去往普通微服务的请求,网关可以先做初步校验,就是校验客户端身份,如果没有问题,则将请求路由到不同的微服务上,各个微服务再根据自身的业务和权限情况,进行响应。

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值