基于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協議的授權方式，從而保障移動辦稅平臺身份認證及訪問控制的安全性。