微服务架构之「 访问安全 」

应用程序的访问安全又是我们每一个研发团队都必须关注的重点问题。尤其是在我们采用了微服务架构之后,项目的复杂度提升了N个级别,相应的,微服务的安全工作也就更难更复杂了。并且我们以往擅长的单体应用的安全方案对于微服务来说已经不再适用了。我们必须有一套新的方案来保障微服务架构的安全。

在探索微服务访问安全之前,我们还是先来回顾一下单体应用的安全是如何实现的。

一、传统单体应用如何实现「访问安全」?

下图就是一个传统单体应用的访问示意图:

(图片来自WillTran在slideshare分享)

在应用服务器里面,我们有一个auth模块(一般采用过滤来实现),当有客户端请求进来时,所有的请求都必须首先经过这个auth来做身份验证,验证通过后,才将请求发到后面的业务逻辑。

通常客户端在第一次请求的时候会带上身份校验信息(用户名和密码),auth模块在验证信息无误后,就会返回Cookie存到客户端,之后每次客户端只需要在请求中携带Cookie来访问,而auth模块也只需要校验Cookie的合法性后决定是否放行。

可见,在传统单体应用中的安全架构还是蛮简单的,对外也只有一个入口,通过auth校验后,内部的用户信息都是内存/线程传递,逻辑并不是复杂,所以风险也在可控范围内。

那么,当我们的项目改为微服务之后,「访问安全」又该怎么做呢。

二、微服务如何实现「访问安全」?

在微服务架构下,有以下三种方案可以选择,当然,用的最多的肯定还是OAuth模式。

  • 网关鉴权模式(API Gateway)

  • 服务自主鉴权模式

  • API Token模式(OAuth2.0)

下面分别来讲一下这三种模式:

  1. 网关鉴权模式(API Gateway)

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值