◆趙嘉熙 鄔卓恒

系統(tǒng)科學(xué)視域下基于OAuth2.0的授權(quán)登錄安全性提升方案研究分析

◆趙嘉熙 鄔卓恒通訊作者

（廣東理工學(xué)院信息技術(shù)學(xué)院 廣東 526000）

為了極大限度地給用戶提供便利，如今的網(wǎng)絡(luò)應(yīng)用供應(yīng)商都提供了第三方授權(quán)登錄的方式，目前OAuth2.0為單點(diǎn)登錄（SSO）最為廣泛的身份認(rèn)證授權(quán)協(xié)議。OAuth2.0是開放式標(biāo)準(zhǔn)的第三方授權(quán)協(xié)議，允許用戶授權(quán)第三方平臺(tái)獲取在某一平臺(tái)上存儲(chǔ)的個(gè)人信息資源，而無需將用戶名和密碼提供給第三方平臺(tái)；針對(duì)OAuth2.0協(xié)議實(shí)施過程中可能存在的信息泄露等的安全威脅，在現(xiàn)有的關(guān)于提升OAuth2.0安全性的研究中，本文分析了兩種目前相對(duì)新穎且可靠的模式，分別是匿名化與區(qū)塊鏈智能合約與OAuth2.0協(xié)議結(jié)合的嘗試，以系統(tǒng)科學(xué)視域分析兩種針對(duì)OAuth2.0安全性的改進(jìn)方案。

OAuth2.0；SSO；第三方平臺(tái)；區(qū)塊鏈；匿名化

當(dāng)前，基于各大通訊平臺(tái)的使用人數(shù)日益擴(kuò)大，為了增加用戶對(duì)網(wǎng)頁或軟件的黏度，第三方授權(quán)登錄的方式漸漸興起，直到現(xiàn)在幾乎每個(gè)軟件和網(wǎng)頁都能看到自定義選擇第三方授權(quán)登錄的方式。在這之前，用戶在各個(gè)平臺(tái)的賬戶是相互獨(dú)立的，為了省去記憶多個(gè)平臺(tái)對(duì)應(yīng)多個(gè)賬戶密碼的麻煩，就出現(xiàn)了一種數(shù)個(gè)平臺(tái)都是同一賬戶同一密碼的現(xiàn)象，這就給了黑客有了可乘之機(jī)[1]。黑客會(huì)利用這種漏洞，破解網(wǎng)站的管理者入口，進(jìn)入內(nèi)部獲取用戶的賬戶信息再到各個(gè)平臺(tái)嘗試登錄。第三方授權(quán)登錄是基于OAuth2.0協(xié)議的登錄方式，實(shí)現(xiàn)了一套賬戶密碼對(duì)應(yīng)多個(gè)平臺(tái)的理想。若是想在網(wǎng)頁端進(jìn)行第三方登錄，初次僅需用手機(jī)端應(yīng)用掃描二維碼同意授權(quán)，之后基于該網(wǎng)頁的活動(dòng)都無需再重復(fù)掃碼，點(diǎn)擊在網(wǎng)頁的頭像然后在手機(jī)端點(diǎn)擊同意授權(quán)即可。在手機(jī)應(yīng)用之間的活動(dòng)點(diǎn)擊第三方授權(quán)登錄即跳轉(zhuǎn)到另一客戶端獲取授權(quán)許可即可登錄，免去了掃描二維碼的過程。隨著使用第三方授權(quán)登錄的用戶日益龐大，用戶使用第三方授權(quán)登錄的頻率越高，其中潛在的風(fēng)險(xiǎn)就越大，因?yàn)橛脩羰褂玫木W(wǎng)站門戶決定了賬戶的安全程度，一旦賬戶密碼被破解，將對(duì)用戶各方面造成損失。由于OAuth 2.0最初是為Web環(huán)境中的授權(quán)目的而設(shè)計(jì)的，加上缺乏關(guān)于如何在本地Android應(yīng)用程序中實(shí)現(xiàn)它的詳細(xì)說明，這些IdP的解決方案和使用這些解決方案的第三方應(yīng)用程序引入了許多嚴(yán)重的漏洞。接下來將詳細(xì)介紹OAuth 2.0授權(quán)代碼授權(quán)流程和隱式授權(quán)流程，從系統(tǒng)科學(xué)視域角度總結(jié)不同環(huán)境對(duì)OAuth 2.0安全的影響，并探討Oauth2.0授權(quán)模式和其他技術(shù)結(jié)合是否有效的方案。

1 Oauth2.0的背景

