本發(fā)明涉及移動通訊領域，特別是涉及一種資源授權(quán)方法及裝置。

背景技術(shù)：

oauth是一個關(guān)于授權(quán)(authorization)的開放網(wǎng)絡標準，在全世界得到廣泛應用，目前的版本是2.0版。oauth在"第三方應用"與"服務提供商"之間，設置了一個授權(quán)層(authorizationlayer)。"第三方應用"不能直接登錄"服務提供商"，只能登錄授權(quán)層，以此將用戶與第三方應用區(qū)分開來。"第三方應用"登錄授權(quán)層所用的令牌(token)，與用戶的密碼不同。用戶可以在登錄的時候，設置授權(quán)令牌的權(quán)限范圍和有效期。

"第三方應用"登錄授權(quán)層以后，"服務提供商"根據(jù)令牌的權(quán)限范圍和有效期，向"第三方應用"開放用戶儲存的資料。在現(xiàn)有技術(shù)中，一般授權(quán)流程如下：

步驟1，用戶打開第三方應用以后，第三方應用要求用戶給予授權(quán)。

步驟2，用戶同意給予第三方應用授權(quán)。

步驟3，第三方應用使用上一步獲得的授權(quán)，向認證服務器申請令牌。

步驟4，認證服務器對第三方應用進行認證以后，確認無誤，同意發(fā)放令牌。

步驟5，第三方應用使用令牌，向資源服務器申請獲取資源。

步驟6，資源服務器確認令牌無誤，同意向第三方應用開放資源。

從上述處理過程可以看出，上述方案中第三方應用一旦獲取令牌以后，在有效期限以內(nèi)可以任意訪問相應的資源。因此在授權(quán)訪問資源的這一環(huán)節(jié)，oauth協(xié)議框架存在以下一些不安全的因素：

1、第三方在引導用戶授權(quán)時，認證服務器往往對要求的權(quán)限描述不是非 常清晰，細節(jié)不明，一般用戶往往在沒有完全理解風險的基礎上就選擇了同意。

2、第三方在本次使用完相應的資源后，仍然持有該訪問令牌，在有效期內(nèi)可以在用戶完全不知情的情況下繼續(xù)使用一些用戶資源，侵犯了用戶相關(guān)權(quán)益。例如，第三方獲取某用戶的好友列表資源，然后在該用戶不知情的情況下向好友群發(fā)廣告郵件等。

技術(shù)實現(xiàn)要素：

鑒于現(xiàn)有技術(shù)中第三方應用在濫用授權(quán)的問題，提出了本發(fā)明以便提供一種克服上述問題或者至少部分地解決上述問題的資源授權(quán)方法及裝置。

本發(fā)明提供一種資源授權(quán)方法，包括：

接收第三方應用的授權(quán)訪問請求，并引導用戶對第三方應用進行授權(quán)，根據(jù)用戶的授權(quán)結(jié)果向第三方應用發(fā)送令牌；

接收第三方應用發(fā)送的攜帶有令牌的用戶資源訪問請求，對令牌進行驗證，在驗證通過后，根據(jù)用戶資源訪問請求確定第三方應用所訪問的用戶資源是否為屬于預先規(guī)定的敏感資源；

在確定第三方應用所訪問的用戶資源為敏感資源時，向用戶發(fā)送是否授權(quán)第三方應用獲取敏感資源的請求，接收用戶的授權(quán)應答，根據(jù)授權(quán)應答確定是否將敏感資源返回給第三方應用。

本發(fā)明還提供了一種資源授權(quán)裝置，設置于服務提供商的服務器，包括：

令牌模塊，用于接收第三方應用的授權(quán)訪問請求，并引導用戶對第三方應用進行授權(quán)，根據(jù)用戶的授權(quán)結(jié)果向第三方應用發(fā)送令牌；

確定模塊，用于接收第三方應用發(fā)送的攜帶有令牌的用戶資源訪問請求，對令牌進行驗證，在驗證通過后，根據(jù)用戶資源訪問請求確定第三方應用所訪問的用戶資源是否為屬于預先規(guī)定的敏感資源；

授權(quán)請求模塊，用于在確定第三方應用所訪問的用戶資源為敏感資源時，向用戶發(fā)送是否授權(quán)第三方應用獲取敏感資源的請求，接收用戶的授權(quán)應答， 根據(jù)授權(quán)應答確定是否將敏感資源返回給第三方應用。

