基于OAuth2.0的税务系统内外网数据传输安全方案

邓雅文

（湖北大学 计算机信息与工程学院，湖北 武汉 430062）

0 引 言

金税工程是国家重要的电子政务工程，加强税务系统网络安全建设，对于维护国家安全具有十分重要的意义。随着金税三期工程在全国税务系统的上线和“互联网+税务”行动计划的深入实施，税收信息化建设得到了快速发展，但移动系统面临的网络安全问题成为发展过程中不可回避的问题。数据安全加密传输可防止明文数据传输时被中途截获，保证传输的安全性。通过身份认证的系统用户可以根据自己的权限来访问系统，但是对其中重要模块和数据的访问一定要合理控制，系统需具备辨识访客身份，同时对访问的行为进行跟踪记录的功能[1]。

税务移动系统中客户端和服务端会话分离，保持服务端基于无状态请求提供服务，同时又要保证服务端资源的安全性。基于OAuth2.0协议和JWT的认证模式被广泛应用在登录认证和三方授权等技术中，其通过特定算法生成用户唯一的令牌token对象，然后用户数据请求过程中携带此token即可完成身份有效校验，既保证了前后端分离，同时也提升了用户请求资源的安全性[2,3]。

1 相关技术

1.1 OAuth2.0协议

OAuth2.0协议是用于授权的行业标准协议，其致力于简化客户端开发人员的工作，同时为Web应用程序、桌面应用程序以及移动端程序等提供特定的授权流程。OAuth2.0授权框架使第三方应用程序能够代表资源所有者获得对HTTP及HTTPS服务的有限访问权限，通过在资源所有者和HTTP服务之间协调批准交互，或者允许第三方应用程序以自己的名义获得访问权限。OAuth2.0于2012年10月发布，在此之前发布的有OAuth1.0协议和OAuth1.0a协议。OAuth2.0协议和OAuth1.0协议相比，其特点主要体现在3个方面。

一是采用简化的签名机制。OAuth2.0协议舍弃了加密算法，转而使用SSL传输为数据提供安全保障。二是简化了授权流程。OAuth1.0协议使用双Secret（appSecret、tokenSecret）的验证方式，流程较为复杂。此外，OAuth2.0协议减少了协议的交互次数，只需提供Access Token即可，简化了协议流程。三是提供多种授权模式[4]。OAuth2.0 协议提供多种授权方式及流程方便开发者，包含了多场景模式，更好地适应当今智能设备和移动设备快速发展的趋势[5-7]。

在传统的客户端-服务器身份验证模型中，客户端通过使用资源所有者的凭据与服务器进行身份验证，来请求服务器上的受保护资源。为了向第三方应用程序提供对受限资源的访问，资源所有者与第三方共享凭据，第三方应用程序存储资源拥有者的凭据以备将来使用。明文密码存在固有的安全弱点，同时资源服务器仍支持密码身份验证。第三方应用程序对资源所有者的受保护资源拥有过多的访问权限，从而使得资源拥有者无法限制资源请求的持续时间和请求范围。资源拥有者不能单独撤销对单个三方应用程序的访问权限，除非撤销所有三方应用程序的访问权限，而且必须修改第三方的密码。OAuth协议通过引入一个授权层将客户端的角色与资源所有者的角色分开来解决这个安全问题，在用户访问第三方资源的过程中不泄露用户的用户名和口令等认证信息。

1.2 JWT验证机制

传统的Cookie-Session模式是基于客户端和服务器端的状态进行验证，即将客户端信息保存在服务器上，客户端携带服务器签发的Cookie向服务器发送请求，服务器收到请求后通过自身保存的Session内容与客户端携带的Cookie进行对比来验证用户的身份。但是基于Cookie-Session的验证模式在浏览器使用GET请求访问页面时会出现安全隐患，发送GET请求时会默认带上该域名下的Cookie，容易带来跨站请求漏洞风险，用户数据的安全性无法得到保障。同时服务器端的Session会占用许多空间，若大量用户同时登录将导致服务器端处理请求速度变慢。而token是一种无状态且跨服务器的高性能验证模式。

