初步认识微服务中的资源服务器

传统安全方式的不足

在Spring Security干货系列教程中，我们一步步来学习了Spring Security的使用。其中大部分涉及到的都是传统的保护应用的方式。我们通过用户名和密码(也可以是验证码)来获得服务器给的凭证(JWT是其中的一种)，然后携带凭证去请求接口以获得对应的资源(Resource)。绝大部分的单体应用使用这种模式非常方便和简单。

但是一旦你所在的项目做大了，需要改造成微服务了，使用这种方式就显得有些笨重了，每个服务的资源都需要认证授权，所以需要一种范式来简化这一流程。

认证和授权是可以松耦合的

用户的认证和资源的访问控制其实是可以分开的。就比如你买飞机票，现在你不仅可以在航空公司的售票部门买到票，也可以到第三方票务中心线下或者线上去买票，最终每个架次的航班会对你的票据进行核验以确定你是否符合登记的条件，而且不会关心你的购票渠道。这是实际生活中的一个例子。

如果在微服务中，我们每一个服务只需要校验请求是否具有符合访问资源的权限即可，我们可以把资源访问校验的逻辑抽象一个公用的模型，并用代码来实现，非常符合微服务去中心化的思想。这就是资源服务器的根本意义。

资源服务器

资源服务器的全称是 OAuth2 Resource Server ，它实际上是OAuth 2.0 协议的一部分，通常我们借助于Json Web Token来实现(其实还有一种叫Opaque Tokens也可以使用)。OAuth2.0授权服务器发给客户端Json Web Token，这个Token是用来验证客户端是否有权限访问某个资源的。

当单体应用改造成微服务时，授权服务其实还是中心化比较好，统一管理用户的认证授权并发放给客户端Token。每个具体的服务同时也是一个资源服务器，我们只需要抽象好访问控制的接口就可以了。这里遵循一个原则：共性封装成类库(jar),个性化抽象为配置。 大致的流程图如下：

这样授权服务器只管发Token功能，资源服务器只负责验证Token，每当有新的服务接入我们只需要加入配套的资源服务依赖和配置即可，改造起来非常简单。

网上还有一种资源服务器也中心化的方式，也就是在网关处进行集中认证处理。个人认为除非你有过类似经验，否则并不容易接受，而且还要处理一些安全上下文跨服务的问题。对于初学者来说强烈建议使用以上的模型。

其实我已经对上面的模型进行了初步实现和改造，我会在下一篇再讲解如何在微服务中利用Spring Security实现资源服务器，以及单体应用改造微服务中相关方面的一些要点。