利用OpenID和OAuth進行安全授權(quán)及風險防范的分析

劉 為 郝 梅

(武漢商業(yè)服務學院，湖北 武漢 430056)

一、Web應用的發(fā)展現(xiàn)狀

隨著Web網(wǎng)絡技術的飛速發(fā)展，網(wǎng)絡應用層出不窮，以社交、分享為代表的web2.0應用已經(jīng)融入了大眾生活，成為網(wǎng)絡發(fā)展的先鋒，諸如國外的Facebook、Twitter、YouTube，國內(nèi)的 Sina 微博、Tencent微博、QQ空間、人人網(wǎng)、360團購等，Web應用的開放化也成為服務商占領市場的一種方式。網(wǎng)絡信息從分散的狀態(tài)，向幾個大型的網(wǎng)絡應用中心聚攏；其他各種數(shù)據(jù)應用，為了得到更多用戶訪問量，都會向這些數(shù)據(jù)中心靠攏，請求用戶數(shù)據(jù)，如Youku上的視頻分享到Tencent微博，這些典型的應用不一定要服務商自己解決，服務商只需公開API給第三方應用，同時加上用戶授權(quán)，第三方就可以代理用戶實現(xiàn)數(shù)據(jù)交互。在這種信息交互中，第三方還可以獲得用戶的個人信息（已授權(quán)部分），并進行深度挖掘，實現(xiàn)了多方受益。

二、開放性Web應用平臺的不安全因素

現(xiàn)在主流的應用平臺，都實現(xiàn)了開放功能，即以API的形式，向第三方應用公開用戶所授權(quán)的內(nèi)容，這些第三方應用可以是網(wǎng)站，可以是專門開發(fā)的Web或桌面端應用程序，還可以是移動終端（手機、平板等）程序。信息的整合和獲取變得更加簡單，但是，相應的安全問題也很明顯：

1、應用平臺內(nèi)的信息屬于用戶隱私，第三方在何種方式下能夠合法的得到這些信息？

2、使用何種機制和技術，能夠保障用戶在授權(quán)過程中不透露或不被竊取個人信息，如用戶名、銀行賬號、密碼等。

3、應用平臺如何審核與規(guī)范第三方應用，防止它們偷偷的收集用戶個人信息，同時還需要防止不被授權(quán)的第三方應用非法取得權(quán)限。

基于以上問題，互聯(lián)網(wǎng)上出現(xiàn)了兩種開放應用協(xié)議，分別是OpenID和OAuth，其作用就是為開放平臺提供規(guī)范、簡潔、安全的通信、授權(quán)和管理機制。這兩種協(xié)議已經(jīng)得到了很多大型廠商的支持，如Yahoo，F(xiàn)acebook，Twitter，Microsoft，Google 等，國內(nèi)的sina，豆瓣，騰訊等都已開始應用這兩項技術。

三、OpenID協(xié)議

OpenID是一種去中心化的身份認證，其不依賴一個集中的認證服務來工作，可以在任意支持該OpenID的網(wǎng)站完成認證工作。比如，用戶在360的網(wǎng)站上注冊成為會員，然后可以憑注冊的用戶名和密碼，登錄數(shù)十個與360合作的、支持該OpenID的團購網(wǎng)站，如美團網(wǎng)，拉手網(wǎng)等，而在這些團購網(wǎng)站上登錄的效果，就猶如是已經(jīng)在這些網(wǎng)站上注冊了用戶一樣。這樣的好處是，一次注冊，可以在多個網(wǎng)站上登陸，從而實現(xiàn)了跨域的單點登錄（SSO）的功能，用戶再無須進行重復的注冊和登錄。

OpenID定義了三個身份和一個標識，如表1所示：

表1 OpenID身份和標識

OpenID的工作流程如下：

1、用戶(End User)需要使用服務提供者(Relying Party)的服務時，要向其提供自己的標識（OpenID URL，可以在頁面上輸入，但一般是點擊圖標操作）。

2、服務提供者根據(jù)用戶的OpenID URL與身份提供者(Identity Provider)進行通信，這里的通信有兩種模式：一種是在后臺進行，不提示用戶；一種是使用訪問服務提供者站點的同一個瀏覽器窗口與身份提供者服務器交互。其中第二種模式更為常用，接下來將以第二種模式分析。這一步結(jié)束后，服務提供者和身份提供者建立了通信。

3、服務提供者將用戶引導到身份提供者的身份認證頁面。

4、用戶向身份提供者表明身份，并完成認證。

5、認證結(jié)束后，身份提供者將用戶引導回服務提供者，同時返回的信息包含認證用戶的結(jié)果判斷，以及服務提供者需要的一些其它信息。

6、服務提供者判斷返回信息的有效性，認證成功，用戶即可使用相應的功能。