本發(fā)明有益效果如下：

通過在資源訪問真正發(fā)生時，給用戶以更加明確的通知信息，解決了現(xiàn)有技術(shù)中第三方應用在濫用授權(quán)的問題，能夠有效防止了第三方在后臺濫用授權(quán)。

上述說明僅是本發(fā)明技術(shù)方案的概述，為了能夠更清楚了解本發(fā)明的技術(shù)手段，而可依照說明書的內(nèi)容予以實施，并且為了讓本發(fā)明的上述和其它目的、特征和優(yōu)點能夠更明顯易懂，以下特舉本發(fā)明的具體實施方式。

附圖說明

通過閱讀下文優(yōu)選實施方式的詳細描述，各種其他的優(yōu)點和益處對于本領域普通技術(shù)人員將變得清楚明了。附圖僅用于示出優(yōu)選實施方式的目的，而并不認為是對本發(fā)明的限制。而且在整個附圖中，用相同的參考符號表示相同的部件。在附圖中：

圖1是本發(fā)明實施例的資源授權(quán)方法的流程圖；

圖2是本發(fā)明實施例的資源授權(quán)方法的信令流程圖；

圖3是本發(fā)明實施例的資源授權(quán)方法的優(yōu)選實例的信令流程圖；

圖4是本發(fā)明實施例的資源授權(quán)裝置的結(jié)構(gòu)示意圖。

具體實施方式

下面將參照附圖更詳細地描述本公開的示例性實施例。雖然附圖中顯示了本公開的示例性實施例，然而應當理解，可以以各種形式實現(xiàn)本公開而不應被這里闡述的實施例所限制。相反，提供這些實施例是為了能夠更透徹地理解本公開，并且能夠?qū)⒈竟_的范圍完整的傳達給本領域的技術(shù)人員。

為防止第三方應用在事后濫用授權(quán)，本發(fā)明實施例提供了一種資源授權(quán)方法及裝置，當?shù)谌綉贸至钆圃L問資源服務器時，服務器需要對訪問內(nèi)容加 以甄別，如訪問較高級別的敏感資源時，以短信，推送(push)消息，電子郵件等方式告知用戶。用戶以規(guī)定的授權(quán)方式回應后，資源服務器才能允許第三方繼續(xù)訪問資源。規(guī)定的授權(quán)方式可以有一次授權(quán)，多次授權(quán)，限期內(nèi)永久授權(quán)，限時授權(quán)等。以下結(jié)合附圖以及實施例，對本發(fā)明進行進一步詳細說明。應當理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不限定本發(fā)明。

方法實施例

根據(jù)本發(fā)明的實施例，提供了一種資源授權(quán)方法，圖1是本發(fā)明實施例的資源授權(quán)方法的流程圖，如圖1所示，根據(jù)本發(fā)明實施例的資源授權(quán)方法包括如下處理：

步驟101，接收第三方應用的授權(quán)訪問請求，并引導用戶對第三方應用進行授權(quán)，根據(jù)用戶的授權(quán)結(jié)果向第三方應用發(fā)送令牌；其中，可以根據(jù)oauth協(xié)議引導用戶對第三方應用進行授權(quán)。

步驟102，接收第三方應用發(fā)送的攜帶有令牌的用戶資源訪問請求，對令牌進行驗證，在驗證通過后，根據(jù)用戶資源訪問請求確定第三方應用所訪問的用戶資源是否為屬于預先規(guī)定的敏感資源；

步驟103，在確定第三方應用所訪問的用戶資源為敏感資源時，向用戶發(fā)送是否授權(quán)第三方應用獲取敏感資源的請求，接收用戶的授權(quán)應答，根據(jù)授權(quán)應答確定是否將敏感資源返回給第三方應用。

優(yōu)選地，是否授權(quán)第三方應用獲取敏感資源的請求具體包括：敏感資源的詳細信息、安全級別、以及是否授權(quán)的請求；授權(quán)應答具體包括：同意或拒絕授權(quán)、以及授權(quán)方式，其中，授權(quán)方式包括：一次同意或拒絕授權(quán)、多次同意或拒絕授權(quán)、以及限時同意或拒絕授權(quán)。

