吳 德,應(yīng) 毅,毛道鶴
?
基于OAuth2.0的認(rèn)證授權(quán)方案設(shè)計(jì)與優(yōu)化
吳 德,應(yīng) 毅,毛道鶴
(三江學(xué)院 計(jì)算機(jī)科學(xué)與工程學(xué)院,江蘇 南京 210012)
OAuth 2.0是由互聯(lián)網(wǎng)工程任務(wù)組于2012年10月發(fā)表在RFC-6749規(guī)范文檔中定義的認(rèn)證授權(quán)協(xié)議,是一種基于HTTP重定向?qū)崿F(xiàn)的開放授權(quán)框架。它允許第三方應(yīng)用訪問該用戶在某一網(wǎng)站上存儲(chǔ)的特定資源,而無需將用戶名和密碼提供給第三方應(yīng)用,大幅提升用戶的WEB應(yīng)用體驗(yàn)。為深入研究OAuth 2.0協(xié)議的工作原理,使用Nginx 服務(wù)器、MySQL和Redis數(shù)據(jù)庫設(shè)計(jì)了一個(gè)開放授權(quán)應(yīng)用框架,同時(shí)指出OAuth 2.0協(xié)議應(yīng)用在授權(quán)流程中的不足之處,并給出基于WebSocket監(jiān)聽機(jī)制的優(yōu)化解決方案,為認(rèn)證授權(quán)應(yīng)用的開發(fā)提供參考。
RFC-6479;OAuth 2.0;認(rèn)證;授權(quán)
OAuth協(xié)議為用戶資源的授權(quán)提供了一個(gè)安全、開放而又簡易的標(biāo)準(zhǔn)。OAuth的授權(quán)使得第三方應(yīng)用無需使用用戶的用戶名與密碼就可以申請獲得該用戶資源的授權(quán)[1]。
OAuth 2.0協(xié)議于2012年10月正式發(fā)布,作為OAuth 1.0的升級版本卻并不向下兼容OAuth 1.0協(xié)議[2]。OAuth 2.0協(xié)議更加關(guān)注客戶端開發(fā)的簡易性,同時(shí)為移動(dòng)設(shè)備、Web應(yīng)用、桌面應(yīng)用等多種客戶端提供認(rèn)證授權(quán)服務(wù)[3]。
目前,國內(nèi)外各大主流互聯(lián)網(wǎng)公司如騰訊、新浪、豆瓣、Facebook、Google等均已支持OAuth 2.0協(xié)議[4-6]。通過在其開發(fā)者平臺(tái)上提供基于OAuth 2.0的開放授權(quán) OpenAPI,由客戶端開發(fā)者調(diào)用,便可以向市場上的其它中小型應(yīng)用分享其海量的用戶數(shù)據(jù)。通過這種方式,不同廠家不同類型的應(yīng)用只要遵循OAuth 2.0協(xié)議流程,就可以引入各大主流網(wǎng)站的用戶資源,簡化登錄流程,優(yōu)化用戶體驗(yàn),從而提高應(yīng)用的可用性和用戶的活躍度。
OAuth 2.0授權(quán)框架允許第三方應(yīng)用代表資源所有者通過合法地協(xié)調(diào)資源所有者和HTTP服務(wù)之間交互,或者僅代表第三方應(yīng)用本身,對Web服務(wù)進(jìn)行有限地訪問。該協(xié)議允許用戶通過授權(quán)的方式讓第三方應(yīng)用訪問該用戶在某一網(wǎng)站上存儲(chǔ)的私密資源(如照片,視頻,聯(lián)系人列表),而無需將用戶名和密碼提供給第三方應(yīng)用[7]。
OAuth 2.0協(xié)議使得用戶通過令牌(而不是用戶名和密碼)來有限地訪問存儲(chǔ)在特定服務(wù)提供者那里的數(shù)據(jù)。每一個(gè)令牌授權(quán)一個(gè)特定的網(wǎng)站在特定的時(shí)段(例如,接下來的120分鐘內(nèi))內(nèi)訪問特定的資源(例如僅限于某一相冊中的照片)。
OAuth 2.0協(xié)議定義了四個(gè)角色,分別是:
(1)Resource Owner:資源所有者,是一個(gè)能授予訪問受保護(hù)資源權(quán)限的實(shí)體。當(dāng)資源所有者是人類的時(shí)候,它被稱為終端的用戶。
(2)Resource Server:資源服務(wù)器,是一個(gè)托管了受保護(hù)資源,能接收和響應(yīng)使用訪問令牌訪問受保護(hù)資源請求的服務(wù)器。
(3)Client:客戶端,是代表 Resource Owner,使用其授權(quán)許可獲取受保護(hù)資源的第三方應(yīng)用。服務(wù)端程序或桌面應(yīng)用或移動(dòng)設(shè)備,都可以是OAuth 2.0協(xié)議流程中的客戶端。
(4)Authorization Server:授權(quán)服務(wù)器,是指在 Client認(rèn)證成功,并獲取了 Resource Owner 的授權(quán)之后,頒發(fā)訪問令牌給 Client 的服務(wù)器。
上述四個(gè)角色的交互流程如圖 1 所示。
圖1 OAuth 2.0交互流程
基本流程包括以下步驟:
(1)Client向Resource Owner請求授權(quán)許可。授權(quán)請求可以如圖1所示直接發(fā)送給Resource Owner,但最好是間接地通過 Authorization Server 請求授權(quán)。
(2) Client接收到一個(gè)代表 Resource Owner授權(quán)的授權(quán)許可,通常以協(xié)議規(guī)范中定義的四種許可類型之一表示。授權(quán)許可的類型由Client請求授權(quán)和 Authorization Server 所支持的類型決定。
(3)Client向Authorization Server認(rèn)證身份,并通過展示授權(quán)許可請求訪問令牌。
(4)Authorization Server 認(rèn)證Client身份并驗(yàn)證其授權(quán)許可,若認(rèn)證成功則頒發(fā)訪問令牌。
(5) Client通過展示訪問令牌向Resource Ser-ver請求受保護(hù)資源。
(6)Resource Server驗(yàn)證請求中訪問令牌,若驗(yàn)證成功則響應(yīng)Client請求。
為了獲取訪問令牌,客戶端需要向用戶獲取授權(quán)。而用戶授權(quán)則以授權(quán)許可的形式向客戶端授予訪問受保護(hù)資源的權(quán)限。OAuth 2.0 協(xié)議中共定義了授權(quán)碼、隱式授權(quán)、用戶密碼憑據(jù)和客戶端憑據(jù)等四種類型的授權(quán)許可。
OAuth 2.0的協(xié)議只是規(guī)定了相關(guān)規(guī)范,但不同開發(fā)者的實(shí)現(xiàn)細(xì)節(jié)卻是大同小異[8][9]。表1列舉了幾個(gè)知名網(wǎng)站中 OAuth 2.0實(shí)現(xiàn)方式。
表1 知名網(wǎng)站的OAuth 2.0實(shí)現(xiàn)
Tab.1 OAuth 2.0 implementation of well known websites
可以看出,這些廠商的OAuth 2.0服務(wù)大多數(shù)都支持授權(quán)碼形式的授權(quán)許可和刷性令牌的操作,卻都不支持用戶密碼憑證形式的授權(quán)許可,而且其客戶端的認(rèn)證方式大多限于Basic和POST方式。
依據(jù)OAuth 2.0協(xié)議流程,通過授權(quán)碼形式的授權(quán)許可獲取訪問令牌,從而向客戶端提供訪問受保護(hù)資源的能力,并支持刷新令牌操作,使客戶端在得知訪問令牌失效之后,可使用刷新令牌再度獲取訪問令牌。為保證OAuth 2.0應(yīng)用的安全性,在設(shè)計(jì)時(shí)重點(diǎn)考慮以下環(huán)節(jié)的技術(shù)實(shí)現(xiàn)方案:
(1)全站配置HTTPS??梢允褂肗ginx為相關(guān)域名配置SSL證書,并將相關(guān)域名的HTTP訪問請求自動(dòng)重定向到HTTPS請求,以保證請求數(shù)據(jù)在網(wǎng)絡(luò)傳輸過程中的安全性。
(2)客戶端回調(diào)URI的驗(yàn)證。
(3)訪問令牌中包含的授權(quán)信息驗(yàn)證。解決該問題的關(guān)鍵在于,客戶端注冊時(shí)授權(quán)服務(wù)器須在持久化的關(guān)系型數(shù)據(jù)庫中記錄其填寫的回調(diào)URI,并在客戶端獲取授權(quán)碼和訪問令牌的時(shí)候,充分驗(yàn)證其請求參數(shù)中的回調(diào) URI。
(4)訪問令牌的訪問范圍和訪問有效期驗(yàn)證。這些問題均由訪問令牌的易變性產(chǎn)生。為了保證訪問令牌在協(xié)議請求過程中的穩(wěn)定性和可用性,OAuth 2.0 應(yīng)用開發(fā)者可以在應(yīng)用中引入 Redis 內(nèi)存數(shù)據(jù)庫,將訪問令牌和其授權(quán)信息存儲(chǔ)在 Redis 中,并為其設(shè)置一定的有效期。授權(quán)服務(wù)器和資源服務(wù)器就可以通過共同操作Redis數(shù)據(jù)庫,達(dá)到同時(shí)限制客戶端訪問令牌(刷新令牌)的目的。
總體設(shè)計(jì)架構(gòu)如圖2所示。
圖2 基于OAuth2.0的總體設(shè)計(jì)架構(gòu)圖
其中,Nginx服務(wù)器負(fù)責(zé)配置全站HTTPS,并實(shí)現(xiàn)對授權(quán)服務(wù)器和資源服務(wù)器的反向代理。授權(quán)服務(wù)器負(fù)責(zé)接收來自Nginx的客戶端認(rèn)證授權(quán)請求,授予客戶端授權(quán)碼和訪問令牌(刷新令牌)。資源服務(wù)器負(fù)責(zé)接受客戶端攜帶訪問令牌的請求,驗(yàn)證其訪問令牌的正確性,并響應(yīng)其一定范圍內(nèi)的受保護(hù)資源請求。MySQL 數(shù)據(jù)庫負(fù)責(zé)存儲(chǔ)第三方應(yīng)用數(shù)據(jù)和用戶信息數(shù)據(jù)。Redis 數(shù)據(jù)庫負(fù)責(zé)存儲(chǔ)帶有訪問范圍和訪問有效期的客戶端授權(quán)碼和訪問令牌(刷新令牌)。
上述實(shí)現(xiàn)方案存在一個(gè)問題:由于OAuth 2.0是基于用戶代理重定向的協(xié)議,這決定了客戶端和OAuth 2.0認(rèn)證授權(quán)服務(wù)只能通過 HTTP 重定向來交換數(shù)據(jù),這使得客戶端應(yīng)用在授權(quán)登錄之后,仍滯留著用戶未登錄之前的頁面,從而導(dǎo)致較差的用戶體驗(yàn)。具體表現(xiàn)為:當(dāng)?shù)谌綉?yīng)用登錄成功之后,在瀏覽器中會(huì)存在兩個(gè)歷史標(biāo)簽頁,其中第一個(gè)標(biāo)簽頁是用戶未登錄之前的頁面,另一個(gè)標(biāo)簽頁則是用戶登錄之后的頁面。
產(chǎn)生登錄前頁面滯留的問題根本原因在于OAuth 2.0協(xié)議流程中繁瑣的用戶代理重定向,導(dǎo)致了第三方應(yīng)用在啟動(dòng)協(xié)議流程時(shí)發(fā)起的請求無法在協(xié)議流程的末尾時(shí)恰當(dāng)?shù)亟邮誒Auth 2.0應(yīng)用回傳的數(shù)據(jù)。一種合適解決辦法是引入一種可在客戶端和服務(wù)端之間建立雙向通訊的消息監(jiān)聽機(jī)制,在授權(quán)過程中根據(jù)監(jiān)聽到的第三方應(yīng)用的消息回傳事件做出相應(yīng)的處理。WebSocket 就是滿足以上需求的一種支持全工雙向通訊的網(wǎng)絡(luò)協(xié)議,目前主流瀏覽器都已經(jīng)支持WebSocket[10]。優(yōu)化后的設(shè)計(jì)方案如圖3所示。
該方案基于原有OAuth 2.0協(xié)議交互模式,在第三方應(yīng)用的客戶端和服務(wù)端建立WebSocket連接。若第三方應(yīng)用服務(wù)端在接收到來自O(shè)Auth Server的返回?cái)?shù)據(jù),第三方應(yīng)用則會(huì)向其客戶端發(fā)送一條消息。第三方應(yīng)用客戶端始終處于監(jiān)聽其服務(wù)端消息的狀態(tài),若接收到一條消息,則表示OAuth Server向第三方應(yīng)用返回?cái)?shù)據(jù)成功。通過在第三方應(yīng)用客戶端和服務(wù)端之間建立WebSocket連接,第三方應(yīng)用便可以快速且不受限制地得知OAuth Server對第三方應(yīng)用請求的響應(yīng)狀態(tài),進(jìn)而采取相應(yīng)的動(dòng)作以消除滯留的登錄之前的網(wǎng)頁。
圖3 優(yōu)化方案原理圖
基于OAuth 2.0協(xié)議規(guī)范設(shè)計(jì)了一個(gè)基于用戶信息為中心數(shù)據(jù)的OAuth 2.0認(rèn)證授權(quán)應(yīng)用框架,分析了由于OAuth 2.0協(xié)議的機(jī)制原因?qū)е碌挠脩粼谑跈?quán)登錄過程中出現(xiàn)的歷史頁面滯留問題,并給出一個(gè)合理可行的優(yōu)化方案,即通過引入雙向通訊 WebSocket 技術(shù)來簡化常規(guī)應(yīng)用中OAuth 2.0協(xié)議的開發(fā)流程。本設(shè)計(jì)方案旨在為使用OAuth2.0協(xié)議的開發(fā)者提供參考。
[1] 時(shí)子慶, 劉金蘭, 譚曉華. 基于OAuth2.0的認(rèn)證授權(quán)技術(shù)[J].計(jì)算機(jī)系統(tǒng)應(yīng)用, 2012年03期: 260-264.
[2] Microsoft. RFC 6479-2012 The OAuth 2.0 Authorization Framework[S]. ISSN: 2070-1721.
[3] MTI Systems. RFC 6750-2012. The OAuth 2.0 Authorization Framework: Bearer Token Usage[S]. ISSN: 2070-1721.
[4] 微信. 微信公眾平臺(tái)開發(fā)者文檔[OL]. (2017-05-05). https://mp.weixin.qq.com/wiki/home.
[5] Google. Using OAuth 2.0 to Access Google APIs[OL](2017-05-05). https://developers.google.com/identity/protocols/OAuth2.
[6] 豆瓣. 了解Auth2.0[OL]. (2017-05-05).https://developers. douban.com/wiki/?title=oauth2.
[7] 維基百科. OAuth[OL]. (2017-01-27). https://zh.wikipedia. org/zh-hans/OAuth.
[8] 魏成坤, 劉向東, 石兆軍. 基于OAuth2.0的認(rèn)證授權(quán)技術(shù)研究[J]. 信息網(wǎng)絡(luò)安全, 2016年09期: 6-11.
[9] 盧慧鋒, 趙文濤, 孫志峰, 游超. 社會(huì)化網(wǎng)絡(luò)服務(wù)中OAuth2.0的應(yīng)用研究與實(shí)現(xiàn)[J]. 計(jì)算機(jī)應(yīng)用. 2014, 34(S1): 50-54.
[10] Google. RFC 6455-2011. The WebSocket Protocol[S]. ISSN 2070-1721.
Design and Optimization of Authentication and Authorization Scheme Based on OAuth2.0 Protocol
WU De, YING Yi, MAO Dao-he
(College of Computer Science and Engineering, Sanjiang University, Nanjing, Jiangsu 210012, China)
The OAuth 2.0 is a certification of authorization protocol defined in the RFC-6749 specification document published by the Internet Engineering Task Force in October 2012. The OAuth 2.0 is a kind of open authorization framework based on HTTP redirection implementation, which allows the third party applications to access the user’s specific resources stored on a web site without having to provide the user name and password to the third party applications. The application of OAuth 2.0 protocol highly promotes the user experience of WEB application. In order to deeply study the working principle of OAuth 2.0 protocol, an open authorization application framework is designed using Nginx server, MySQL and Redis database. At the same time, the deficiencies of OAuth 2.0 protocol in the authorization process are pointed out, and an optimization solution based on WebSocket monitoring mechanism is presented which provides reference for the development of authentication authorization application.
RFC-6479; OAuth 2.0; Authentication; Authorization
TP391.41
A
10.3969/j.issn.1003-6970.2018.10.003
江蘇省現(xiàn)代教育技術(shù)課題(批準(zhǔn)號(hào):2017-R-59217)、江蘇省高等學(xué)校自然科學(xué)研究項(xiàng)目(批準(zhǔn)號(hào):17KJB520033)
吳德(1978-),男,講師,主要研究方向:數(shù)據(jù)挖掘與智能計(jì)算;應(yīng)毅(1979-),男,副教授,主要研究方向:大數(shù)據(jù)與云計(jì)算;毛道鶴(1994-),男,工程師,主要研究方向:Java應(yīng)用開發(fā)。
吳德,應(yīng)毅,毛道鶴. 基于OAuth2.0的認(rèn)證授權(quán)方案設(shè)計(jì)與優(yōu)化[J]. 軟件,2018,39(10):10-13