基于OAuth2.0的認證授權(quán)方案設(shè)計與優(yōu)化

吳 德，應(yīng) 毅，毛道鶴

?

基于OAuth2.0的認證授權(quán)方案設(shè)計與優(yōu)化

吳 德，應(yīng) 毅，毛道鶴

（三江學(xué)院 計算機科學(xué)與工程學(xué)院，江蘇 南京 210012）

OAuth 2.0是由互聯(lián)網(wǎng)工程任務(wù)組于2012年10月發(fā)表在RFC-6749規(guī)范文檔中定義的認證授權(quán)協(xié)議，是一種基于HTTP重定向?qū)崿F(xiàn)的開放授權(quán)框架。它允許第三方應(yīng)用訪問該用戶在某一網(wǎng)站上存儲的特定資源，而無需將用戶名和密碼提供給第三方應(yīng)用，大幅提升用戶的WEB應(yīng)用體驗。為深入研究OAuth 2.0協(xié)議的工作原理，使用Nginx 服務(wù)器、MySQL和Redis數(shù)據(jù)庫設(shè)計了一個開放授權(quán)應(yīng)用框架，同時指出OAuth 2.0協(xié)議應(yīng)用在授權(quán)流程中的不足之處，并給出基于WebSocket監(jiān)聽機制的優(yōu)化解決方案，為認證授權(quán)應(yīng)用的開發(fā)提供參考。

RFC-6479；OAuth 2.0；認證；授權(quán)

0 引言

OAuth協(xié)議為用戶資源的授權(quá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è)備、Web應(yīng)用、桌面應(yīng)用等多種客戶端提供認證授權(quán)服務(wù)[3]。

目前，國內(nèi)外各大主流互聯(lián)網(wǎng)公司如騰訊、新浪、豆瓣、Facebook、Google等均已支持OAuth 2.0協(xié)議[4-6]。通過在其開發(fā)者平臺上提供基于OAuth 2.0的開放授權(quán) OpenAPI，由客戶端開發(fā)者調(diào)用，便可以向市場上的其它中小型應(yīng)用分享其海量的用戶數(shù)據(jù)。通過這種方式，不同廠家不同類型的應(yīng)用只要遵循OAuth 2.0協(xié)議流程，就可以引入各大主流網(wǎng)站的用戶資源，簡化登錄流程，優(yōu)化用戶體驗，從而提高應(yīng)用的可用性和用戶的活躍度。

1 OAuth 2.0原理

OAuth 2.0授權(quán)框架允許第三方應(yīng)用代表資源所有者通過合法地協(xié)調(diào)資源所有者和HTTP服務(wù)之間交互，或者僅代表第三方應(yīng)用本身，對Web服務(wù)進行有限地訪問。該協(xié)議允許用戶通過授權(quán)的方式讓第三方應(yīng)用訪問該用戶在某一網(wǎng)站上存儲的私密資源（如照片，視頻，聯(lián)系人列表），而無需將用戶名和密碼提供給第三方應(yīng)用[7]。

OAuth 2.0協(xié)議使得用戶通過令牌（而不是用戶名和密碼）來有限地訪問存儲在特定服務(wù)提供者那里的數(shù)據(jù)。每一個令牌授權(quán)一個特定的網(wǎng)站在特定的時段（例如，接下來的120分鐘內(nèi)）內(nèi)訪問特定的資源（例如僅限于某一相冊中的照片）。

OAuth 2.0協(xié)議定義了四個角色，分別是：

（1）Resource Owner：資源所有者，是一個能授予訪問受保護資源權(quán)限的實體。當資源所有者是人類的時候，它被稱為終端的用戶。

（2）Resource Server：資源服務(wù)器，是一個托管了受保護資源，能接收和響應(yīng)使用訪問令牌訪問受保護資源請求的服務(wù)器。

（3）Client：客戶端，是代表 Resource Owner，使用其授權(quán)許可獲取受保護資源的第三方應(yīng)用。服務(wù)端程序或桌面應(yīng)用或移動設(shè)備，都可以是OAuth 2.0協(xié)議流程中的客戶端。

（4）Authorization Server：授權(quán)服務(wù)器，是指在 Client認證成功，并獲取了 Resource Owner 的授權(quán)之后，頒發(fā)訪問令牌給 Client 的服務(wù)器。

上述四個角色的交互流程如圖 1 所示。

圖1 OAuth 2.0交互流程

基本流程包括以下步驟：

（1）Client向Resource Owner請求授權(quán)許可。授權(quán)請求可以如圖1所示直接發(fā)送給Resource Owner，但最好是間接地通過 Authorization Server 請求授權(quán)。