首先，隨著互聯(lián)網(wǎng)快速發(fā)展，許多企業(yè)單位為加快信息化進(jìn)程都建立了大量網(wǎng)頁和應(yīng)用，用戶需要在不同的應(yīng)用系統(tǒng)間登錄。單點(diǎn)登錄（Single Sign On，SSO）為降低非法破解口令的可能性[2]，提升系統(tǒng)的安全性便應(yīng)運(yùn)而生。單點(diǎn)登錄就是多個(gè)應(yīng)用系統(tǒng)共用一個(gè)登錄認(rèn)證機(jī)制，用戶只需登錄一次，就可以自由在多個(gè)應(yīng)用或網(wǎng)頁來回切換，不需要重新輸入用戶名和口令進(jìn)行登錄。而OAuth2.0就是SSO最廣泛使用的協(xié)議。OAuth2.0是一個(gè)開放標(biāo)準(zhǔn)式的第三方授權(quán)協(xié)議，允許用戶授權(quán)第三方平臺(tái)獲取在某個(gè)APP上存儲(chǔ)的個(gè)人信息而無需將用戶名和密碼提供給第三方平臺(tái)。OAuth2.0的抽象協(xié)議流程涉及四個(gè)角色，分別為客戶端、資源擁有者、授權(quán)服務(wù)器和資源服務(wù)器；四種授權(quán)模式，分別為授權(quán)碼授權(quán)模式、隱式授權(quán)模式、用戶名和密碼授權(quán)模式、客戶端授權(quán)模式[2]。當(dāng)用戶想登錄一個(gè)第三方應(yīng)用或者網(wǎng)頁時(shí)，可以選擇是否使用自己的社交平臺(tái)（如微信或者QQ，是常見的身份提供者）進(jìn)行登錄；當(dāng)用戶按下社交平臺(tái)登錄按鈕后，第三方平臺(tái)將生成一個(gè)登錄頁面，跳轉(zhuǎn)到社交平臺(tái)。接下來，用戶可同意也可拒絕即將授予第三方平臺(tái)的權(quán)限。最后，社交平臺(tái)將會(huì)向第三方平臺(tái)發(fā)送一個(gè)訪問令牌；通過這個(gè)訪問令牌，第三方平臺(tái)可以訪問用戶的部分信息。通過這種機(jī)制，用戶無需為每個(gè)APP記住復(fù)雜的密碼，從而降低了密碼泄露和密碼遺忘的安全風(fēng)險(xiǎn)。此外，這種機(jī)制還降低了第三方平臺(tái)的賬戶管理成本。

2 Oauth2.0的授權(quán)流程

2.1 授權(quán)代碼授予流程

授權(quán)代碼授予流程是最完整也是最嚴(yán)格的授予類型[2]，它適用于第三方應(yīng)用程序，這些應(yīng)用程序不僅可以與用戶的用戶代理（通常是Web環(huán)境中的Web瀏覽器）交互[3]，而且還具有接收來自授權(quán)服務(wù)器的請(qǐng)求的后端服務(wù)器。

如圖1所示，具體授權(quán)流程[2]如下：

（1）用戶輸入U(xiǎn)RL訪問第三方應(yīng)用程序，并希望該應(yīng)用程序可以訪問身份提供商（如微信等社交平臺(tái)）上受保護(hù)的資源，然后第三方應(yīng)用程序?qū)⒂脩舸碇囟ㄏ虻缴缃痪W(wǎng)絡(luò)。

（2）授權(quán)服務(wù)器驗(yàn)證這些參數(shù)，以確保所有必需的參數(shù)都存在且有效。如果驗(yàn)證通過，授權(quán)服務(wù)器將對(duì)用戶進(jìn)行認(rèn)證，然后提供一個(gè)頁面讓用戶決定是否批準(zhǔn)第三方應(yīng)用申請(qǐng)的范圍。

（3）如果用戶批準(zhǔn)了范圍或部分，授權(quán)服務(wù)器會(huì)通過步驟1中第三方應(yīng)用提供的重定向URI將用戶代理重定向到第三方應(yīng)用。

（4）第三方app收到代碼和狀態(tài)后，首先檢查狀態(tài)的正確性，然后使用授權(quán)代碼通過服務(wù)器到服務(wù)器的直接通信從授權(quán)服務(wù)器交換訪問令牌。