不同于Cookie-Session需要在同一个服务器上验证，token的验证在任何服务器上都可以进行，服务器端不需要再存储客户端的状态信息，用户登录成功后，向服务器端发送的请求中携带服务器加密生成的token，服务器通过验证token的有效性来判断该请求的合法性。验证环节相较于传统的Session模式提升了网络流量的安全性，并且省去了不同服务器之间的认证信息交换。其中JWT验证方式更简洁且安全，它基于JSON格式数据采用加密算法进行签名。

由于JWT是带签名的token，其中包含的用户信息可以防篡改，在一定程度上可以作为可信来源。而JWT的负载中包括所有用户需要的信息，不再需要多次查询数据库，减轻了服务器的压力[8]。

2 安全数据传输的设计与实现

本文在对Spring Security框架、OAuth2.0协议以及JWT验证方式研究的基础上，实现了移动办税系统中的统一身份认证和用户对税务敏感数据的访问控制，保障了敏感数据在税务内外网之间传输的安全性。用户进行统一身份认证后，认证服务器根据不同用户的不同身份授予不同的访问操作权限，使他们能够进行相应授权的访问和操作。同时还在客户端请求中加入了时间戳为访问资源服务提供时间保障和确认机制。

2.1 Spring框架整合OAuth2.0

基于OAuth2.0协议的授权认证机制抽象了以下6个概念。一是第三方应用程序，即本文方案中的税务外网接口服务；二是HTTP服务提供商，即本文方案中的外网认证服务；三是资源所有者，即本文方案中的税务系统用户；四是用户代理，如浏览器；五是认证服务器，即本文方案中的外网认证服务器；六是资源服务器，即本文方案中的税务外网接口服务。

Spring Security框架提供了认证、授权以及防网络攻击等功能。在基于Servlet的网络应用中，Spring Security框架的核心思想是使用过滤链来对请求进行拦截并进行后续的认证和授权等操作。Spring Security框架对OAuth2.0协议进行了实现，主要包含认证服务器和资源服务器两大模块的实现。Spring Security OAuth2.0架构如图1所示。

图1 Spring Security OAuth2.0架构

由图1可知，认证服务器主要包含了四种授权模式的实现和token生成与存储，也可以使用JWT替换默认token，将token存储在第三方存储中。资源服务器主要是在Spring Security的过滤器链上添加了OAuth 2 Authentication Processing Filter过滤器，即使用OAuth2.0协议发放令牌认证的方式来保护敏感资源。

2.2 认证服务器的实现

2.2.1 身份认证完整流程

OAuth2.0协议包含授权服务和资源服务。授权服务包含对接入客户端和登入用户的合法性进行验证并颁发令牌的功能。资源服务包含对资源的保护功能，可以拦截非法请求并对请求中包含的token进行解析鉴权等。为了适应不同的应用场景，OAuth2.0协议提供了4种不同的授权模式，即授权码授权模式、隐式授权模式、用户密码授权模式以及客户端授权模式[9]。

在税务系统中，所有用户采用统一身份认证，使用用户密码模式进行授权，授权流程主要包括5步，抽象流程如图2所示。

图2 密码模式授权流程图

第一步，用户（资源拥有者）在客户端录入用户名和密码。

第二步，客户端使用用户提交的用户名和密码以及自己的私有证书向税务端(服务器)请求令牌，请求代码为/oauth/token?client_id=clientId & client_secret=clientSecret & grant_type=password & username=username & password=userPassword。其中，client_id表示客户端准入标识；client_secret表示客户端密钥；grant_type表示授权类型；password表示密码模式；username表示资源拥有者用户名；password表示资源拥有者密码。

第三步，授权服务器对客户端的私有证书以及用户提交的账号和密码进行验证，若验证通过，则向客户端发送访问令牌。一次性颁发两个令牌，一个用于获取数据，另一个用于获取新的令牌(refresh token字段)。令牌到期前，用户使用refresh token发送请求更新令牌。

第四步，客户端使用有效的访问令牌向资源服务器请求受保护的资源。

第五步，资源服务器调用授权服务的URL验证令牌有效性后对该请求做出响应。