（2） Client接收到一個代表 Resource Owner授權(quán)的授權(quán)許可，通常以協(xié)議規(guī)范中定義的四種許可類型之一表示。授權(quán)許可的類型由Client請求授權(quán)和 Authorization Server 所支持的類型決定。

（3）Client向Authorization Server認證身份，并通過展示授權(quán)許可請求訪問令牌。

（4）Authorization Server 認證Client身份并驗證其授權(quán)許可，若認證成功則頒發(fā)訪問令牌。

（5） Client通過展示訪問令牌向Resource Ser-ver請求受保護資源。

（6）Resource Server驗證請求中訪問令牌，若驗證成功則響應(yīng)Client請求。

為了獲取訪問令牌，客戶端需要向用戶獲取授權(quán)。而用戶授權(quán)則以授權(quán)許可的形式向客戶端授予訪問受保護資源的權(quán)限。OAuth 2.0 協(xié)議中共定義了授權(quán)碼、隱式授權(quán)、用戶密碼憑據(jù)和客戶端憑據(jù)等四種類型的授權(quán)許可。

2 基于OAuth2.0的設(shè)計框架

OAuth 2.0的協(xié)議只是規(guī)定了相關(guān)規(guī)范，但不同開發(fā)者的實現(xiàn)細節(jié)卻是大同小異[8][9]。表1列舉了幾個知名網(wǎng)站中 OAuth 2.0實現(xiàn)方式。

表1 知名網(wǎng)站的OAuth 2.0實現(xiàn)

Tab.1 OAuth 2.0 implementation of well known websites

可以看出，這些廠商的OAuth 2.0服務(wù)大多數(shù)都支持授權(quán)碼形式的授權(quán)許可和刷性令牌的操作，卻都不支持用戶密碼憑證形式的授權(quán)許可，而且其客戶端的認證方式大多限于Basic和POST方式。

依據(jù)OAuth 2.0協(xié)議流程，通過授權(quán)碼形式的授權(quán)許可獲取訪問令牌，從而向客戶端提供訪問受保護資源的能力，并支持刷新令牌操作，使客戶端在得知訪問令牌失效之后，可使用刷新令牌再度獲取訪問令牌。為保證OAuth 2.0應(yīng)用的安全性，在設(shè)計時重點考慮以下環(huán)節(jié)的技術(shù)實現(xiàn)方案：

（1）全站配置HTTPS?？梢允褂肗ginx為相關(guān)域名配置SSL證書，并將相關(guān)域名的HTTP訪問請求自動重定向到HTTPS請求，以保證請求數(shù)據(jù)在網(wǎng)絡(luò)傳輸過程中的安全性。

（2）客戶端回調(diào)URI的驗證。

（3）訪問令牌中包含的授權(quán)信息驗證。解決該問題的關(guān)鍵在于，客戶端注冊時授權(quán)服務(wù)器須在持久化的關(guān)系型數(shù)據(jù)庫中記錄其填寫的回調(diào)URI，并在客戶端獲取授權(quán)碼和訪問令牌的時候，充分驗證其請求參數(shù)中的回調(diào) URI。

（4）訪問令牌的訪問范圍和訪問有效期驗證。這些問題均由訪問令牌的易變性產(chǎn)生。為了保證訪問令牌在協(xié)議請求過程中的穩(wěn)定性和可用性，OAuth 2.0 應(yīng)用開發(fā)者可以在應(yīng)用中引入 Redis 內(nèi)存數(shù)據(jù)庫，將訪問令牌和其授權(quán)信息存儲在 Redis 中，并為其設(shè)置一定的有效期。授權(quán)服務(wù)器和資源服務(wù)器就可以通過共同操作Redis數(shù)據(jù)庫，達到同時限制客戶端訪問令牌（刷新令牌）的目的。

總體設(shè)計架構(gòu)如圖2所示。

圖2 基于OAuth2.0的總體設(shè)計架構(gòu)圖

其中，Nginx服務(wù)器負責(zé)配置全站HTTPS，并實現(xiàn)對授權(quán)服務(wù)器和資源服務(wù)器的反向代理。授權(quán)服務(wù)器負責(zé)接收來自Nginx的客戶端認證授權(quán)請求，授予客戶端授權(quán)碼和訪問令牌（刷新令牌）。資源服務(wù)器負責(zé)接受客戶端攜帶訪問令牌的請求，驗證其訪問令牌的正確性，并響應(yīng)其一定范圍內(nèi)的受保護資源請求。MySQL 數(shù)據(jù)庫負責(zé)存儲第三方應(yīng)用數(shù)據(jù)和用戶信息數(shù)據(jù)。Redis 數(shù)據(jù)庫負責(zé)存儲帶有訪問范圍和訪問有效期的客戶端授權(quán)碼和訪問令牌（刷新令牌）。