（5）授權(quán)服務(wù)器收到訪問令牌請(qǐng)求后，通過客戶端賬號(hào)和客戶端密鑰對(duì)第三方應(yīng)用進(jìn)行身份認(rèn)證，并且驗(yàn)證授權(quán)代碼是否有效[4]，并確保重定向URI的值保持不變，如果驗(yàn)證全部通過，授權(quán)服務(wù)器將向第三方應(yīng)用發(fā)送一個(gè)訪問令牌，第三方應(yīng)用同時(shí)會(huì)獲取一個(gè)刷新令牌，當(dāng)訪問令牌過期時(shí)以便進(jìn)行刷新。

（6）一旦第三方應(yīng)用程序獲得訪問令牌，它就可以使用該訪問令牌訪問身份提供者上的用戶受保護(hù)資源。

圖1 授權(quán)代碼授予流程

2.2 授權(quán)碼授權(quán)流的安全性分析

在授權(quán)碼授權(quán)流中，應(yīng)用URL中的狀態(tài)參數(shù)來緩解CSRF攻擊。在OAuth 2.0協(xié)議中，訪問令牌是一種無記名令牌，它可以被任何擁有這個(gè)令牌的人使用，因此要確保第三方應(yīng)用程序保護(hù)其訪問令牌不被泄露[6]。在授權(quán)代碼授予流程中，第三方應(yīng)用程序通過直接的服務(wù)器到服務(wù)器通信獲得訪問令牌，這比用戶-代理重定向更安全。用戶代理只知道授權(quán)碼。授權(quán)碼存在時(shí)間短，只能使用一次。即使授權(quán)代碼泄露，攻擊者也不能使用它來交換訪問令牌，因?yàn)槭跈?quán)服務(wù)器在發(fā)布訪問令牌之前會(huì)對(duì)第三方應(yīng)用進(jìn)行身份驗(yàn)證（攻擊者不能偽裝成目標(biāo)第三方應(yīng)用，除非他擁有目標(biāo)第三方應(yīng)用的客戶端密鑰）。

2.3 隱式授權(quán)流程

隱式授權(quán)流程適用于只運(yùn)行在用戶設(shè)備上且沒有后端服務(wù)器的第三方應(yīng)用，授權(quán)碼授權(quán)流程和隱式授權(quán)流程如下：在授權(quán)碼授權(quán)流程中，用戶對(duì)應(yīng)用授權(quán)后，授權(quán)服務(wù)器向第三方應(yīng)用發(fā)送授權(quán)碼。然后，第三方應(yīng)用通過服務(wù)器與服務(wù)器之間的直接通信交換訪問令牌授權(quán)碼。在隱式授權(quán)流程中，用戶對(duì)應(yīng)用授權(quán)后，授權(quán)服務(wù)器直接向第三方應(yīng)用發(fā)送訪問令牌。在隱式授權(quán)流程中，授權(quán)服務(wù)器不認(rèn)證第三方應(yīng)用，這是由于第三方應(yīng)用沒有后端服務(wù)器，無法安全地存儲(chǔ)其客戶端賬號(hào)和客戶端密鑰。由于在隱式授權(quán)流中，所有內(nèi)容都是通過用戶設(shè)備交換的，所以在同一臺(tái)設(shè)備上訪問令牌很容易公開給用戶和其他應(yīng)用程序。與授權(quán)碼授權(quán)相比，隱式授權(quán)流程更簡(jiǎn)單，但不夠安全。

2.4 基于安卓系統(tǒng)的Oauth2.0漏洞研究

（1）在本地存儲(chǔ)client_secret容易造成泄露

第三方平臺(tái)使用client_secret在Oauth2.0授權(quán)碼授權(quán)流中向授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證時(shí)，client_secret容易暴露給攻擊者，攻擊者可以使用暴露的client_secret開發(fā)惡意應(yīng)用程序來模擬原始應(yīng)用程序。在安卓系統(tǒng)中，為了方便起見或者是對(duì)Oauth2.0標(biāo)準(zhǔn)的誤解，一些開發(fā)人員習(xí)慣在原生移動(dòng)應(yīng)用中對(duì)client_secret進(jìn)行硬編碼，攻擊者很容易通過從應(yīng)用市場(chǎng)下載目標(biāo)應(yīng)用并對(duì)其靜態(tài)分析來獲取client_secret；另外還有一些開發(fā)人員在運(yùn)行時(shí)將client_secret緩存在本地設(shè)備的共享文件中，這樣攻擊者就會(huì)通過已經(jīng)獲取超級(jí)用戶權(quán)限（ROOT）的設(shè)備運(yùn)行目標(biāo)程序來讀取這個(gè)文件。所以在本地存儲(chǔ)client_secret是不安全的。

（2）在本地存儲(chǔ)訪問令牌

