基于Token的身份認證在高校實訓互動平臺中的應用研究

鄒軍國

（滁州職業(yè)技術學院，安徽 滁州 239000）

加強實訓實踐教學是高職院校技能型人才培養(yǎng)的重要手段，目前各高職院校對實訓環(huán)節(jié)管理相對缺失或滯后，構(gòu)建一種實訓互動平臺迫在眉睫。隨著互聯(lián)網(wǎng)的快速發(fā)展，實訓互動平臺僅僅實現(xiàn)Web應用端已經(jīng)無法滿足用戶需求。我們還需要實現(xiàn)移動Web、微信小程序以及移動APP等多用戶端于一體的實訓交互平臺。在這些多用戶端的系統(tǒng)平臺中，傳統(tǒng)的Web應用所采用的將登錄信息存儲在Cookie，Session或者本地數(shù)據(jù)文件中實現(xiàn)用戶身份認證已經(jīng)無法滿足需求，并且這些方式還容易造成信息被截取等安全性問題。針對上述問題，我們在實訓互動平臺開發(fā)中采用Token（通常翻譯為令牌）的身份認證是一種比較安全的方式。用戶在登錄時，應用程序調(diào)用獲取令牌的接口，客戶端將用戶名和密碼以請求的方式提交給服務端程序與數(shù)據(jù)庫中用戶信息進行匹配，成功則生成令牌。在令牌中還可以包含如這個令牌屬于誰、這個令牌的有效期是多久、這個令牌當前登錄的客戶端類型以及設備ID等信息。在以后用戶使用過程中都通過令牌的方式請求數(shù)據(jù)和資源，系統(tǒng)根據(jù)令牌的有效性將有效的數(shù)據(jù)響應給用戶。

1 傳統(tǒng)Web身份認證技術

目前，絕大多數(shù)應用程序都是基于一種無狀態(tài)的HTTP協(xié)議互聯(lián)網(wǎng)應用，它不能存儲登錄用戶信息[1]。用戶在登錄使用用戶名和密碼輸入后驗證登錄，每次請求服務器上的應用程序的時候都需要將用戶名和密碼提交服務器進行認證后再響應數(shù)據(jù)給用戶，但是這些都可能對應用程序的安全性提出了挑戰(zhàn)。

隨著技術的發(fā)展，開發(fā)人員逐漸通過Cookie和Session這兩種技術就解決了HTTP的無狀態(tài)問題，可將用戶身份信息記錄在Cookie和Session中以解決身份認證問題。下面介紹一下這種身份認證模式的實現(xiàn)原理：用戶首先使用用戶名和密碼以及驗證碼等信息登錄，在登錄時創(chuàng)建一個Session對象并生成唯一ID，將其存儲在服務器端來記錄用戶登錄的身份信息，然后將sessionid返回并存儲在客戶端的Cookie中，這樣就在客戶端與服務器端之間開始了一次會話，直到關閉瀏覽器或者說是關閉整個應用程序后會話才結(jié)束。在會話有效期內(nèi)每次客戶端向服務器端請求數(shù)據(jù)的時候就將在客戶端使用Cookie存儲的sessionid發(fā)送到服務器端，服務器端根據(jù)sessionid與服務器端存儲的Session中的ID進行比較，如果一致則響應用戶請求并返回數(shù)據(jù)，否則通知用戶未通過身份認證無權(quán)訪問資源。為了安全我們還可以將客戶端IP地址和系統(tǒng)生成的隨機碼存儲在Cookie和Session中，在用戶請求服務器進行身份認證時可通過比對IP和隨機碼來增強系統(tǒng)的安全性。當然也可以使用RSA等加密算法來對存儲的信息進行加密，確保系統(tǒng)安全。

上述采用Cookie和Session的會話模式確實解決了身份認證問題，但是這種模式依然存在很多問題，并且隨著科技的發(fā)展和人們對用戶體驗的需求，一個企業(yè)級應用程序不僅僅包括PC端的桌面程序和Web程序，還必須提供手機APP和WAP端等。這些都對原來的身份認證模式提出了挑戰(zhàn)，也暴露出很多缺點，具體分析如下。（1）Session：每次認證用戶發(fā)起請求時，服務器需要去創(chuàng)建一個記錄來存儲信息。當越來越多的用戶發(fā)請求時，內(nèi)存的開銷也會不斷增加。（2）可擴展性：在服務端的內(nèi)存中使用Session存儲登錄信息，伴隨而來的是可擴展性問題[2]。（3）跨域資源共享（Cross-Origin Resource Sharing，CORS），當我們需要讓數(shù)據(jù)跨多臺移動設備上使用時，跨域資源的共享會是一個讓人頭疼的問題。在使用Ajax抓取另一個域的資源，就會出現(xiàn)禁止請求資源情況。（4）跨站請求偽造（Cross Site request forgery，CSRF），如果用戶在訪問系統(tǒng)時，其他用戶很容易偽造請求致使系統(tǒng)收到跨站請求偽造的攻擊。在這些問題中，可擴展性是最突出的。因此我們有必要去尋求一種更有行之有效的方法[3]。