其中，在步驟103中，在確定第三方應用所訪問的用戶資源為敏感資源時，可以將第三方應用發(fā)送的用戶資源訪問請求掛起；或者，向第三方應用返回等待響應。

在步驟103中，根據(jù)授權(quán)應答確定是否將敏感資源返回給第三方應用具體 包括：如果用戶的授權(quán)應答為同意授權(quán)，則將敏感資源返回給第三方應用；如果用戶的授權(quán)應答為拒絕授權(quán)，則將拒絕授權(quán)響應返回給第三方應用。

在本發(fā)明實施例中，在確定第三方應用所訪問的用戶資源不是敏感資源時，將第三方應用所請求的用戶資源返回給第三方應用。

向用戶發(fā)送是否授權(quán)第三方應用獲取敏感資源的請求之后，如果在預定時間內(nèi)沒有收到用戶返回的授權(quán)應答，則默認用戶拒絕授權(quán)。

以下結(jié)合附圖，對本發(fā)明實施例的上述技術(shù)方案進行詳細說明。

圖2是本發(fā)明實施例的資源授權(quán)方法的信令流程圖，如圖2所示，具體包括如下處理：

步驟201，第三方應用請求服務提供者進行授權(quán)；

步驟202，按oauth協(xié)議引導用戶授權(quán)后，服務提供者返回給第三方應用一個令牌；

步驟203，第三方應用使用此令牌向服務提供者請求訪問用戶的相關(guān)資源；

步驟204，服務提供者判斷此次訪問的用戶資源是否為敏感資源，如果不是敏感資源，直接返回資源給第三方。如果是敏感資源，將掛起該訪問請求或返回給第三方一個需要等待的響應；

步驟205，對于敏感資源，服務提供者將通過各種通道告知用戶詳細的第三方應用請求信息，指明安全級別，要求用戶再次確認同意或拒絕該授權(quán)；

步驟206，用戶從服務提供者收到該信息后需要進行應答，同意或拒絕授權(quán)，如果用戶一段時間內(nèi)沒有任何響應，則默認為拒絕授權(quán)；用戶在同意和拒絕時可根據(jù)提示做出特定授權(quán)應答，如一次授權(quán)，多次授權(quán)，限期內(nèi)永久授權(quán)，限時授權(quán)等方式；

步驟207，服務提供者根據(jù)用戶的應答情況，對第三方進行回復。如用戶同意授權(quán)則返回相應資源，否則回復userdennied等類似響應。

以下結(jié)合實例，對本發(fā)明實施例的上述技術(shù)方案進行舉例說明。

圖3是本發(fā)明實施例的資源授權(quán)方法的優(yōu)選實例的信令流程圖，如圖3所 示，具體包括如下處理：

步驟301，第三方應用向im服務提供商請求授權(quán)訪問某手機用戶的相關(guān)信息；

步驟302，第三方應用按oauth協(xié)議打開瀏覽器，訪問im服務提供商的用戶登錄授權(quán)頁面。引導用戶登錄并授權(quán)后，返回給第三方應用一個令牌；

步驟303，第三方應用使用該令牌請求訪問該im用戶的相關(guān)信息資源，如該用戶的好友信息；

步驟304，im服務提供商判斷此次訪問的用戶資源是否為敏感資源，比如此時訪問的是該用戶的基本資料，如昵稱，id等，則直接授權(quán)給第三方。如果訪問的是im好友的信息等敏感資源，則將掛起該訪問請求或返回給第三方一個需要等待的響應；

步驟305，對于im好友信息等敏感資源，im服務提供商將通過各種可選通道，如短信，push，email等告知用戶詳細的請求情況，指明有可能涉及到哪些安全因素，要求用戶再次確認同意或拒絕該授權(quán)；

步驟306，用戶通過短信等方式收到請求后，再通過回復短信等方式告知im服務提供商同意或拒絕授權(quán)。如果用戶一段時間內(nèi)沒有任何響應，則默認為拒絕授權(quán)；用戶在同意和拒絕時可根據(jù)提示做出特定授權(quán)應答，如一次授權(quán)，多次授權(quán)，限期內(nèi)永久授權(quán)，限時授權(quán)等方式；