這個(gè)漏洞類似于第一個(gè)，若開發(fā)人員將獲得的訪問令牌或授權(quán)代碼存儲(chǔ)在本地共享首選項(xiàng)文件中[7]，并將訪問令牌和授權(quán)代碼以明文形式存儲(chǔ)時(shí)，攻擊者可以通過對(duì)目標(biāo)應(yīng)用程序動(dòng)態(tài)分析從而獲取到訪問令牌和授權(quán)代碼。

（3）使用嵌入式Webview作為授權(quán)代理

Webview是安卓系統(tǒng)上Oauth2.0實(shí)現(xiàn)中常用的用戶代理，但是Webview作為用戶代理會(huì)危及Oauth2.0的安全性。在Android環(huán)境下，第三方應(yīng)用嵌入的Webview完全由第三方應(yīng)用控制，第三方應(yīng)用程序可以對(duì)嵌入式Webview中顯示的任何內(nèi)容進(jìn)行操作，包括身份認(rèn)證和授權(quán)UI。

（4）只使用訪問令牌作為身份驗(yàn)證的證據(jù)

即使用戶已經(jīng)從第三方應(yīng)用程序注銷，訪問令牌通常也是可用的，僅僅用令牌交換用戶的配置文件不能確保身份驗(yàn)證仍然有效。另外，接入令牌是Oauth2.0協(xié)議中的承載令牌，授權(quán)服務(wù)器不驗(yàn)證第三方應(yīng)用提交的訪問令牌是否是最初發(fā)給這個(gè)應(yīng)用的。如果某個(gè)應(yīng)用程序僅使用訪問令牌作為身份驗(yàn)證的證據(jù)，攻擊者可能會(huì)使用另一個(gè)應(yīng)用程序最初接收到的訪問令牌來欺騙應(yīng)用程序[8]。若第三方應(yīng)用程序沒有驗(yàn)證用戶ID和訪問令牌之間的綁定，攻擊者可以通過SSL中間代理人來修改用戶ID，并使用受害者的用戶ID登錄第三方應(yīng)用。

（5）第三方應(yīng)用重定向處理不當(dāng)

在Web環(huán)境中，Oauth2.0協(xié)議中的不同角色通過瀏覽器重定向來交換信息，這些重定向受到各種安全保護(hù)機(jī)制保護(hù)，但是在Android環(huán)境下情況就要復(fù)雜得多，Oauth2.0有兩種交換信息的方式，一種是顯式意圖，另一種是網(wǎng)頁地址協(xié)議。因?yàn)镮DP原生應(yīng)用程序可以驗(yàn)證第三方應(yīng)用程序，所以第三方應(yīng)用程序和IDP原生應(yīng)用程序可以通過顯式意圖交換信息，這種方式是安全的；若使用外部瀏覽器應(yīng)用作為用戶代理，則第三方應(yīng)用需要注冊(cè)相應(yīng)的網(wǎng)頁地址協(xié)議來接收瀏覽器發(fā)送的隱式意圖[5]，在這種情況下可能會(huì)發(fā)生鏈接劫持攻擊。

（6）缺少傳輸保護(hù)

在Oauth2.0協(xié)議中，應(yīng)該使用SSL或TLS安全輸送內(nèi)容，沒有正確使用SSL或TLS會(huì)造成攻擊者竊聽授權(quán)代碼或訪問令牌。

2.5 利用OAuth2.0漏洞進(jìn)行的攻擊

（1）靜態(tài)和動(dòng)態(tài)分析

攻擊應(yīng)用的第一步是先靜態(tài)和動(dòng)態(tài)地分析它，應(yīng)用程序中硬編碼的未加密信息可以通過靜態(tài)分析提取，應(yīng)用程序運(yùn)行時(shí)產(chǎn)生的未加密敏感信息可以通過動(dòng)態(tài)分析提取。

（2）Webview劫持

當(dāng)使用嵌入式Webview作為用戶代理時(shí)，惡意第三方應(yīng)用程序可通過將JavaScript代碼注入網(wǎng)頁內(nèi)容中，從而向頁面中的任何地方添加JavaScript項(xiàng)目處理程序，以監(jiān)控用戶輸入授權(quán)頁面中顯示的請(qǐng)求權(quán)限。此外通過調(diào)用惡意的第三方應(yīng)用程序可以將本地Java對(duì)象插入到WebView中，添加Java對(duì)象的方法可以被運(yùn)行在WebView中的JavaScript訪問到，它們成功竊聽了用戶訪問Facebook登錄時(shí)的用戶憑據(jù)。

（3）鏈接劫持