2 基于Token的身份認證原理

高校實訓互動平臺是集Web端、移動Web端、微信小程序和移動APP端等于一體的多用戶端系統(tǒng)，為了滿足需求并解決Cookie和Session會話模式的身份認證的不足，我們尋找一種新的身份認證模式即Token身份認證模型，就如古時候有些軍隊里傳令官手持將軍的令牌去調(diào)動部隊一樣，采用這種令牌的機制去處理身份認證問題。

基于Token身份認證技術就無須在客戶端或服務端存儲大量用戶名密碼等信息。不僅解決了有關敏感用戶信息存儲的問題，也解決了Session認證所造成的過多占用服務端內(nèi)存資源的問題，而且服務端無需考慮用戶是否已登錄[4]。下面具體介紹以下基于Token的身份認證過程：（1）用戶可使用不同客戶端輸入用戶名和密碼并發(fā)送請求到服務端。（2）服務端接收請求后查詢數(shù)據(jù)庫中用戶信息并驗證請求中的用戶名和密碼合法性。（3）驗證通過后，服務端使用加密算法簽發(fā)令牌，再將令牌響應給客戶端。（4）客戶端接收令牌后將它存儲在客戶端，在H5規(guī)范中可存儲Cookie或Local Storage對象中，而在Android系統(tǒng)中也可存儲Share Preference對象中。（5）之后客戶端每次請求服務端資源時都須帶著服簽發(fā)的加密令牌，驗證令牌的合法性，如果成功，根據(jù)用戶權(quán)限向客戶端響應數(shù)據(jù)。

每次發(fā)送請求時都需要將Token放在HTTP頭部發(fā)送到服務端，以保證HTTP請求無狀態(tài)。通過設置服務器屬性Access-Control-Allow-Origin:*，讓服務器能接受到來自所有域的請求[5]。需要注意的是，在ACAO頭部標明(designating)*時，不得帶有像HTTP認證，客戶端SSL證書和cookies的證書。

3 實訓互動平臺身份認證解決方案

設計與開發(fā)高校實訓互動平臺項目中，我們搭建了一個輕量級微服務架構(gòu)，使用Spring Boot作為微服務開發(fā)框架，使用zookeeper來注冊微服務，通過Node.js將請求轉(zhuǎn)發(fā)到Tomcat上，從而實現(xiàn)“反向代理”。該平臺分為后端和前端兩個部分，后端主要包括后臺管理端和Restful服務端，前端主要包括PC端Web程序、Android端APP、iOS端APP以及微信小程序等多種客戶端。在這些不同程序之間必須建立統(tǒng)一的身份認證系統(tǒng)。下面著重介紹在實訓互動平臺的身份認證系統(tǒng)中核心部分如何設計實現(xiàn)。

3.1 令牌設計

高校實訓互動平臺的身份認證采用的是基于Token的身份認證，顯然Token（令牌）如何設計是整個身份認證系統(tǒng)中最重要的環(huán)節(jié)，針對高校實訓互動平臺需求的特點對Token進行了詳細規(guī)劃和設計，具體令牌構(gòu)成主要包括用戶名、用戶ID、登錄客戶端類型、時間戳和過期時間等相關信息。項目中我們將用戶名、用戶ID和登錄客戶端類型等信息作為令牌的用戶基本信息部分，將時間戳和令牌過期時間作為隨機信息部分。首先我們介紹一下用戶基本信息部分的具體格式，將信息以JSON的格式組合起來，再使用BASE64編碼進行加密和解密。具體格式舉例如下：

以上面格式構(gòu)成用戶基本信息為例，首先將JSON數(shù)據(jù)格式轉(zhuǎn)換為字符串數(shù)據(jù)后使用base64編碼進行加密，加密后結(jié)果如下：