由于税务敏感数据均存储在税务内网数据库中，因此为保障用户数据的安全性，本文在第三步过程中对客户端私有证书及用户的账号密码进行验证时对请求进行了进一步处理。用户在客户端提交用户名和密码后，开发者服务器在请求头的Authorization中加入使用AES加密算法生成的签名，签名内容为时间戳(选取当前时间，设置签名有效期为当前时间起十分钟)+@+验证字符串。税务内网对所有HTTP请求统一进行拦截，使用密钥解析请求头，验证该请求中是否携带签名、签名是否在有效期内以及签名是否有效，验证通过后为用户颁发令牌。

2.2.2 配置JWT令牌服务

Spring Security框架默认的令牌由UUID生成，可以使用JWT替换默认令牌，需要新建一个配置类，初始化JwtTokenStore对象，设置签名密钥，并在认证服务器的配置中替换默认的TokenStore。采用非对称加密算法生成JWT令牌，使用公钥/私钥对来对数据进行签名，防止被篡改。JWT令牌由头部、负载以及签名3部分构成，每部分中间使用英文中的点符号“.”分隔。使用OpenSSL库生成密钥证书，基于私钥生成JWT令牌，基于公钥解析JWT令牌。在认证服务器My Authorization Server Config类上，添加JWT的配置，定义JwtTokenStore，代码如下：

从认证服务器获取到令牌后需要将一些额外的敏感信息传输到资源服务器，可以通过拓展JWT令牌，在其中添加一些额外信息来实现。该过程使用token增强器Token Enhancer，然后在JWT配置中注册，最后在认证服务器的配置中配置该增强器即可。

2.3 资源服务器的实现

2.3.1 数据加密传输

用户携带有效令牌进行身份验证后，税务内网执行数据库查询操作，查询结果使用AES加密算法进行加密后再作为返回体发送给税务外网接口。税务外网接口将返回结果发送给开发者服务器。开发者服务器对返回结果进行解密，将敏感数据存入数据库，将最终结果和非敏感数据返回给客户端。该过程中除了使用JWT令牌对请求进行授权认证，数据本身也使用了AES加密算法进行处理，充分保障数据在内外网之间的传输安全。

AES算法使用分组密码，算法密钥长度可以为128位、192位或256位，明文数据分组长度为128位。加密过程对明文数据通过轮函数循环迭代，每一轮对轮函数的输入进行替换。本文提出的方案中使用128位密钥，加密迭代轮数为10，即每个明文分组会加密10轮。由于AES算法以字节为单位对数据进行处理，因此128位的输入明文分组P和输入密钥K都被分成16个字节。其中明文分组输入后转换为状态矩阵，即以字节为单位的正方形矩阵。状态矩阵的内容在算法加密处理的每一轮过程中不断更替迭代，最后的结果作为密文输出[10]。算法流程如图3所示。

图3 AES算法流程图

