基于令牌認(rèn)證方案的改進(jìn)研究與實(shí)踐
2021-04-18 23:45胡獻(xiàn)宇
軟件工程 2021年4期
摘? 要：就前后端分離的軟件開(kāi)發(fā)模式而言，保護(hù)后端數(shù)據(jù)接口不被非法調(diào)用是十分重要的。令牌作為獲取保護(hù)資源的憑證，需要提供過(guò)期時(shí)間，否則認(rèn)證功能就失去了意義。針對(duì)活躍用戶(hù)，需要在有效時(shí)間內(nèi)提供自動(dòng)登錄功能，可以提升使用體驗(yàn)。本文研究了OAuth（Open Authorization，一種開(kāi)放的授權(quán)標(biāo)準(zhǔn)）的認(rèn)證機(jī)制，并在ASP.NET Web API框架基礎(chǔ)上，實(shí)現(xiàn)身份認(rèn)證方案，當(dāng)訪問(wèn)令牌過(guò)期后，增加令牌刷新機(jī)制，既能夠改善用戶(hù)體驗(yàn)，也能夠有效保護(hù)數(shù)據(jù)接口。該方案具有通用性，適用于前后端分離的軟件開(kāi)發(fā)。通過(guò)測(cè)試，表明了該方案具有有效性和可行性。
關(guān)鍵詞：OAuth;身份驗(yàn)證和授權(quán);前后端分離;刷新
中圖分類(lèi)號(hào)：TP311.11? ? ?文獻(xiàn)標(biāo)識(shí)碼：A
文章編號(hào)：2096-1472（2021）-04-34-05
Abstract： For software development model that separates front and back ends， it is very important to protect back-end data interface from being illegally invoked. The token， as a voucher for obtaining protected resources， needs to provide an expiration time， otherwise authentication function will lose its meaning. For active users， automatic login function needs to be provided within valid time to improve user experience. This paper proposes to implement an identity authentication scheme based on the ASP.NET Web API framework after studying an authentication mechanism of OAuth （Open Authorization， an open authorization standard）. When the access token expires， token refresh mechanism is added， which can not only improve user experience， but also effectively protect data interfaces. The proposed scheme is versatile and suitable for software development with separation of front and back ends. Tests show its effectiveness and feasibility.
Keywords： OAuth; authentication and authorization; separation of front and back ends; refresh
1? ?引言（Introduction）
隨著Web應(yīng)用的快速發(fā)展，前后端分離的開(kāi)發(fā)方式成為主流趨勢(shì)。圖1是一種主流的前后端分離的交互模型，使用前按需設(shè)計(jì)數(shù)據(jù)接口，后端（主要是指服務(wù)器端）可以為前端（主要是指PC端平臺(tái)、APP及各類(lèi)小程序）提供HTTP（Hyper Text Transfer Protocol， 超文本傳輸協(xié)議）服務(wù)，而不需要關(guān)注業(yè)務(wù)的詳細(xì)展示[1]。此外，前端主要負(fù)責(zé)接收和組織展示后端傳過(guò)來(lái)的數(shù)據(jù)，根據(jù)具體的業(yè)務(wù)進(jìn)行頁(yè)面邏輯的設(shè)計(jì)。這種前后端交互模型結(jié)構(gòu)簡(jiǎn)潔，方便前后端開(kāi)發(fā)者關(guān)注自己的業(yè)務(wù)，降低了前后端的耦合性，可成功解耦，為后續(xù)開(kāi)發(fā)工作打下了堅(jiān)實(shí)的基礎(chǔ)。
然而，使用前后端分離的軟件開(kāi)發(fā)模式，需要關(guān)注后端數(shù)據(jù)接口的安全性，保護(hù)接口不被非法調(diào)用。針對(duì)這種情況，本文實(shí)現(xiàn)了基于OAuth（Open Authorization，一種開(kāi)放的授權(quán)標(biāo)準(zhǔn)）2.0的身份驗(yàn)證和授權(quán)方案，一方面能夠保護(hù)接口的安全性;另一方面，能夠在令牌過(guò)期之后實(shí)現(xiàn)刷新機(jī)制，改善用戶(hù)體驗(yàn)，并通過(guò)Postman工具進(jìn)行完整測(cè)試，表明方案的可行性。
2 身份驗(yàn)證與授權(quán)（Authentication and authorization）
2.1? ?身份驗(yàn)證
身份驗(yàn)證是驗(yàn)證一個(gè)系統(tǒng)實(shí)體或系統(tǒng)資源具有某種屬性值的過(guò)程。對(duì)于HTTP而言，客戶(hù)端和服務(wù)器端是兩個(gè)獨(dú)立的系統(tǒng)實(shí)體，因此，需要從兩個(gè)方面去考慮。一方面，若想實(shí)現(xiàn)服務(wù)器端的身份驗(yàn)證，就得需要向客戶(hù)端保證，請(qǐng)求消息只會(huì)發(fā)送給正確的源服務(wù)器，在這種情況下，消息的發(fā)送者需要在發(fā)送消息之前核實(shí)消息的接收者，通常是認(rèn)證傳輸連接的另一端。另一方面，若想實(shí)現(xiàn)客戶(hù)端的身份驗(yàn)證，就得需要客戶(hù)端向服務(wù)器端發(fā)送驗(yàn)證請(qǐng)求，即判斷請(qǐng)求消息是否應(yīng)該得到授權(quán)[2]。常用的身份驗(yàn)證包含基于密碼的HTTP基礎(chǔ)身份驗(yàn)證和基于令牌的身份驗(yàn)證。
2.1.1? ?基于密碼的HTTP基礎(chǔ)身份驗(yàn)證
基于密碼的HTTP基礎(chǔ)身份驗(yàn)證，就是將用戶(hù)名和密碼信息進(jìn)行加密處理，生成Ticket（票據(jù)），客戶(hù)端請(qǐng)求的時(shí)候需要校驗(yàn)Ticket[3]，主要步驟如下：
（1）使用冒號(hào)作為分隔符，連接用戶(hù)名和對(duì)應(yīng)的密碼，使用Base64對(duì)連接字符串進(jìn)行加密處理。
（2）將加密之后的字符串放在Authorization標(biāo)頭的方案標(biāo)識(shí)符Basic之后。
（3）若通過(guò)后臺(tái)校驗(yàn)，客戶(hù)端將會(huì)接收Ticket，并保存為驗(yàn)證信息，之后的每一次請(qǐng)求都需要攜帶，以方便服務(wù)器進(jìn)行驗(yàn)證。驗(yàn)證成功，則獲取相關(guān)信息，否則返回未通過(guò)的提示信息。
2.1.2? ?基于令牌的身份驗(yàn)證
基于令牌的身份驗(yàn)證，就是使用安全令牌進(jìn)行驗(yàn)證。安全令牌是指用于在身份驗(yàn)證過(guò)程中驗(yàn)證用戶(hù)標(biāo)識(shí)的數(shù)據(jù)對(duì)象[4]。我們?cè)赪eb應(yīng)用程序中使用的身份驗(yàn)證Cookie，就是基于令牌的身份驗(yàn)證，其流程如下：
（1）使用密碼進(jìn)行初始認(rèn)證操作，之后會(huì)生成一個(gè)Cookie，將其返回給客戶(hù)端。
（2）客戶(hù)端之后發(fā)出的每個(gè)請(qǐng)求，都通過(guò)這個(gè)Cookie進(jìn)行身份驗(yàn)證，不再需要初始的身份信息。
2.1.3? ?身份驗(yàn)證小結(jié)
基于密碼的HTTP基礎(chǔ)身份驗(yàn)證方法存在如下一些問(wèn)題：
（1）客戶(hù)端必須保存密碼，同時(shí)，由于密碼采用明文保存，或使用一種可逆的保存方式，增加了密碼泄露的風(fēng)險(xiǎn)。
（2）服務(wù)器對(duì)每個(gè)請(qǐng)求都進(jìn)行密碼驗(yàn)證，會(huì)增加很多開(kāi)銷(xiāo)，影響效率。
（3）為防御字典攻擊而使用相關(guān)技術(shù)，會(huì)導(dǎo)致驗(yàn)證過(guò)程計(jì)算開(kāi)銷(xiāo)較大。
（4）不適合分布式應(yīng)用。分布式系統(tǒng)中，身份驗(yàn)證通常委托給外部系統(tǒng)。
基于如上考慮，本方案將使用基于令牌的認(rèn)證方案。
2.2? ?授權(quán)
2.2.1? ?授權(quán)簡(jiǎn)介
授權(quán)，可以理解為控制主體對(duì)受保護(hù)資源進(jìn)行相應(yīng)的操作[5]。通常來(lái)說(shuō)，授權(quán)問(wèn)題的核心主要是主體、操作和資源三者的關(guān)系，即主體是否可以操作資源[6]，如圖2所示。
在Web API中，對(duì)于授權(quán)我們可以有如下理解：
（1）資源，指HTTP資源，而HTTP資源是請(qǐng)求消息要訪問(wèn)的資源。
（2）操作，指HTTP方法，包括GET請(qǐng)求、POST請(qǐng)求等。
（3）主體，指執(zhí)行HTTP請(qǐng)求的HTTP客戶(hù)端。
2.2.2? ?OAuth 2.0簡(jiǎn)介
OAuth 2.0是OAuth 1.0協(xié)議的升級(jí)版本[6]，它的主要目標(biāo)是讓客戶(hù)端的開(kāi)發(fā)工作變得簡(jiǎn)單與便捷，為Web應(yīng)用程序、手機(jī)APP、桌面軟件等提供特定的授權(quán)方式。OAuth 2.0允許第三方應(yīng)用程序獲得HTTP服務(wù)的訪問(wèn)權(quán)限，同時(shí)，可以通過(guò)HTTP服務(wù)提供方授權(quán)資源擁有者，允許第三方應(yīng)用程序憑借自己的客戶(hù)端憑證獲取在資源服務(wù)器上的受保護(hù)資源的訪問(wèn)權(quán)限。
在OAuth 2.0中，定義了授權(quán)碼模式、簡(jiǎn)化模式、密碼模式和客戶(hù)端模式四種授權(quán)方式[7]，綜合考慮本方案的需求，決定采用密碼模式。密碼模式的流程如圖3所示。
這種模式的流程如下：
（1）用戶(hù)通過(guò)提供賬號(hào)和密碼來(lái)使用客戶(hù)端。
（2）客戶(hù)端將賬號(hào)和密碼發(fā)送給認(rèn)證服務(wù)器，即請(qǐng)求token。
（3）通過(guò)認(rèn)證服務(wù)器驗(yàn)證，將會(huì)向客戶(hù)端提供訪問(wèn)token。
（4）客戶(hù)端使用token向資源服務(wù)器請(qǐng)求資源。
3 身份驗(yàn)證和授權(quán)方案的設(shè)計(jì)與實(shí)現(xiàn)（Design and implementation of identity verification and authorization scheme）
3.1? ?身份驗(yàn)證和授權(quán)方案的設(shè)計(jì)
在ASP.NET Web API框架上，使用微軟開(kāi)發(fā)的基于OWIN規(guī)范的Katana項(xiàng)目中的中間件，能夠很方便地完成基于OAuth 2.0的身份驗(yàn)證和授權(quán)。雖然OAuth 2.0關(guān)注的主要內(nèi)容是授權(quán)，但是在該中間件中OAuth 2.0可以提供基于令牌的身份驗(yàn)證功能[8]，其處理訪問(wèn)令牌的流程如圖4所示。
（1）獲取令牌。如果HTTP請(qǐng)求存在Bearer的Authorization標(biāo)頭，那么將該標(biāo)頭作為訪問(wèn)令牌，否則身份驗(yàn)證方法不返回任何身份信息。
（2）獲取身份認(rèn)證票據(jù)。解析訪問(wèn)令牌，可以獲取身份驗(yàn)證票據(jù)信息以及屬性信息。
（3）驗(yàn)證身份票據(jù)，并檢查其有效性。
3.2? ?身份驗(yàn)證和授權(quán)方案的實(shí)現(xiàn)
（1）使用Postman發(fā)送仿真模擬請(qǐng)求，并嘗試使用GET方式訪問(wèn)已有的數(shù)據(jù)接口，其結(jié)果如圖5所示。此時(shí)，我們是在沒(méi)有限制的情況下獲取相關(guān)數(shù)據(jù)信息。對(duì)于我們的方法，如果不加以限制，那么任何客戶(hù)端都可無(wú)條件訪問(wèn)我們的接口獲取數(shù)據(jù)，這樣是不安全的，必須對(duì)接口進(jìn)行限制，只有通過(guò)驗(yàn)證的用戶(hù)才可以獲取數(shù)據(jù)信息。
（2）在項(xiàng)目中，新建一個(gè)MyAuthorizationServerProvider
類(lèi)，用于實(shí)現(xiàn)身份驗(yàn)證，并且重寫(xiě)ValidateClientAuthentication
方法和GrantResourceOwnerCredentials方法。
關(guān)鍵代碼如下：
public class MyAuthorizationServerProvider ：
OAuthAuthorizationServerProvider
{
public override Task ValidateClientAuthentication（
OAuthValidateClientAuthenticationContext context）
{
context.Validated（）;
return Task.FromResult
}
public override async Task GrantResourceOwner
Credentials（
OAuthGrantResourceOwnerCredentialsContext context）
{
context.OwinContext.Response.Headers.
Add（"Access-Control-Allow-Origin"， new[] { "*" }）;
AccountService accService = new AccountService（）;
string md5Pwd = LoginHelperMD5CryptoPasswd
（context.Password）;
IList
if （ul.Count（） == 0）
{
context.SetError（"授權(quán)無(wú)效"， "用戶(hù)名或密碼錯(cuò)誤！"）;
return;
}
var identity = new
ClaimsIdentity（context.Options.AuthenticationType）;
context.Validated（identity）;
}
}
為上述數(shù)據(jù)接口添加Authorize標(biāo)簽，達(dá)到過(guò)濾的目的，進(jìn)而實(shí)現(xiàn)對(duì)接口的保護(hù)。此時(shí)，我們?cè)俅问褂肞ostman進(jìn)行仿真請(qǐng)求，嘗試請(qǐng)求接口，返回信息如圖6所示，即顯示已拒絕為該請(qǐng)求授權(quán)。
（3）當(dāng)前接口已經(jīng)被保護(hù)了，我們?cè)谠L問(wèn)接口的時(shí)候，就得通過(guò)Access_token。因此，我們必須拿到Access_token的值，其獲取方法如下：發(fā)送POST請(qǐng)求，訪問(wèn)token的URL;發(fā)送請(qǐng)求之前，在Body內(nèi)添加grant_type、username、password這三個(gè)參數(shù)，由于我們采用密碼模式進(jìn)行授權(quán)，因此，grant_type的參數(shù)是password，如圖7所示，我們發(fā)送一個(gè)POST請(qǐng)求之后，響應(yīng)的信息包含access_token、token_type等值，響應(yīng)詳情如圖8所示。
（4）我們重新訪問(wèn)受限的接口，在發(fā)送GET請(qǐng)求的時(shí)候，如圖9所示。在請(qǐng)求的標(biāo)頭里將Authorization設(shè)置為KEY，此時(shí)需要使用上一步獲取到的Access_token，將其作為VALUE參數(shù)的一部分。最終，VALUE對(duì)應(yīng)的值應(yīng)該為Bearer+access_token，如圖9所示，我們能夠順利獲取到數(shù)據(jù)信息。這種情況下，15分鐘內(nèi)客戶(hù)端在訪問(wèn)服務(wù)器端的時(shí)候，無(wú)須進(jìn)行驗(yàn)證就可使用該token訪問(wèn)受保護(hù)的資源。
（5）當(dāng)Access_token的值失效時(shí)，我們就需要重新獲取新的令牌值。此時(shí)，我們需要在項(xiàng)目目錄中新建一個(gè)MyRefreshTokenProvider類(lèi)，用于令牌到期之前進(jìn)行刷新，以便獲取新的令牌，并重寫(xiě)Create方法和Receive方法，代碼如下：
public class MyRefreshTokenProvider ： Authentication
TokenProvider
{
private static ConcurrentDictionary
//用于生成refresh_token
public override void Create（AuthenticationToken
CreateContext context）
{
context.Ticket.Properties.IssuedUtc = DateTime.UtcNow;
context.Ticket.Properties.ExpiresUtc = DateTime.UtcNow.AddDays（60）;
context.SetToken（Guid.NewGuid（）.ToString（"n"））;
_refreshTokens[context.Token] = context.SerializeTicket（）;
}
//由 refresh_token 解析成 access_token
public override void Receive（AuthenticationTokenReceiveContext context）
{
string value;
if （_refreshTokens.TryRemove（context.Token， out value））
{
context.DeserializeTicket（value）;
}
}
}
（6）修改好相關(guān)代碼之后，我們需要按照第（4）步的方式重新獲取Token，因?yàn)檫@次獲取數(shù)據(jù)的時(shí)候，會(huì)額外獲取到Refresh_token的值，如圖10所示，該值將用于重新獲取新的令牌，而不需要重新使用密碼的授權(quán)方式獲取。
（7）當(dāng)Token過(guò)期后，我們需要使用上次得到的Refresh_token重新獲取令牌，即發(fā)送POST請(qǐng)求訪問(wèn)獲取令牌的URL。發(fā)送請(qǐng)求的時(shí)候，需要在Body內(nèi)添加grant_type、refresh_token這兩個(gè)參數(shù)，由于本次需要使用刷新令牌的方式獲取新的令牌，因此Grant_type的值為Refresh_token，而Refresh_token的值就是我們?cè)诘谝淮潍@取令牌的時(shí)候里面的Refresh_token，如圖11所示。
只要在客戶(hù)端進(jìn)行相關(guān)設(shè)置，即可實(shí)現(xiàn)在不影響用戶(hù)操作體驗(yàn)的情況下動(dòng)態(tài)延長(zhǎng)token有效期限，有效地解決了token失效問(wèn)題。
4? ?結(jié)論（Conclusion）
本文通過(guò)研究身份驗(yàn)證和授權(quán)的機(jī)制，改進(jìn)了基于令牌的認(rèn)證方案，增加刷新令牌，能夠在訪問(wèn)令牌過(guò)期之后，使用刷新令牌實(shí)現(xiàn)自動(dòng)登錄和授權(quán)，不僅提升了用戶(hù)體驗(yàn)，還能有效地保護(hù)后端數(shù)據(jù)接口的安全性;并使用Postman進(jìn)行接口測(cè)試，驗(yàn)證了方案的可行性，為前后端分離的身份驗(yàn)證和授權(quán)提供了有效解決方案。
參考文獻(xiàn)（References）
[1] 程冬梅，王瑞聰，劉燕，等.基于REST架構(gòu)風(fēng)格的物聯(lián)網(wǎng)服務(wù)平臺(tái)研發(fā)[J].計(jì)算機(jī)工程與應(yīng)用，2012，48（14）：74-78.
[2] 劉文元.基于ASP.NET Web API的摘要身份驗(yàn)證改進(jìn)算法[J].電腦迷，2017（4）：56.
[3] GLENN B.ASP.NET Web API設(shè)計(jì)[M].北京：人民郵電出版社，2015：331-333.
[4] 蔣金楠.ASP.NET Web API2框架揭秘[M].北京：電子工業(yè)出版社，2014：591-594.
[5] 王仲洲，楊曉洪，王劍平，等.基于REST風(fēng)格的WEB API架構(gòu)研究[J].微處理機(jī)，2016，37（5）：52-55.
[6] 沈海波，陳強(qiáng)，陳勇昌.基于OAuth 2.0擴(kuò)展的客戶(hù)端認(rèn)證方案[J].計(jì)算機(jī)工程與設(shè)計(jì)，2017，38（2）：350-354.
[7] 王婷婷，趙松澤.基于OAuth 2.0協(xié)議的安全授權(quán)模型研究[J].軟件工程，2017，20（01）：55-59.
[8] DAVIS J， RAJASREE M S. A framework for the description， discovery and composition of RESTful semantic web services[C]. Computational Science， Engineering and Information Technology， 2012：88-93.
作者簡(jiǎn)介：
胡獻(xiàn)宇（1994-），男，碩士，講師.研究領(lǐng)域：軟件開(kāi)發(fā).
- 軟件工程的其它文章
- 基于云平臺(tái)的物聯(lián)網(wǎng)停車(chē)場(chǎng)管理系統(tǒng)設(shè)計(jì)
- 航運(yùn)業(yè)未完航次利潤(rùn)核算平臺(tái)的設(shè)計(jì)與實(shí)現(xiàn)
- 基于Prometheus的油田數(shù)據(jù)泄漏防護(hù)大數(shù)據(jù)系統(tǒng)運(yùn)維方法
- 新型互聯(lián)網(wǎng)技術(shù)與跨境電商平臺(tái)生態(tài)系統(tǒng)的演化研究
- 一種多源統(tǒng)一爬蟲(chóng)框架的設(shè)計(jì)與實(shí)現(xiàn)
- 基于云平臺(tái)的智能語(yǔ)音交互機(jī)器人設(shè)計(jì)