3 存在的問題

上述實現(xiàn)方案存在一個問題：由于OAuth 2.0是基于用戶代理重定向的協(xié)議，這決定了客戶端和OAuth 2.0認證授權(quán)服務(wù)只能通過 HTTP 重定向來交換數(shù)據(jù)，這使得客戶端應(yīng)用在授權(quán)登錄之后，仍滯留著用戶未登錄之前的頁面，從而導(dǎo)致較差的用戶體驗。具體表現(xiàn)為：當?shù)谌綉?yīng)用登錄成功之后，在瀏覽器中會存在兩個歷史標簽頁，其中第一個標簽頁是用戶未登錄之前的頁面，另一個標簽頁則是用戶登錄之后的頁面。

4 方案優(yōu)化策略

產(chǎn)生登錄前頁面滯留的問題根本原因在于OAuth 2.0協(xié)議流程中繁瑣的用戶代理重定向，導(dǎo)致了第三方應(yīng)用在啟動協(xié)議流程時發(fā)起的請求無法在協(xié)議流程的末尾時恰當?shù)亟邮誒Auth 2.0應(yīng)用回傳的數(shù)據(jù)。一種合適解決辦法是引入一種可在客戶端和服務(wù)端之間建立雙向通訊的消息監(jiān)聽機制，在授權(quán)過程中根據(jù)監(jiān)聽到的第三方應(yīng)用的消息回傳事件做出相應(yīng)的處理。WebSocket 就是滿足以上需求的一種支持全工雙向通訊的網(wǎng)絡(luò)協(xié)議，目前主流瀏覽器都已經(jīng)支持WebSocket[10]。優(yōu)化后的設(shè)計方案如圖3所示。

該方案基于原有OAuth 2.0協(xié)議交互模式，在第三方應(yīng)用的客戶端和服務(wù)端建立WebSocket連接。若第三方應(yīng)用服務(wù)端在接收到來自O(shè)Auth Server的返回數(shù)據(jù)，第三方應(yīng)用則會向其客戶端發(fā)送一條消息。第三方應(yīng)用客戶端始終處于監(jiān)聽其服務(wù)端消息的狀態(tài)，若接收到一條消息，則表示OAuth Server向第三方應(yīng)用返回數(shù)據(jù)成功。通過在第三方應(yīng)用客戶端和服務(wù)端之間建立WebSocket連接，第三方應(yīng)用便可以快速且不受限制地得知OAuth Server對第三方應(yīng)用請求的響應(yīng)狀態(tài)，進而采取相應(yīng)的動作以消除滯留的登錄之前的網(wǎng)頁。

圖3 優(yōu)化方案原理圖

5 結(jié)論

基于OAuth 2.0協(xié)議規(guī)范設(shè)計了一個基于用戶信息為中心數(shù)據(jù)的OAuth 2.0認證授權(quán)應(yīng)用框架，分析了由于OAuth 2.0協(xié)議的機制原因?qū)е碌挠脩粼谑跈?quán)登錄過程中出現(xiàn)的歷史頁面滯留問題，并給出一個合理可行的優(yōu)化方案，即通過引入雙向通訊 WebSocket 技術(shù)來簡化常規(guī)應(yīng)用中OAuth 2.0協(xié)議的開發(fā)流程。本設(shè)計方案旨在為使用OAuth2.0協(xié)議的開發(fā)者提供參考。

[1] 時子慶, 劉金蘭, 譚曉華. 基于OAuth2.0的認證授權(quán)技術(shù)[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] 微信. 微信公眾平臺開發(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的認證授權(quán)技術(shù)研究[J]. 信息網(wǎng)絡(luò)安全, 2016年09期: 6-11.

[9] 盧慧鋒, 趙文濤, 孫志峰, 游超. 社會化網(wǎng)絡(luò)服務(wù)中OAuth2.0的應(yīng)用研究與實現(xiàn)[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ù)課題(批準號：2017-R-59217)、江蘇省高等學(xué)校自然科學(xué)研究項目(批準號：17KJB520033)

吳德(1978-)，男，講師，主要研究方向：數(shù)據(jù)挖掘與智能計算；應(yīng)毅(1979-)，男，副教授，主要研究方向：大數(shù)據(jù)與云計算；毛道鶴(1994-)，男，工程師，主要研究方向：Java應(yīng)用開發(fā)。

吳德，應(yīng)毅，毛道鶴. 基于OAuth2.0的認證授權(quán)方案設(shè)計與優(yōu)化[J]. 軟件，2018，39（10）：10-13