AES算法在对明文数据进行加密时需要进行密钥扩展，并传入密钥key的字符串表示。函数getWordFromStr()从字符串中读取4个字（16字节），读取后开始扩展密钥。在算法首尾使用轮密钥加，将当前分组和扩展密钥的一部分进行按位异或XOR，保障了算法的有效性和安全性。轮函数首先对每个字进行字循环，即一个字的4个字节循环左移1个字节，利用S盒(由16×16个字节组成的矩阵，包含了8位所能表示的256个数的一个置换）将输入字节的高4位作为行值，低4位作为列值，以这些数值为索引从S盒的对应位置取出元素作为输出，对输入字的每个字节进行字节代换。最后输出一个由44个字组成（176字节）的一维线性数组。通过convertToIntArray()函数将128位长度的字符串读进一个4×4的状态矩阵中。行移位即对状态矩阵每行进行左循环移位，列混合则是对状态矩阵进行混淆(即对状态矩阵使用定义在GF(28)上的加法和乘法进行运算)。在执行完10轮加密后，通过convertArrayToStr()函数将状态矩阵转换回字符串，再存入明文P的字符数组中。与之相反，数据解密则逆序调用各轮操作的逆函数。

2.3.2 访问控制模块

采用基于OAuth2.0协议的认证机制和Spring Security框架中提供的注解来实现用户对资源服务的访问控制，具体流程如图4所示，具体步骤包括9步。

图4 资源服务访问控制流程图

（1）客户端请求认证服务申请令牌；

（2）认证服务采用非对称加密算法，使用私钥生成JWT令牌；

院校在进行物流专业实践课程教学的时候应该积极的进行校企合作的方式进行校外实训基地的实践操作，为学生的实践创新平台。对于低年级的学生应该开展近距离的观摩机会，比如对设施设备的观摩以及对物流中心的参观等机会，能够帮助学生熟悉企业物流操作的实际环境，建立学习的氛围和信心。对于高年级的学生应该积极的开展实习机会，在实际操作中不断的提高自身的综合素质和专业技术水平，并且要做好实习报告的编写工作，提出作业流程和操作方法的不科学之处，做好相应的改进方案，才能够更好的帮助学生融入物流实践中，感悟企业文化，了解物流行业的实际情况，进而才能够调动学生的积极性和学习热情，提高学生的创新意识和解决实际问题的能力。

（3）客户端携带令牌访问资源服务，OAuth2.0协议使用token进行认证的机制会在每一次向服务器发起请求时都带上完成签名的token信息，客户端在HTTP请求的header中的Authorization字段携带此token；

（4）客户端通过GET或POST请求访问资源（访问页面或调用API）；

（5）认证服务作为一个Middleware HOOK对请求进行拦截，在HTTP Authorization Head中查找token信息；

（6）如果找到token信息，则根据配置文件中的签名加密秘钥，调用JWT Lib对token信息进行解密和解码；

（7）完成解码并验证签名通过后，对token中的exp（该JWT的到期时间）、nbf（一个时间点，在此时间点到达之前这个令牌是不可用的）以及aud（接收该JWT的终端信息）等信息进行验证；

（8）验证通过后，根据令牌中获取的用户的角色权限信息，对请求的资源的权限逻辑进行判断；

系统后端微服务端口则通过注解方式配置接口的访问控制，Spring Security框架基于注解的安全认证是通过在相关方法上进行安全注解标记来实现的。在实例中使用@Enable Global Method Security注解来判断用户对该控制层的所有方法是否具有访问权限，设置prePostEnabled为true，开启基于表达式的方法安全控制。通过表达式运算结果的布尔值来决定是否可以访问（true为开放，false为拒绝）。

3 方案安全性分析

本文的税务移动服务平台内、外网数据传输的安全解决方案可以有效解决税务移动服务平台面临的一系列安全问题，如CSRF攻击、重放攻击以及数据完整性鉴别问题。

3.1 CSRF攻击

传统cookie-session模式基于cookie进行用户识别，若cookie被截获，用户就会很容易受到跨站请求伪造的攻击。而使用token验证机制则不存在CSRF攻击问题。

3.2 重放攻击

指攻击者发送一个目的主机已接收过的包，来达到欺骗系统的目的，主要用于身份认证过程，破坏认证的正确性。本文方案在JWT令牌的payload部分中添加时间戳判断该请求是否重放攻击，提高了身份认证和数据传输的安全性。

3.3 数据完整性鉴别问题

本文基于OAuth2.0协议及JWT验证机制，在客户端请求中使用签名，其中的验证字符串和时间戳确保了数据在传输过程中的完整性和机密性。

4 结 论

基于OAuth2.0协议、Spring Security框架以及JWT令牌技术，结合互联网+税务服务平台，设计并实现了用于税务部门移动办税系统内、外网数据传输安全的解决方案，为保障税务部门服务信息化奠定了安全基础。系统使用结果表明，所设计的方案是一个安全可信、统一且完整的数据传输平台，可以有效保障移动办税系统中用户的身份认证、用户对受保护资源的访问控制及税务敏感数据传输的安全性。未来将针对OAuth2.0协议的优化及其与传统的身份认证技术相结合来提高协议的安全性，尝试使用生物识别、令牌融合等方法进一步完善丰富OAuth2.0协议的授权方式，从而保障移动办税平台身份认证及访问控制的安全性。