如果普通應(yīng)用程序注冊(cè)了一個(gè)網(wǎng)址來從外部瀏覽器應(yīng)用程序接收OAuth2.0憑據(jù)，惡意應(yīng)用程序可以注冊(cè)相同的網(wǎng)址來攔截訪問令牌或授權(quán)代碼；如果目標(biāo)第三方應(yīng)用程序和惡意應(yīng)用程序都安裝在用戶的設(shè)備上，系統(tǒng)將向用戶顯示所有相同網(wǎng)址方案的應(yīng)用程序，并要求用戶選擇一個(gè)，所以用戶極其容易被誘騙選擇惡意應(yīng)用，導(dǎo)致訪問令牌或授權(quán)代碼暴露。

（4）網(wǎng)絡(luò)竊聽

如果未正確使用SSL或TLS，Oauth2.0憑據(jù)將暴露給竊聽者，攻擊者將捕獲任何未加密的信息。

（5）網(wǎng)絡(luò)釣魚攻擊

用戶在原生安卓應(yīng)用中使用單點(diǎn)登錄時(shí)易受到網(wǎng)絡(luò)釣魚攻擊[5]，移動(dòng)設(shè)備操作系統(tǒng)中的瀏覽器和系統(tǒng)本身都缺乏安全的應(yīng)用程序身份指示器，用戶清楚地知道自己在哪個(gè)網(wǎng)站或移動(dòng)應(yīng)用程序交互，極易被網(wǎng)絡(luò)釣魚攻擊入侵頁面。在安卓Oauth2.0協(xié)議的實(shí)現(xiàn)中，無論使用什么用戶代理，當(dāng)用戶登錄時(shí)，都必須有用戶界面的轉(zhuǎn)移，如果第三方應(yīng)用是惡意應(yīng)用程序，可以中斷合法的UI傳輸，向用戶呈現(xiàn)釣魚登錄頁面，一個(gè)合法的登錄頁面可能會(huì)被一個(gè)惡意的釣魚頁面所覆蓋，用戶已經(jīng)習(xí)慣了在登錄頁面輸入密碼就很有可能會(huì)在釣魚頁面不小心輸入密碼。惡意應(yīng)用程序可以嵌入網(wǎng)站，然后竊聽任何交換的憑據(jù)，安卓和iOS都允許應(yīng)用程序?qū)avaScript插入到嵌入式WebView中，網(wǎng)站沒有機(jī)制來阻止這一點(diǎn)，這種攻擊與合法行為幾乎無法區(qū)分，插入的JavaScript可能會(huì)被混淆，從而阻礙應(yīng)用程序分析，這種攻擊的安卓版本需要互聯(lián)網(wǎng)許可才能加載目標(biāo)，但合法版本也是如此。

3 Oauth2.0安全性提升方案分析

3.1 基于匿名化的Oauth2.0授權(quán)的分析

（1）基于匿名的Oauth2.0授權(quán)系統(tǒng)

Victor Sucasas等人提出將基于假名的簽名方案和委托簽名方案集成到OAuth 2.0協(xié)議流的方案，解決了以前報(bào)道的授權(quán)碼授予型OAuth 2.0協(xié)議的隱私問題，該方案允許用戶在不同的不可鏈接假名下對(duì)不同的移動(dòng)應(yīng)用進(jìn)行認(rèn)證和授權(quán)，防止竊聽者跟蹤用戶的活動(dòng)。因?yàn)榧倜梢杂米鲗?shí)體的標(biāo)識(shí)符，同時(shí)仍然保持實(shí)體的匿名狀態(tài)，實(shí)體可以有許多假名，代表實(shí)體、其角色或功能，或?qū)嶓w與不同組織的不同關(guān)系，同一個(gè)實(shí)體的不同假名之間是無法互動(dòng)的，并且不會(huì)泄露任何關(guān)于實(shí)體真實(shí)身份的信息。認(rèn)證機(jī)構(gòu)可以將假名與假名所有者的真實(shí)身份聯(lián)系起來，這就是匿名撤銷，通常被作為一種機(jī)制來對(duì)抗欺詐性地使用其匿名狀態(tài)的濫用者[11]。在不同的加密系統(tǒng)可以實(shí)現(xiàn)匿名化，如數(shù)字匿名憑證，用戶可以生成假名來代表不同組織，并擁有可驗(yàn)證此類假名的憑證。

（2）系統(tǒng)模型概述

如圖2所示，基于假名的系統(tǒng)由以下實(shí)體組成[3]：

①用戶。是訂閱一個(gè)或多個(gè)遠(yuǎn)程服務(wù)并在一個(gè)或多個(gè)資源服務(wù)器中擁有賬號(hào)的實(shí)體；