步驟307，im服務提供商根據(jù)用戶的應答情況，對第三方應用進行回復。如用戶同意授權(quán)則返回相應資源，否則回復userdennied；

綜上所述，借助于本發(fā)明實施例的技術(shù)方案，通過在資源訪問真正發(fā)生時，給用戶以更加明確的通知信息，解決了現(xiàn)有技術(shù)中第三方應用在濫用授權(quán)的問題，能夠使用戶可以更加靈活地選擇使用多種授權(quán)方式，從而有效防止了第三方在后臺濫用授權(quán)。

裝置實施例

根據(jù)本發(fā)明的實施例，提供了一種資源授權(quán)裝置，設置于服務提供商的服 務器，圖4是本發(fā)明實施例的資源授權(quán)裝置的結(jié)構(gòu)示意圖，如圖4所示，根據(jù)本發(fā)明實施例的資源授權(quán)裝置包括：令牌模塊40、確定模塊42、以及授權(quán)請求模塊44，以下對本發(fā)明實施例的各個模塊進行詳細的說明。

令牌模塊40，用于接收第三方應用的授權(quán)訪問請求，并引導用戶對第三方應用進行授權(quán)，根據(jù)用戶的授權(quán)結(jié)果向第三方應用發(fā)送令牌；令牌模塊40具體用于：根據(jù)oauth協(xié)議引導用戶對第三方應用進行授權(quán)。

確定模塊42，用于接收第三方應用發(fā)送的攜帶有令牌的用戶資源訪問請求，對令牌進行驗證，在驗證通過后，根據(jù)用戶資源訪問請求確定第三方應用所訪問的用戶資源是否為屬于預先規(guī)定的敏感資源；

授權(quán)請求模塊44，用于在確定第三方應用所訪問的用戶資源為敏感資源時，向用戶發(fā)送是否授權(quán)第三方應用獲取敏感資源的請求，接收用戶的授權(quán)應答，根據(jù)授權(quán)應答確定是否將敏感資源返回給第三方應用。

其中，是否授權(quán)第三方應用獲取敏感資源的請求具體包括：敏感資源的詳細信息、安全級別、以及是否授權(quán)的請求；授權(quán)應答具體包括：同意或拒絕授權(quán)、以及授權(quán)方式，其中，授權(quán)方式包括：一次同意或拒絕授權(quán)、多次同意或拒絕授權(quán)、以及限時同意或拒絕授權(quán)。

授權(quán)請求模塊44具體用于：如果用戶的授權(quán)應答為同意授權(quán)，則將敏感資源返回給第三方應用；如果用戶的授權(quán)應答為拒絕授權(quán)，則將拒絕授權(quán)響應返回給第三方應用。

授權(quán)請求模塊44進一步用于：將第三方應用發(fā)送的用戶資源訪問請求掛起；或者，向第三方應用返回等待響應。在確定模塊42確定第三方應用所訪問的用戶資源不是敏感資源時，將第三方應用所請求的用戶資源返回給第三方應用。向用戶發(fā)送是否授權(quán)第三方應用獲取敏感資源的請求之后，如果在預定時間內(nèi)沒有收到用戶返回的授權(quán)應答，則默認用戶拒絕授權(quán)。

綜上所述，借助于本發(fā)明實施例的技術(shù)方案，通過在資源訪問真正發(fā)生時，給用戶以更加明確的通知信息，解決了現(xiàn)有技術(shù)中第三方應用在濫用授權(quán)的問 題，能夠使用戶可以更加靈活地選擇使用多種授權(quán)方式，從而有效防止了第三方在后臺濫用授權(quán)。

顯然，本領域的技術(shù)人員可以對本發(fā)明進行各種改動和變型而不脫離本發(fā)明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權(quán)利要求及其等同技術(shù)的范圍之內(nèi)，則本發(fā)明也意圖包含這些改動和變型在內(nèi)。

在此提供的算法和顯示不與任何特定計算機、虛擬系統(tǒng)或者其它設備固有相關(guān)。各種通用系統(tǒng)也可以與基于在此的示教一起使用。根據(jù)上面的描述，構(gòu)造這類系統(tǒng)所要求的結(jié)構(gòu)是顯而易見的。此外，本發(fā)明也不針對任何特定編程語言。應當明白，可以利用各種編程語言實現(xiàn)在此描述的本發(fā)明的內(nèi)容，并且上面對特定語言所做的描述是為了披露本發(fā)明的最佳實施方式。