OpenID跨域工作的方式，非常適合現(xiàn)在不同服務提供商之間的用戶共享，一方面增加了服務提供商的潛在客戶，另一方面也給用戶提供了更好的登錄體驗。

四、OAuth協(xié)議

OAuth協(xié)議是一個開放的認證協(xié)議，其作用是為使用API的第三方提供安全、簡單、標準的認證。簡單地說，OAuth允許用戶授權(quán)第三方的應用訪問他們存儲在另外的服務提供者上的信息，而不需要將用戶名和密碼提供給第三方。比如人人網(wǎng)需要訪問用戶QQ好友列表的內(nèi)容，用戶需要授權(quán)給人人網(wǎng)，但是如果直接將用戶的QQ號和密碼發(fā)給人人網(wǎng)，很難保證其不記錄下來，從而對用戶產(chǎn)生安全威脅。OAuth可以看作OpenID的一個補充，一般支持OpenID的服務都會使用到OAuth。

OAuth定義了3個身份，如表2：

表2 OAuth的身份定義

OAuth大致工作方式如圖1：

圖1 OAuth工作流程圖

其工作流程描述如下：

1、第三方服務者（Consumer）可以與不同的服務提供者(Service Provider)建立合作關系，每一個第三方的一個應用，都可以在服務提供者那里申請到唯一的AppID（類似于登錄名）或是公鑰。

2、當用戶向（User）第三方發(fā)出請求時，第三方提供一個AppID或者是公鑰給服務提供方，服務提供方使用該公鑰來確認第三方的身份，并與之建立通信。

3、第三方根據(jù)服務提供者發(fā)回的信息，將用戶重定向到服務提供者網(wǎng)站所提供的登錄頁面。

4、用戶登錄后告訴服務提供者，該第三方訪問他的保護資源是沒問題的。

OAuth認證過程中的一個關鍵技術叫做令牌（token），分為兩種：

1、Request_token：一個臨時的令牌，其作用是第三方在向服務提供者初次發(fā)出請求時，服務提供商返回的一個臨時令牌。

2、Access_token：是第三方獲得用戶授權(quán)后，服務提供商提供給第三方的一個存取令牌，第三方憑此令牌與服務提供者進行通信，并可以訪問用戶資源。

OAuth授權(quán)的過程中伴隨著如下令牌的交換，其中3個URL是必須的，用于不同token的申請：

1、第三方向服務提供商的Request_token URL發(fā)起請求，獲得未授權(quán)的臨時令牌：Request_token。

2、第三方將先前獲得的Request_token，帶上自身的信息（AppID和用戶要求等）發(fā)往服務提供商的User_Authorization URL，并請求用戶授權(quán)。授權(quán)后，再將授權(quán)Request_token返還給第三方。

3、第三方憑已授權(quán)的Request_token向服務提供商的Access_token URL發(fā)起請求，換取Access_token，進而憑此令牌訪問用戶的資源。

從上面可以看出，OAuth協(xié)議認證雖然也有用戶登錄的過程，但是，其登錄始終是在服務提供者的頁面登錄，而并非在第三方的頁面，從而保證了用戶的登錄名和密碼不泄露給第三方。

圖2 OpenID和OAuth整合認證流程圖

五、利用OpenID和OAuth進行認證的分析

通過上面的分析，OpenID協(xié)議是服務提供者在與不同的第三方合作時，共享的一個唯一的用戶ID，而OAuth協(xié)議作用于當用戶在第三方網(wǎng)站使用OpenID登錄過程中，保證不將用戶名、密碼等敏感信息透露給第三方。兩者結(jié)合起來使用，基本可以解決開放應用平臺對第三方進行安全授權(quán)的問題。

接下來分析開放平臺（即服務提供者，同時為OpenID提供者）結(jié)合使用OpenID和OAuth協(xié)議，對第三方應用進行安全認證的過程（流程圖見圖2）：

1、開放平臺并非對任何第三方應用都開放，為了管理它們，第三方應用首先應向開放平臺申請一個獨有的AppID和AppKey（類似于用戶名和密碼），這一過程類似于用戶注冊成為網(wǎng)站的會員。完成注冊后，第三方即受到了開放平臺的認可，從而可以進行接下來的開發(fā)工作。

2、應用程序完成后，根據(jù)用戶需求，第三方會向服務提供者請求訪問用戶資源，其方法是向網(wǎng)址Request_token URL（一般也為OpenID的URL）發(fā)送請求，請求包含AppID和AppKey（之后的所有請求都需要這兩個參數(shù)）。

3、服務提供者接受請求，驗證AppID和AppKey，之后返回未經(jīng)授權(quán)的臨時Request_token給第三方。

