基于 Spring Security OAuth2和 JWT 构建保护微服务系统

小灰灰 2022-11-30 04:10 186阅读 0赞

> 我们希望自己的微服务能够在用户登录之后才可以访问，而单独给每个微服务单独做用户权限模块就显得很弱了，从复用角度来说是需要重构的，从功能角度来说，也是欠缺的。尤其是前后端完全分离之后，我们的用户信息不一定存在于 Session 会话中。

### ![format_png][] ###

## **应用场景** ##

常见的应用场景如下图，用户通过浏览器进行登录，一旦确定用户名和密码正确，那么在服务器端使用秘钥创建 JWT，并且返回给浏览器；接下来我们的请求需要在头部增加 jwt 信息，服务器端进行解密获取用户信息，然后进行其他业务逻辑处理，再返回客户端

![format_png 1][]

### **什么是OAuth2？** ###

OAuth2是一个关于授权的开放标准，核心思路是通过各类认证手段（具体什么手段OAuth2不关心）认证用户身份，并颁发token（令牌），使得第三方应用可以使用该令牌在**限定时间**、**限定范围**访问指定资源。主要涉及的RFC规范有`RFC6749`（整体授权框架）,`RFC6750`（令牌使用）,`RFC6819`（威胁模型）这几个，一般我们需要了解的就是`RFC6749`。获取令牌的方式主要有四种，分别是`授权码模式`，`简单模式`，`密码模式`和`客户端模式`，如何获取token不在本篇文章的讨论范围，我们这里假定客户端已经通过某种方式获取到了access\_token，想了解具体的oauth2授权步骤可以移步阮一峰老师的理解OAuth 2.0，里面有非常详细的说明。

这里要先明确几个OAuth2中的几个重要概念：

*  `resource owner`: 拥有被访问资源的用户
 *  `user-agent`: 一般来说就是浏览器
 *  `client`: 第三方应用
 *  `Authorization server`: 认证服务器，用来进行用户认证并颁发token
 *  `Resource server`：资源服务器，拥有被访问资源的服务器，需要通过token来确定是否有权限访问

明确概念后，就可以看OAuth2的协议握手流程，摘自RFC6749

![format_png 2][]

### **什么是Spring Security？** ###

Spring Security是一套安全框架，可以基于RBAC（基于角色的权限控制）对用户的访问权限进行控制，核心思想是通过一系列的filter chain来进行拦截过滤，以下是ss中默认的内置过滤器列表，当然你也可以通过`custom-filter`来自定义扩展filter chain列表

<table> 
 <thead> 
  <tr> 
   <th>Alias</th> 
   <th>Filter Class</th> 
   <th>Namespace Element or Attribute</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>CHANNEL_FILTER</td> 
   <td>ChannelProcessingFilter</td> 
   <td>http/intercept-url@requires-channel</td> 
  </tr> 
  <tr> 
   <td>SECURITY_CONTEXT_FILTER</td> 
   <td>SecurityContextPersistenceFilter</td> 
   <td>http</td> 
  </tr> 
  <tr> 
   <td>CONCURRENT_SESSION_FILTER</td> 
   <td>ConcurrentSessionFilter</td> 
   <td>session-management/concurrency-control</td> 
  </tr> 
  <tr> 
   <td>HEADERS_FILTER</td> 
   <td>HeaderWriterFilter</td> 
   <td>http/headers</td> 
  </tr> 
  <tr> 
   <td>CSRF_FILTER</td> 
   <td>CsrfFilter</td> 
   <td>http/csrf</td> 
  </tr> 
  <tr> 
   <td>LOGOUT_FILTER</td> 
   <td>LogoutFilter</td> 
   <td>http/logout</td> 
  </tr> 
  <tr> 
   <td>X509_FILTER</td> 
   <td>X509AuthenticationFilter</td> 
   <td>http/x509</td> 
  </tr> 
  <tr> 
   <td>PRE_AUTH_FILTER</td> 
   <td>AbstractPreAuthenticatedProcessingFilter</td> 
   <td>N/A</td> 
  </tr> 
  <tr> 
   <td>CAS_FILTER</td> 
   <td>CasAuthenticationFilter</td> 
   <td>N/A</td> 
  </tr> 
  <tr> 
   <td>FORM_LOGIN_FILTER</td> 
   <td>UsernamePasswordAuthenticationFilter</td> 
   <td>http/form-login</td> 
  </tr> 
  <tr> 
   <td>BASIC_AUTH_FILTER</td> 
   <td>BasicAuthenticationFilter</td> 
   <td>http/http-basic</td> 
  </tr> 
  <tr> 
   <td>SERVLET_API_SUPPORT_FILTER</td> 
   <td>SecurityContextHolderAwareRequestFilter</td> 
   <td>http/@servlet-api-provision</td> 
  </tr> 
  <tr> 
   <td>JAAS_API_SUPPORT_FILTER</td> 
   <td>JaasApiIntegrationFilter</td> 
   <td>http/@jaas-api-provision</td> 
  </tr> 
  <tr> 
   <td>REMEMBER_ME_FILTER</td> 
   <td>RememberMeAuthenticationFilter</td> 
   <td>http/remember-me</td> 
  </tr> 
  <tr> 
   <td>ANONYMOUS_FILTER</td> 
   <td>AnonymousAuthenticationFilter</td> 
   <td>http/anonymous</td> 
  </tr> 
  <tr> 
   <td>SESSION_MANAGEMENT_FILTER</td> 
   <td>SessionManagementFilter</td> 
   <td>session-management</td> 
  </tr> 
  <tr> 
   <td>EXCEPTION_TRANSLATION_FILTER</td> 
   <td>ExceptionTranslationFilter</td> 
   <td>http</td> 
  </tr> 
  <tr> 
   <td>FILTER_SECURITY_INTERCEPTOR</td> 
   <td>FilterSecurityInterceptor</td> 
   <td>http</td> 
  </tr> 
  <tr> 
   <td>SWITCH_USER_FILTER</td> 
   <td>SwitchUserFilter</td> 
   <td>N/A</td> 
  </tr> 
 </tbody> 