②客戶端。安裝在用戶移動(dòng)設(shè)備中的移動(dòng)應(yīng)用程序，提供對(duì)用戶訂閱服務(wù)的訪問，在用戶授權(quán)時(shí)可以訪問用戶的遠(yuǎn)程資源；

③安全防護(hù)應(yīng)用程序。安裝在用戶移動(dòng)設(shè)備中的移動(dòng)應(yīng)用程序，通過執(zhí)行加密操作來幫助執(zhí)行建議的隱私保護(hù)協(xié)議，并且用來存儲(chǔ)執(zhí)行協(xié)議所需的非敏感信息；

④資源服務(wù)器。托管用戶賬戶并向公民提供個(gè)性化服務(wù)的服務(wù)器；

⑤授權(quán)服務(wù)器-提供訪問控制機(jī)制的服務(wù)器。使用戶能驗(yàn)證和授權(quán)移動(dòng)應(yīng)用程序代表用戶訪問遠(yuǎn)程資源；

⑥隱私服務(wù)器。通過存儲(chǔ)用戶的真實(shí)身份并在用戶授權(quán)時(shí)觸發(fā)匿名撤銷過程，實(shí)現(xiàn)隱私保護(hù)用戶認(rèn)證，并為提出的基于隱私增強(qiáng)的OAuth 2.0協(xié)議提供了加密機(jī)制。

圖2 基于假名的系統(tǒng)組成

系統(tǒng)的初始化需要用戶注冊(cè)授權(quán)服務(wù)器，用戶需要提供真實(shí)個(gè)人信息并且選擇一個(gè)匿名和密碼，以便在隱私保護(hù)的用戶身份驗(yàn)證中被隱私服務(wù)器用來檢驗(yàn)用戶身份，并且隱私服務(wù)器會(huì)訪問個(gè)人信息，比如說用戶真實(shí)的身份是否同意和其他授權(quán)服務(wù)器共享，如果授權(quán)服務(wù)器在Oauth2.0協(xié)議執(zhí)行隱私保護(hù)流程期間接收到用戶同意的指令，授權(quán)服務(wù)器將會(huì)把信息公開至其他授權(quán)服務(wù)器。授權(quán)服務(wù)器還需要先注冊(cè)隱私服務(wù)器并且展示在其他授權(quán)服務(wù)器中用戶列表的賬號(hào)，即通過這個(gè)授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證來訪問資源服務(wù)器的資源所有者列表。隱私服務(wù)器將自身的注冊(cè)用戶添加到授權(quán)服務(wù)器提供的用戶列表；授權(quán)服務(wù)器同時(shí)也能提供用戶一系列會(huì)訪問此授權(quán)服務(wù)器的應(yīng)用程序。在注冊(cè)隱私服務(wù)器時(shí)，用戶和授權(quán)服務(wù)器會(huì)獲得一串特殊的值，其實(shí)是靜態(tài)匿名和授權(quán)服務(wù)器獲得的公共匿名和相應(yīng)的證書。在生成參數(shù)，生成證書和生成靜態(tài)匿名后，所有的授權(quán)服務(wù)器和隱私服務(wù)器以及用戶需要到新的隱私服務(wù)器注冊(cè)來獲取密碼，用戶從隱私服務(wù)器獲得的值會(huì)被儲(chǔ)存到安全防護(hù)應(yīng)用程序中。

3.2 基于區(qū)塊鏈智能合約方案的Oauth2.0授權(quán)

（1）區(qū)塊鏈與OAuth2.0結(jié)合的優(yōu)勢(shì)

①使用Oauth2.0進(jìn)行賬戶授權(quán)時(shí)需要聯(lián)網(wǎng)，將Oauth2.0與區(qū)塊鏈支付相結(jié)合就不需要與資源所有者線上進(jìn)行授權(quán)服務(wù)。

②區(qū)塊鏈可以永久記錄在使用Oauth2.0授權(quán)時(shí)產(chǎn)生的哈希算法交易信息，并將授權(quán)方式與加密支付結(jié)合，在發(fā)生沖突時(shí)可以提供無可爭(zhēng)議的收據(jù)。

③智能合約可以以一種無法改變和透明的方式對(duì)條約進(jìn)行編碼，條約基于區(qū)塊鏈支付以及其他物聯(lián)網(wǎng)活動(dòng)內(nèi)容。

④智能合約運(yùn)行在分布式平臺(tái)上，通常涉及調(diào)用成本，因此用智能合約處理訪問請(qǐng)求可以防止引起超高請(qǐng)求率的DoS攻擊。