4、第三方得到未授權(quán)的臨時Request_token后，向User_Authorization URL發(fā)出申請授權(quán)的Request_token的請求，在請求中加入callback地址。在請求發(fā)出后，第三方應按照要求將用戶引導到服務提供商的登陸界面。

5、用戶在登陸界面登陸后，完成授權(quán)工作，這時服務提供商將會生成授權(quán)的臨時Request_token，這其中包含一個唯一的OpenID值 (該值并不安全，可能被篡改)，并返回給第三方，同時將用戶引導到第三方先前提交的callback地址上。

6、第三方收到授權(quán)的臨時Request_token和OpenID值后，如果不再進一步需要訪問用戶的資源，而僅僅是完成登錄的話，則到這一步即可。如果第三方想進一步訪問用戶的資源，則需要向服務提供者的Access_token URL申請具有訪問權(quán)限的Access_token，申請參數(shù)中需帶上上面獲得授權(quán)的Request_token值。

7、服務提供商根據(jù)請求，返回給第三方一個Access_token和一個OpenID，這兩個值是之后訪問和修改用戶數(shù)據(jù)所必須的參數(shù)。注意，這里返回的新的OpenID理論上是和第六步中的OpenID值相同，不過這一步返回的更加安全可靠，因為完全杜絕了用戶篡改和偽造的可能性。同時，該OpenID（也可以是Access_token）也存在過期時間的問題，這需要服務提供商自行設置。

8、第三方獲得了Access_token后可以訪問和修改用戶的數(shù)據(jù)，這里的數(shù)據(jù)包含兩部分，一是服務提供商提供了API的數(shù)據(jù)；二是還要驗證用戶為其數(shù)據(jù)單獨設置的是何種權(quán)限：比如，第三方應用允許訪問用戶留言，但如果用戶本身設置了留言不對外開放，則該應用還是無法訪問。這種組合權(quán)限管理，需要服務提供商提前的設置，而不能依靠OAuth來設置權(quán)限的細節(jié)。

9、第三方獲得了第7步得來的OpenID后，可以將其與用戶在該第三方自身擁有的ID進行綁定。如果該用戶之前沒有該第三方應用的賬戶，第三方可以根據(jù)OpenID的信息為用戶即時創(chuàng)建一個，并生成隨機密碼提供給用戶，以便對該OpenID的管理。

六、依然存在的安全隱患

（一）“釣魚”欺詐

采用OpenID和OAuth進行認證，依然無法防止“釣魚”網(wǎng)站的欺詐。釣魚網(wǎng)站可以偽裝成與服務提供商合作的第三方，然后設置偽裝的OpenID登陸框，誘使用戶輸入用戶名和密碼，從而竊取用戶的信息。對于釣魚網(wǎng)站的防范，主要是依靠用戶預先安裝的安全軟件，以及有安全防護功能的瀏覽器。但更重要的是，對于大多數(shù)不了解釣魚欺詐的用戶來說，服務提供商可能需要安裝瀏覽器插件或ActiveX插件進行即時的防護（幾乎所有的網(wǎng)上銀行都采用這種方式），比如當檢測到用戶輸入了可能的敏感信息時，提醒用戶查看當前網(wǎng)址是否為服務商的真實網(wǎng)址。

（二）地址偽造

在前面第五點分析的認證流程的第6步中，瀏覽器會返回一個OpenID，但是這個OpenID的生成是在用戶參與的情況下，即用戶輸入了用戶名密碼后的，這是個可以偽造的OpenID，惡意攻擊者可以對網(wǎng)站進行虛假登錄。同時，如果攻擊者獲得了AppID和AppKey，也可以偽造簽名，從而生成偽造的OpenID。防范這種風險的方法是，在使用返回的OpenID之前，必須要對其進行效驗，確保和服務端的OpenID相同，或是使用上面第五點分析的認證流程中的第7步返回的OpenID，因為這一步返回的ID是由第三方在后臺與服務提供商進行的通信而生成的，這一過程中并沒有用戶的參與。

[1] 劉敏,呂先競,宋玉忠.基于OpenID的分布式認證系統(tǒng)的設計與實現(xiàn)[J].現(xiàn)代情報,2008(06).

[2] 張明西,劉暉.OpenID標準化認證機制的研究與應用[J].計算機應用與軟件,2010(07).

[3] 阮高峰,徐曉東.OpenID分布式身份認證系統(tǒng)及其教育應用展望[J].中國電化教育,2008(11).

[4] 許彤,雷體南.OpenID與OAuth技術組合應用于教學資源庫建設[J].軟件導刊(教育技術),2009(10).

[5] 張衛(wèi)全,胡志遠.淺析作用于Web2_0安全防范的OpenID和OAuth機制[J].通信管理與技術,2011(02).

[6] 夏曄,錢松榮.OpenID身份認證系統(tǒng)的認證等級模型研究[J].微型電腦應用,2011(04).