在此處所提供的說明書中，說明了大量具體細節(jié)。然而，能夠理解，本發(fā)明的實施例可以在沒有這些具體細節(jié)的情況下實踐。在一些實例中，并未詳細示出公知的方法、結(jié)構(gòu)和技術(shù)，以便不模糊對本說明書的理解。

類似地，應當理解，為了精簡本公開并幫助理解各個發(fā)明方面中的一個或多個，在上面對本發(fā)明的示例性實施例的描述中，本發(fā)明的各個特征有時被一起分組到單個實施例、圖、或者對其的描述中。然而，并不應將該公開的方法解釋成反映如下意圖：即所要求保護的本發(fā)明要求比在每個權(quán)利要求中所明確記載的特征更多的特征。更確切地說，如下面的權(quán)利要求書所反映的那樣，發(fā)明方面在于少于前面公開的單個實施例的所有特征。因此，遵循具體實施方式的權(quán)利要求書由此明確地并入該具體實施方式，其中每個權(quán)利要求本身都作為本發(fā)明的單獨實施例。

本領域那些技術(shù)人員可以理解，可以對實施例中的客戶端中的模塊進行自適應性地改變并且把它們設置在與該實施例不同的一個或多個客戶端中?？梢园褜嵤├械哪K組合成一個模塊，以及此外可以把它們分成多個子模塊或子單元或子組件。除了這樣的特征和/或過程或者單元中的至少一些是相互排斥之外，可以采用任何組合對本說明書(包括伴隨的權(quán)利要求、摘要和附圖)中公 開的所有特征以及如此公開的任何方法或者客戶端的所有過程或單元進行組合。除非另外明確陳述，本說明書(包括伴隨的權(quán)利要求、摘要和附圖)中公開的每個特征可以由提供相同、等同或相似目的的替代特征來代替。

此外，本領域的技術(shù)人員能夠理解，盡管在此所述的一些實施例包括其它實施例中所包括的某些特征而不是其它特征，但是不同實施例的特征的組合意味著處于本發(fā)明的范圍之內(nèi)并且形成不同的實施例。例如，在下面的權(quán)利要求書中，所要求保護的實施例的任意之一都可以以任意的組合方式來使用。

本發(fā)明的各個部件實施例可以以硬件實現(xiàn)，或者以在一個或者多個處理器上運行的軟件模塊實現(xiàn)，或者以它們的組合實現(xiàn)。本領域的技術(shù)人員應當理解，可以在實踐中使用微處理器或者數(shù)字信號處理器(dsp)來實現(xiàn)根據(jù)本發(fā)明實施例的加載有排序網(wǎng)址的客戶端中的一些或者全部部件的一些或者全部功能。本發(fā)明還可以實現(xiàn)為用于執(zhí)行這里所描述的方法的一部分或者全部的設備或者裝置程序(例如，計算機程序和計算機程序產(chǎn)品)。這樣的實現(xiàn)本發(fā)明的程序可以存儲在計算機可讀介質(zhì)上，或者可以具有一個或者多個信號的形式。這樣的信號可以從因特網(wǎng)網(wǎng)站上下載得到，或者在載體信號上提供，或者以任何其他形式提供。

應該注意的是上述實施例對本發(fā)明進行說明而不是對本發(fā)明進行限制，并且本領域技術(shù)人員在不脫離所附權(quán)利要求的范圍的情況下可設計出替換實施例。在權(quán)利要求中，不應將位于括號之間的任何參考符號構(gòu)造成對權(quán)利要求的限制。單詞“包含”不排除存在未列在權(quán)利要求中的元件或步驟。位于元件之前的單詞“一”或“一個”不排除存在多個這樣的元件。本發(fā)明可以借助于包括有若干不同元件的硬件以及借助于適當編程的計算機來實現(xiàn)。在列舉了若干裝置的單元權(quán)利要求中，這些裝置中的若干個可以是通過同一個硬件項來具體體現(xiàn)。單詞第一、第二、以及第三等的使用不表示任何順序?？蓪⑦@些單詞解釋為名稱。