（2）區(qū)塊鏈與OAuth2.0結(jié)合的流程模型

在本模型中，客戶端和授權(quán)服務(wù)器之間相互的訪問與正常Oauth2.0的框架基本是一致的，但是普通授權(quán)服務(wù)器在用戶同意授權(quán)后會(huì)給客戶端提供授權(quán)憑據(jù)，該模型加入了區(qū)塊鏈，將會(huì)在記錄資源訪問賬單后公開授權(quán)憑據(jù)[9]。因此，資源所有者不需要聯(lián)網(wǎng)就能進(jìn)行像Oauth2.0一樣的授權(quán)模式。

區(qū)塊鏈與OAuth2.0結(jié)合的流程模型如圖3所示，詳解如下。

圖3 區(qū)塊鏈與OAuth2.0結(jié)合的流程模型

①第一步，客戶端以安全的方式從授權(quán)服務(wù)器請(qǐng)求獲取資源，接著授權(quán)服務(wù)器會(huì)生成一個(gè)隨機(jī)的證明密鑰；

②第二步，授權(quán)服務(wù)器將證明密鑰與加密密鑰一起發(fā)送給客戶端，客戶端可以使用證明密鑰與設(shè)備創(chuàng)建一個(gè)安全的溝通鏈接；同時(shí)授權(quán)服務(wù)器給客戶端發(fā)送一個(gè)加密的訪問令牌，密鑰s的哈希值，用密鑰s加密的訪問令牌哈希值，訪問資源所需的價(jià)格[7]。其中，密鑰s是由授權(quán)服務(wù)器隨機(jī)生成的一次性的密鑰，客戶端需要用此密鑰對(duì)授權(quán)服務(wù)器解密來獲取訪問令牌，一旦授權(quán)服務(wù)器確認(rèn)在區(qū)塊鏈上的資源訪問賬單，授權(quán)服務(wù)器將會(huì)顯示密碼[13]。與普通Oauth2.0不一樣的是，該模型中的授權(quán)服務(wù)器不發(fā)生明文訪問令牌，而是發(fā)送加密的訪問令牌，不需要得到用戶的同意即可立即響應(yīng)資源訪問請(qǐng)求。同時(shí)，授權(quán)服務(wù)器會(huì)發(fā)送資源訪問的哈希值和價(jià)格。授權(quán)服務(wù)器到客戶端之間的價(jià)格水平是已經(jīng)被編碼在訪問令牌中的，不同的價(jià)格水平對(duì)應(yīng)不同水平的資源訪問水平。

③到了第三步中，兩個(gè)哈希值被發(fā)送到區(qū)塊鏈中，第一個(gè)哈希值是已經(jīng)被確認(rèn)的授權(quán)服務(wù)器顯示并確認(rèn)的交易賬單；第二個(gè)哈希值由三個(gè)分項(xiàng)目組成，分別是加密的證明密鑰（PoP）、未加密證明密鑰、加密令牌。第二個(gè)哈希值作為授權(quán)服務(wù)器和客戶端之間使用Oauth2.0進(jìn)行通信信息的證明，第二個(gè)哈希值可以在發(fā)生爭(zhēng)議的時(shí)候提供確鑿的交易信息。

④到了第四步后，客戶端需向區(qū)塊鏈存入一定的金額，（第三步創(chuàng)建在區(qū)塊鏈上哈希時(shí)間鎖支付條約）允許客戶端存入與所要求價(jià)格相等的金額。若在一定時(shí)間內(nèi)授權(quán)服務(wù)器將哈希鎖的密碼發(fā)送到智能合約，這筆金額會(huì)返還到資源所有者的賬戶中；若超過時(shí)間限制，用戶可向客戶端申請(qǐng)退款。只要密鑰顯示出來后，客戶端即可從區(qū)塊鏈獲取密鑰解鎖加密令牌進(jìn)而獲取訪問令牌。相較于普通Oauth2.0的授權(quán)模式，區(qū)塊鏈的加入會(huì)使得用戶的信息安全不被偷盜，增強(qiáng)用戶在授權(quán)登錄時(shí)的安全感。

4 未來應(yīng)用分析

