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

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

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

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

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

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

（图片来自WillTran在slideshare分享）

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

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

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

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

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

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

• 网关鉴权模式（API Gateway）

• 服务自主鉴权模式

• API Token模式（OAuth2.0）

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

由于OAuth2.0目前最为常用，所以接下来我再来详细讲解一下OAuth2.0的原理和各类用法。

三、详解 OAuth2.0 的「 访问安全 」？

OAuth2.0是一种访问授权协议框架。它是基于Token令牌的授权方式，在不暴露用户密码的情况下，使 应用方 能够获取到用户数据的访问权限。

例如：你开发了一个视频网站，可以采用第三方微信登陆，那么只要用户在微信上对这个网站授权了，那这个网站就可以在无需用户密码的情况下获取用户在微信上的头像。

OAuth2.0 的流程如下图：

OAuth2.0 里的主要名词有：

• 资源服务器：用户数据/资源存放的地方，在微服务架构中，服务就是资源服务器。在上面的例子中，微信头像存放的服务就是资源服务器。

• 资源拥有者：是指用户，资源的拥有人。在上面的例子中某个微信头像的用户就是资源拥有者。

• 授权服务器：是一个用来验证用户身份并颁发令牌的服务器。

• 客户端应用：想要访问用户受保护资源的客户端/Web应用。在上面的例子中的视频网站就是客户端应用。

• 访问令牌：Access Token，授予对资源服务器的访问权限额度令牌。

• 刷新令牌：客户端应用用于获取新的 Access Token 的一种令牌。

• 客户凭证：用户的账号密码，用于在 授权服务器 进行验证用户身份的凭证。

OAuth2.0有四种授权模式，也就是四种获取令牌的方式：授权码、简化式、用户名密码、客户端凭证。

下面来分别讲解一下：

以上，就是对微服务架构中「访问安全」的一些思考。

在微服务架构的系列文章中，前面已经通过文章介绍过了「服务注册 」、「服务网关 」、「配置中心 」、「 监控系统 」、「调用链监控」、「容错隔离」，大家可以翻阅历史文章查看。

码字不易啊，喜欢的话不妨转发朋友，或点击文章右下角的“在看”吧。