</table>

这里面最核心的就是`FILTER_SECURITY_INTERCEPTOR`，通过`FilterInvocationSecurityMetadataSource`来进行资源权限的匹配，`AccessDecisionManager`来执行访问策略。

### 认证与授权（Authentication and Authorization） ###

一般意义来说的应用访问安全性，都是围绕认证（Authentication）和授权（Authorization）这两个核心概念来展开的。即首先需要确定用户身份，在确定这个用户是否有访问指定资源的权限。认证这块的解决方案很多，主流的有`CAS`、`SAML2`、`OAUTH2`等（不巧这几个都用过-\_-），我们常说的单点登录方案（SSO）说的就是这块，授权的话主流的就是spring security和shiro。shiro我没用过，据说是比较轻量级，相比较而言spring security确实架构比较复杂。

### **OAuth2与SSO** ###

首先要明确一点，**OAuth2并不是一个SSO框架，但可以实现SSO功能**。

所以总结一下就是：**通过将用户信息这个资源设置为被保护资源，可以使用OAuth2技术实现单点登陆（SSO），而Spring Security OAuth2就是这种OAuth2 SSO方案的一个实现。**

### **JWT介绍** ###

终于来到了著名的JWT部分了，JWT全称为Json Web Token，最近随着微服务架构的流行而越来越火，号称新一代的认证技术。今天我们就来看一下，jwt的本质到底是什么。

我们先来看一下OAuth2的token技术有没有什么痛点，相信从之前的介绍中你也发现了，token技术最大的问题是**不携带用户信息**，且资源服务器无法进行本地验证，每次对于资源的访问，资源服务器都需要向认证服务器发起请求，一是验证token的有效性，二是获取token对应的用户信息。如果有大量的此类请求，无疑处理效率是很低的，且认证服务器会变成一个中心节点，对于SLA和处理性能等均有很高的要求，这在分布式架构下是很要命的。

JWT就是在这样的背景下诞生的，从本质上来说，jwt就是一种**特殊格式**的token。普通的oauth2颁发的就是一串随机hash字符串，本身无意义，而jwt格式的token是有特定含义的，分为三部分：

*  头部`Header`
 *  载荷`Payload`
 *  签名`Signature`

这三部分均用base64进行编码，当中用`.`进行分隔，一个典型的jwt格式的token类似`xxxxx.yyyyy.zzzzz`。关于jwt格式的更多具体说明，不是本文讨论的重点，大家可以直接去官网查看官方文档，这里不过多赘述。

jwt相对于传统的token来说，解决以下两个痛点：

*  通过验证签名，token的验证可以直接在本地完成，不需要连接认证服务器
 *  在payload中可以定义用户相关信息，这样就轻松实现了token和用户信息的绑定

在上面的那个资源服务器和认证服务器分离的例子中，如果认证服务器颁发的是jwt格式的token，那么资源服务器就可以直接自己验证token的有效性并绑定用户，这无疑大大提升了处理效率且减少了单点隐患。

### JWT适用场景与不适用场景 ###

JWT的使用上现在也有一种误区，认为传统的认证方式都应该被jwt取代。事实上，jwt也不能解决一切问题，它也有适用场景和不适用场景。

适用场景：

*  一次性的身份认证
 *  api的鉴权

这些场景能充分发挥jwt无状态以及分布式验证的优势

不适用的场景：

*  传统的基于session的用户会话保持

**不要试图用jwt去代替session。**这种模式下其实传统的session+cookie机制工作的更好，jwt因为其无状态和分布式，事实上只要在有效期内，是无法作废的，用户的签退更多是一个客户端的签退，服务端token仍然有效，你只要使用这个token，仍然可以登陆系统。另外一个问题是续签问题，使用token，无疑令续签变得十分麻烦，当然你也可以通过redis去记录token状态，并在用户访问后更新这个状态，但这就是硬生生把jwt的无状态搞成有状态了，而这些在传统的session+cookie机制中都是不需要去考虑的。这种场景下，考虑高可用，我更加推荐采用分布式的session机制，现在已经有很多的成熟框架可供选择了（比如spring session）。

# 基于Spring Security OAuth2和JWT构建保护微服务系统 #

本工程代码是基于简书一文基于 Spring Security OAuth2和 JWT 构建保护微服务系统所编写的。

## 目录说明 ##

1.  ljl-architecture-spring-cloud 基于Dalston.SR5版本Spring Cloud + 1.5.13.RELEASE版本Spring Boot去构建。
2.  ljl-architecture-spring-cloud2 基于Finchley.SR2版本Spring Cloud + 2.0.8.RELEASE版本Spring Boot构建。

github地址：

https://github.com/leslie-1994/spring-security-oauth2-jwt-demo

[format_png]: /images/20221124/0d49923daaf2489490b93956301d971e.png
[format_png 1]: /images/20221124/3ad613dc0f4c43e9855e36b7a525ca4e.png
[format_png 2]: /images/20221124/997e77c645cb49d7816dd9ba55fe419a.png