與用戶基本信息相比，隨機信息主要是用于增加令牌的隨機性和提高安全性。隨機信息部分主要由時間戳和過期時間組成，用戶在客戶端使用用戶名和密碼進行第一次登錄時，需驗證一下請求參數(shù)中的時間戳與被請求服務器的時間是否一致，誤差我們設定在保持合理范圍內(nèi)即可，一般為5 min，驗證是否匹配，匹配則說明是合理登錄。之后我們將時間戳和過期時間使用HS256算法進行加密，具體隨機信息格式如下：

接下來將隨機信息轉(zhuǎn)換為字符串格式后使用HS256算法進行加密，加密結(jié)果如下：

上面也說了令牌主要是由用戶基本信息和隨機信息兩部分組成，這兩部分信息中間使用“.”隔開，最后得出上述例子的令牌如下：

這些令牌由服務端身份認證服務生成，響應到客戶端使用Cookies存儲在客戶端。對于整個身份認證過程最重要的主要是登錄和請求服務端資源的過程，下面對這兩個過程進行說明。

3.2 登錄過程

在高校實訓互動平臺中設定了部門實訓管理員、學校實訓管理員、校內(nèi)實訓指導教師、校外實訓指導教師和學生等角色。不同角色擁有不同的權(quán)限，通過客戶端登錄后才能請求到服務端相應資源。用戶登錄是基于令牌身份認證的核心功能。具體登錄過程時序如圖1所示。

高校互動實訓平臺中基于令牌登錄過程如下：第一次登錄時，用戶通過客戶端輸入用戶名和密碼通過POST請求發(fā)送到登錄控制器（即Login Controller）；登錄控制器調(diào)用認證服務，認證服務通過用戶信息服務獲取用戶信息并驗證用戶名和密碼準確性，如果驗證通過則生產(chǎn)令牌，具體令牌格式已經(jīng)在令牌設計小節(jié)中做了詳細描述；認證服務將驗證結(jié)果返回給登錄控制器，登錄控制器將令牌設置到響應對象中返回給客戶端；客戶端通過本地存儲技術將令牌存儲在本地，以便于請求服務端資源時使用。

3.3 請求資源過程

客戶端與服務端交互主要是通過HTTP請求實現(xiàn)的，在HTTP請求中核心部分就是請求資源過程，也是用戶與服務端數(shù)據(jù)交互過程。每次客戶端提交給服務端的請求都需要經(jīng)過認證服務進行身份合法性認證之后才能響應相應資源給用戶。具體基于令牌的請求資源過程時序如圖2所示。

圖1 登錄過程時序

圖2 請求資源過程時序

在高校實訓互動平臺中請求資源具體過程如下：用戶請求任何資源時首先將請求提交給對應的資源控制器，再調(diào)用身份認證服務進行身份認證；認證服務通過請求對象查找到請求對象中的令牌信息，再驗證令牌的合法性并進行角色判斷；確認了令牌合法性和對應角色之后再請求對應的資源服務獲取用戶所需資源，并返回結(jié)果給資源控制器，再響應給用戶。

4 基于令牌認證方案的優(yōu)勢

基于Token身份認證模式與之前描述的傳統(tǒng)身份認證技術進行比較。首先，采用Token認證模式進行用戶認證，則用戶信息不用存儲在Session中即使用戶量大時也不會造成擁堵。其次，當用戶請求資源時發(fā)送的是令牌而不是Cookie中存儲的用戶名和密碼這樣敏感信息，從而有效防止CSRF[6]。再次，在可擴展性方面Token能夠創(chuàng)建與其他應用共享權(quán)限的程序。能通過一個帳號將所有應用程序關聯(lián)起來，實現(xiàn)單點登錄，登錄成功后即可使用該應用程序的部分功能。最后，在多平臺跨域方面，也就是CORS問題，對應用程序和服務進行擴展的時候，可以加入各種設備和應用程序。只要用戶有一個通過了驗證的Token，數(shù)據(jù)和資源就能夠在任何域上被請求到。正因為這些優(yōu)勢我們在跨平臺開發(fā)中選用Token去解決身份認證問題。

5 結(jié)語

本文通過介紹傳統(tǒng)Web認證技術基礎上描述基于Token的身份認證模式的原理，從而著重介紹了高校實訓互動平臺中多客戶端身份認證解決方案。借助令牌設計、登錄過程設計和請求資源過程設計3個方面闡述了在實訓互動平臺中是如何解決身份認證問題，該解決方案對其他多客戶端平臺開發(fā)也有非常寶貴的借鑒意義。