目前以匿名化方式提升Oauth2.0安全性的方式還未得到廣泛應(yīng)用，急于需要在用戶設(shè)備中安裝相應(yīng)的安全防護(hù)應(yīng)用程序，絕大多數(shù)用戶并未察覺這一登錄方式帶來的安全隱患，多數(shù)不會(huì)選擇自主安裝這一應(yīng)用程序，原生設(shè)備系統(tǒng)可以針對(duì)這一方案生成相應(yīng)的匿名程序與安全防護(hù)應(yīng)用程序進(jìn)行替換，用戶對(duì)第三方授權(quán)登錄也有自然的過渡，不會(huì)因?yàn)榈讓蛹夹g(shù)的升級(jí)而造成用戶使用的不便；相較于匿名化的方式，區(qū)塊鏈技術(shù)給Oauth2.0帶來的是革命性的升級(jí)，不論是在安全性方面還是在給用戶使用的體驗(yàn)感方面，都會(huì)比匿名化方式更加出色，本身區(qū)塊鏈就可以在離線的狀態(tài)下為用戶進(jìn)行授權(quán)服務(wù)，自身的智能合約模式能為Oauth2.0在發(fā)生沖突時(shí)提供確鑿解決方案數(shù)據(jù)，但區(qū)塊鏈技術(shù)仍待挖掘，這一解決方案為提升Oauth2.0的安全性提供了一個(gè)新思路。

5 結(jié)束語

目前Oauth2.0已成為全球最廣泛應(yīng)用的第三方授權(quán)協(xié)議，在這個(gè)信息化時(shí)代，個(gè)人信息安全雖然已經(jīng)得到了良好的控制，但還是要將各方面的安全漏洞進(jìn)行排解，目前Oauth2.0等委托第三方授權(quán)進(jìn)行登錄的方式亟須科學(xué)技術(shù)手段支持以及國(guó)家安全部門重視?；谙到y(tǒng)科學(xué)視域下的這兩種創(chuàng)新方式對(duì)Oauth2.0安全性進(jìn)行改造升級(jí)，有效為科研人員針對(duì)區(qū)塊鏈技術(shù)研究方向進(jìn)一步探索，具有廣泛的開發(fā)前景。

[1]朱博昌.情報(bào)學(xué)視域下的網(wǎng)站“第三方授權(quán)登錄”安全研究[D].廣西：廣西民族大學(xué)管理學(xué)院，2017：6-21.

[2] Liu Xing，Liu Jiqiang，Wang Wei, et al.Android single sign-on security：Issues，taxonomy and directions[J]. Future Generation Computer Systems，2018：0167-739X.

[3]Victor Sucasas，Georgios Mantas，Saud Althunibat, et al.A privacy-enhanced OAuth 2.0 based protocol for Smart City mobile applications[J].ScienceDirect，2018：258-274.

[4]H.Wang，Y.Zhang，J.Li，et al.Vulnerability assessment of OAuth implementations in android applications[C].Proceeding of the 31stAnnual Computer Security Application Conference，ACM，2015：61-70.

[5]A.P. Felt，D.Wagner.Phishing on mobile devices，Web 2.0 Security and Privacy[C].W2SP 2011，2011.

[6]Hui W，Yuanyuan Z，Juanru L,et al，Vulnerability Assessment of OAuth Implementations in Android Applications[C]. Proceedings of the 31stAnnual Computer Security Applications Conference，2015:61-70.

[7] Vasilios A S，Dimitrios，Nikos Fotiou ,et al. Decentralized authorization in constrained IoT environments exploiting interledger mechanisms[J].Computer Communications，2020

[8] M. Shehab，F(xiàn). Mohsen.Towards enhancing the security of OAuth implementations in smartphones，in Mobile Services，MS[C].2014 IEEE International Conference on，IEEE，2014，pp. 39–46.

[9]Vasilios A.S，D.Dimopoulos，Nikos Fotiou, et al.OAuth2.0 meets Blockchain for Authorization in Constrained IoT Environments[J].IEEE，2019:15-18.

[10]Seiamak Vahid and Rahim. Tafazolli ControlChain： Blockchain as a central enabler for access control authorizations in the IoT[J].IEEE，2017.

[11]Xinyi H，Yi M，Willy S，et al.A Short Proxy Signature Scheme：Efficient Authentication in the Ubiquitous World[C].IFIP International Federation for Information Processing，2005:480-489.

[12]Jan C，Anna L.An efficient system for non-transferable anonymous credentials with optional anonymity revocation[J].Springer-Verlag Berlin Heidelberg，2001:93-118.

[13]Nikos F，Iakovos P，Vasilios A.S.OAuth 2.0 authorization using blockchain-based Tokens.

[14]Yuanyu Z，Shoji K，Yulong S ,et al.Smart Contract-Based Access Control for the Internet of Things[J].IEEE.

廣東理工學(xué)院自然科學(xué)項(xiàng)目（2019GKJZK017）