基于OAuth2.0的認證授權方案設計與優化

吳 德，應 毅，毛道鶴

?

基于OAuth2.0的認證授權方案設計與優化

吳 德，應 毅，毛道鶴

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

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

RFC-6479；OAuth 2.0；認證；授權

0 引言

OAuth協議為用戶資源的授權提供了一個安全、開放而又簡易的標準。OAuth的授權使得第三方應用無需使用用戶的用戶名與密碼就可以申請獲得該用戶資源的授權[1]。

OAuth 2.0協議于2012年10月正式發布，作為OAuth 1.0的升級版本卻并不向下兼容OAuth 1.0協議[2]。OAuth 2.0協議更加關注客戶端開發的簡易性，同時為移動設備、Web應用、桌面應用等多種客戶端提供認證授權服務[3]。

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

1 OAuth 2.0原理

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

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

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

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

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

（3）Client：客戶端，是代表 Resource Owner，使用其授權許可獲取受保護資源的第三方應用。服務端程序或桌面應用或移動設備，都可以是OAuth 2.0協議流程中的客戶端。

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

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

圖1 OAuth 2.0交互流程

基本流程包括以下步驟：

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

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

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

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

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

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

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

2 基于OAuth2.0的設計框架

OAuth 2.0的協議只是規定了相關規范，但不同開發者的實現細節卻是大同小異[8][9]。表1列舉了幾個知名網站中 OAuth 2.0實現方式。

表1 知名網站的OAuth 2.0實現

Tab.1 OAuth 2.0 implementation of well known websites

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

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

（1）全站配置HTTPS。可以使用Nginx為相關域名配置SSL證書，并將相關域名的HTTP訪問請求自動重定向到HTTPS請求，以保證請求數據在網絡傳輸過程中的安全性。

（2）客戶端回調URI的驗證。

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

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

總體設計架構如圖2所示。

圖2 基于OAuth2.0的總體設計架構圖

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

3 存在的問題

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

4 方案優化策略

產生登錄前頁面滯留的問題根本原因在于OAuth 2.0協議流程中繁瑣的用戶代理重定向，導致了第三方應用在啟動協議流程時發起的請求無法在協議流程的末尾時恰當地接收OAuth 2.0應用回傳的數據。一種合適解決辦法是引入一種可在客戶端和服務端之間建立雙向通訊的消息監聽機制，在授權過程中根據監聽到的第三方應用的消息回傳事件做出相應的處理。WebSocket 就是滿足以上需求的一種支持全工雙向通訊的網絡協議，目前主流瀏覽器都已經支持WebSocket[10]。優化后的設計方案如圖3所示。

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

圖3 優化方案原理圖

5 結論

基于OAuth 2.0協議規范設計了一個基于用戶信息為中心數據的OAuth 2.0認證授權應用框架，分析了由于OAuth 2.0協議的機制原因導致的用戶在授權登錄過程中出現的歷史頁面滯留問題，并給出一個合理可行的優化方案，即通過引入雙向通訊 WebSocket 技術來簡化常規應用中OAuth 2.0協議的開發流程。本設計方案旨在為使用OAuth2.0協議的開發者提供參考。

[1] 時子慶, 劉金蘭, 譚曉華. 基于OAuth2.0的認證授權技術[J].計算機系統應用, 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] 微信. 微信公眾平臺開發者文檔[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的認證授權技術研究[J]. 信息網絡安全, 2016年09期: 6-11.

[9] 盧慧鋒, 趙文濤, 孫志峰, 游超. 社會化網絡服務中OAuth2.0的應用研究與實現[J]. 計算機應用. 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

江蘇省現代教育技術課題(批準號：2017-R-59217)、江蘇省高等學校自然科學研究項目(批準號：17KJB520033)

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

吳德，應毅，毛道鶴. 基于OAuth2.0的認證授權方案設計與優化[J]. 軟件，2018，39（10）：10-13