專利名稱：一種開放鑒權應用程序接口代理的方法、裝置及系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及計算機通信技術領域，特別涉及一種開放鑒權應用程序接口代理的方法、裝置及系統(tǒng)。
背景技術：
開放鑒權應用程序接口(OAuth, An open protocol to allow secureAPI authorization in a simple and standard method from desktop and webapplications)標準作為目前業(yè)界最為流行的第三方應用程序接口(API)鑒權授權訪問協(xié)議已在互聯(lián)網(wǎng)上廣泛使用，該OAuth標準能夠讓客戶端在不暴露客戶端密鑰的情況下將客戶端在某個服務提供商保存的隱私信息暴露給第三方應用，例如新浪sina微博，豆瓣，google等均基于OAuth標準發(fā)布了各種應用程序接口 API，極大的豐富了互聯(lián)網(wǎng)的開放環(huán)境，基于OAuth的代理需求也隨之顯現(xiàn)出來?，F(xiàn)有技術中，OAuth消費者(OAuth consumer)先在OAuth服務提供商(OAuthprovider)上注冊自己的應用信息,被授權后,可以直接與OAuth服務提供商進行交互,獲取需要客戶端授權的隱私信息。但是，在實際應用中，很可能OAuth consumer無法直接和OAuth provider進行交互,需要代理才能訪問OAuth provider上保存的資源,例如互聯(lián)網(wǎng)上眾多的短信批發(fā)商和彩信批發(fā)商，作為短信API的代理接收第三方應用的請求，并將請求轉發(fā)給運營商的短信網(wǎng)關。在對現(xiàn)有技術的研究和實踐過程中，本發(fā)明的發(fā)明人發(fā)現(xiàn)，現(xiàn)有的實現(xiàn)方式中，客戶端在訪問多種服務提供商提供的服務時，需要在每個OAuth provider上注冊自己的應用信息，實現(xiàn)比較復雜；同時，客戶端授權 時，被授權的第三方應用和授權頁面上展示的應用名稱可能不一致，從而導致客戶端混淆的問題。

發(fā)明內(nèi)容
本發(fā)明實施例提供一種開放鑒權應用程序接口代理的方法、裝置及系統(tǒng)，以簡化客戶端訪問服務提供商提供的服務，以及被授權的第三方應用和授權頁面上展示的應用名稱可能不一致的技術問題。為解決上述技術問題，本發(fā)明實施例提供一種開放鑒權應用程序接口 OAuth代理的方法，包括:接收第三方應用發(fā)送的獲取請求令牌的請求消息；根據(jù)所述請求令牌的請求消息中的Oauth提供商字段查詢到Oauth提供商為Oauth代理發(fā)布的安全密鑰對及其請求令牌統(tǒng)一資源定位符；利用所述安全密鑰對所述獲取請求令牌的請求消息進行簽名后，從所述獲取請求令牌的請求消息對應的請求令牌統(tǒng)一資源定位符上獲取請求令牌；向所述第三方應用發(fā)送包括請求令牌的響應消息；接收所述第三方應用發(fā)送的獲取訪問令牌的請求消息；
根據(jù)所述訪問令牌的請求消息中的Oauth提供商字段查詢到Oauth提供商為Oauth代理發(fā)布的安全密鑰對及其請求令牌統(tǒng)一資源定位符；利用所述安全密鑰和請求令牌對所述獲取訪問令牌的請求消息進行簽名后，從所述獲取訪問令牌的請求消息對應的訪問令牌統(tǒng)一資源定位符上獲取訪問令牌；向所述第三方應用發(fā)送包括訪問令牌的響應消息；接收第三方應用發(fā)送的客戶端資源訪問請求；根據(jù)所述訪問令牌對所述客戶端資源訪問請求進行簽名后，向所述客戶端資源訪問請求對應的OAuth提供商發(fā)起客戶端資源訪問請求；接收所述OAuth提供商發(fā)送的客戶端資源訪問響應；將所述客戶端資源訪問響應發(fā)送給第三方應用。相應的，本發(fā)明實施例提供一種開放鑒權應用程序接口 OAuth代理裝置，包括:第一接收單元，用于接收第三方應用發(fā)送的獲取請求令牌的請求消息；第一查詢單元，用于根據(jù)所述請求令牌的請求消息中的Oauth提供商字段查詢到Oauth提供商為oauth代理發(fā)布的消費者密鑰對及其請求令牌統(tǒng)一資源定位符；

第一獲取單元，用于利用所述安全密鑰對所述獲取請求令牌的請求消息進行簽名后，從所述獲取請求令牌的請求消息對應的請求令牌統(tǒng)一資源定位符上獲取請求令牌；第一發(fā)送單元，用于向所述第三方應用發(fā)送包括請求令牌的響應消息；第二接收單元，用于接收所述第三方應用發(fā)送的獲取訪問令牌的請求消息；第二查詢單元，用于根據(jù)所述訪問令牌的請求消息中的Oauth提供商字段查詢到Oauth提供商為oauth代理發(fā)布的安全密鑰鑰對及其請求令牌統(tǒng)一資源定位符；第二獲取單元，用于利用所述安全密鑰和請求令牌對所述獲取訪問令牌的請求消息進行重新簽名后，從所述獲取訪問令牌的請求消息對應的訪問令牌統(tǒng)一資源定位符上獲取訪問令牌；第二發(fā)送單元，用于向所述第三方應用發(fā)送包括訪問令牌的響應消息；第三接收單元，用于接收第三方應用發(fā)送的客戶端資源訪問請求；資源請求單元，用于根據(jù)所述訪問令牌對所述客戶端資源訪問請求進行重新簽名后，向所述客戶端資源訪問請求對應的OAuth提供商發(fā)起客戶端資源訪問請求；資源接收單元，用于接收所述OAuth提供商的發(fā)送的客戶端資源訪問響應；第三發(fā)送單元，用于向第三方應用發(fā)送所述客戶端資源訪問響應。本發(fā)明實施例還提供一種開放鑒權應用程序接口 OAuth代理系統(tǒng)，包括:第三方應用、OAuth代理裝置和OAuth提供商，其中，所述第三方應用，用于將接收到客戶端發(fā)送的獲取請求令牌的請求消息轉發(fā)給所述OAuth代理裝置；接收所述OAuth代理裝置發(fā)送的包括請求令牌的響應消息；以及將接收到客戶端發(fā)送的獲取訪問令牌的請求消息轉發(fā)給OAuth代理裝置；接收所述OAuth代理裝置發(fā)送的包括訪問令牌的響應消息；以及，向所述OAuth代理裝置發(fā)送客戶端資源訪問請求；接收所述OAuth代理裝置發(fā)送的客戶端資源訪問響應；所述OAuth代理裝置，用于接收客戶端通過第三方應用發(fā)送的獲取請求令牌的請求消息；根據(jù)所述請求令牌的請求消息中的Oauth提供商字段查詢到Oauth提供商為Oauth代理發(fā)布的安全密鑰對及其請求令牌統(tǒng)一資源定位符；利用所述安全密鑰對所述獲取請求令牌的請求消息進行簽名后，從所述獲取請求令牌的請求消息對應的請求令牌統(tǒng)一資源定位符上獲取請求令牌；向所述第三方應用發(fā)送包括請求令牌的響應消息；接收所述第三方應用發(fā)送的獲取訪問令牌的請求消息；根據(jù)所述訪問令牌的請求消息中的Oauth提供商字段查詢到Oauth提供商為Oauth代理發(fā)布的安全密鑰對及其請求令牌統(tǒng)一資源定位符；利用所述安全密鑰和請求令牌對所述獲取訪問令牌的請求消息進行重新簽名后，從所述獲取訪問令牌的請求消息對應的訪問令牌統(tǒng)一資源定位符上獲取訪問令牌；向所述第三方應用發(fā)送包括訪問令牌的響應消息；接收第三方應用發(fā)送的客戶端資源訪問請求；根據(jù)所述訪問令牌對所述客戶端資源訪問請求進行重新簽名后，向所述客戶端資源訪問請求對應的OAuth提供商發(fā)起客戶端資源訪問請求；接收所述OAuth提供商的發(fā)送的客戶端資源訪問響應，并將所述客戶端資源訪問響應發(fā)送給第三方應用。由上述技術方案可知,本發(fā)明實施例中，通過代理OAuth provider提供的資源，由于代理暴露的接口也遵循OAuthl.0a標準，應用開發(fā)者可以重用已有的各種OAuth客戶端庫，而且應用只需要通過OAuth代理即可訪問后面多種被代理的OAuth provider提供的服務，而不需要在每個OAuth provider上注冊,簡化了第三方應用的開發(fā)，同時本方案通過兩次重定向的機制解決了在客戶端授權階段被授權應用(OAuth代理)與客戶端實際使用應用(第三方應用)不一致導致客戶端困惑的問題，提高了客戶端的體驗。


圖1為本發(fā)明實施例提供的一種開放鑒權應用程序接口代理的方法的流程圖；圖2為本發(fā)明實施例提供的一種開放鑒權應用程序接口代理裝置的結構示意圖；圖3為本發(fā)明實施例 提供的一種開放鑒權應用程序接口代理裝置的另一結構示意圖；圖4為本發(fā)明實施例提供的一種開放鑒權應用程序接口代理系統(tǒng)的結構示意圖；圖5為本發(fā)明實施例提供的第一實施例的流程圖；圖6為本發(fā)明實施例提供的第二實施例的流程圖。
具體實施例方式本發(fā)明實施例主要提供一種開放的鑒權應用程序接口(0Auth,An open protocolto allow secure API authorization in a simple and standard method from desktopand web applications)代理的方法、裝置以及OAuth代理，在這種代理機制下，只需通過OAuth代理提供的安全密鑰對(消費密者鑰鍵consumer key,消費者密鑰consumersecret),對于第三方應用即可訪問OAuth代理后的各種OAuth提供商(OAuth provider)提供的資源，而不需要在每個OAuth provider上注冊自己的應用信息，簡化了第三方應用的開發(fā)的技術問題。同時，本發(fā)明實施例提供的代理機制暴露出去的接口仍然是滿足OAuth標準規(guī)范的，從而保證了已有的各種OAuth客戶端數(shù)據(jù)庫可以被重用，也提供了開發(fā)者友好性。進一步，本發(fā)明實施例還解決了在OAuth代理模式下，對于OAuth provider,OAuth代理才是OAuth的消費者(OAuth consumer),客戶端授權時,被授權的第三方應用和授權頁面上展示的應用名稱不一致導致客戶端混淆的情況，提高了客戶端的體驗度。
為了使本技術領域的人員更好地理解本發(fā)明實施例的方案，下面結合附圖和實施方式對本發(fā)明實施例作進一步的詳細說明。請參閱圖1，為本發(fā)明實施例提供的一種開放鑒權應用程序接口代理的方法的流程圖。在該實施例中，代理OAuth provider的多種應用，并對外提供OAuthl.0a標準的服務。在該實例中，客戶端需要先在OAuth代理注冊，也就是說，該客戶端為OAuth代理的注冊客戶端。所述方法包括:步驟101:接收客戶端通過第三方應用發(fā)送的獲取請求令牌的請求消息；客戶端訪問第三方應用，并觸發(fā)應用需要訪問客戶端在某個OAuth提供商上存儲的客戶端隱私數(shù)據(jù)，第三方應用向OAuth代理(OAuth proxy)發(fā)送獲取請求令牌的請求消
息
步驟102:根據(jù)所述請求令牌的請求消息中的Oauth提供商字段查詢到Oauth提供商為Oauth代理發(fā)布的安全密鑰對及其請求令牌統(tǒng)一資源定位符；步驟103:利用所述安全密鑰對所述獲取請求令牌的請求消息進行簽名后，從所述獲取請求令牌的請求消息對應的請求令牌統(tǒng)一資源定位符上獲取請求令牌；也就是說，OAuth代理根據(jù)所述OAuth提供商發(fā)布的安全密鑰(比如消費者密鑰鍵、消費者密鑰)對所述獲取請求令牌的請求消息進行重新簽名；將重新簽名后的獲取請求令牌的請求消息發(fā)送給OAuth提供商；接收所述OAuth提供商發(fā)送的包括請求令牌的響應消息；存儲所述請求令牌與所述第三方應用和OAuth提供商的映射關系。其中，一種重新簽名方式是=OAuth代理可以根據(jù)所述OAuth提供商發(fā)布的安全密鑰(消費者密鑰鍵consumer key,消費者密鑰consumer secret)對所述請求消息進行重新簽名，之后，將重新簽名的后請求消息發(fā)送給OAuth提供商，以請求獲取請求令牌；以及OAuth代理接收到OAuth提供商反饋的包括請求令牌的響應消息。之后，OAuth代理存儲接收到的所述請求令牌，與第三方應用和OAuth提供商之間的映射關系，所述請求令牌包括:密鑰鍵和密鑰，但并不限于此步驟104:向所述第三方應用發(fā)送包括請求令牌的響應消息；該步驟以便于所述第三方應用根據(jù)所述請求令牌將客戶端重定向到OAuth代理提供的指示頁面或OAuth提供商提供的客戶端統(tǒng)一資源定位符上；在該實施例中，第三方應用在接收到包括請求令牌的響應消息后，可以根據(jù)所述請求令牌將客戶端重定向到OAuth代理提供的指示頁面上；或者將客戶端重定向到OAuth提供商提供的客戶端統(tǒng)一資源定位符上。本實施例以重定向OAuth提供商提供的客戶端統(tǒng)一資源定位符為例進行說明。也就是說，OAuth代理將獲取到的所述請求令牌發(fā)送給第三方應用，第三方應用在接收到所述請求令牌后，將客戶端重定向OAuth代理提供的指示頁面上，或者將客戶端直接重定向到OAuth提供商提供的客戶端授權頁面上。步驟105:接收所述第三方應用發(fā)送的獲取訪問令牌的請求消息；其中，所述請求消息可以包括:消費者密鑰鍵和請求令牌鍵；但并不限于此。步驟106:根據(jù)所述訪問令牌的請求消息中的Oauth提供商字段查詢到Oauth提供商為Oauth代理發(fā)布的安全密鑰對及其請求令牌統(tǒng)一資源定位符；也就是說，OAuth代理根據(jù)所述獲取訪問令牌的請求消息中的消費者密鑰鍵和請求令牌鍵查找到對應的OAuth提供商和訪問令牌統(tǒng)一資源定位符。步驟107:利用所述安全密鑰和請求令牌對所述獲取訪問令牌的請求消息進行重新簽名后，從所述獲取訪問令牌的請求消息對應的訪問令牌統(tǒng)一資源定位符上獲取訪問令牌；一種具體的實施方式為:0Auth代理根據(jù)所述OAuth提供商為Oauth代理布發(fā)布的安全密鑰和請求令牌對所述獲取訪問令牌的請求消息進行重新簽名；將重新簽名后的獲取訪問令牌的請求消息發(fā)送給所述OAuth提供商；接收所述OAuth提供商發(fā)送的包括訪問令牌的響應消息；存儲所述訪問令牌與所述第三方應用和OAuth提供商的映射關系。步驟108:向所述第三方應用發(fā)送包括訪問令牌的響應消息；步驟109:接收第三方應用發(fā)送的客戶端資源訪問請求；步驟110:根據(jù)所述訪問令牌對所述客戶端資源訪問請求進行簽名后，向所述客戶端資源訪問請求對應的OAuth提供商發(fā)起客戶端資源訪問請求；在接收第三方應用發(fā)送的客戶端資源訪問請求后，OAuth代理根據(jù)所述OAuth提供商提供的安全密鑰(比如消費者密 鑰鍵、消費者密鑰)和訪問令牌對所述客戶端資源訪問請求進行重新簽名后，向所述OAuth提供商的應用程序接口終端發(fā)起客戶端資源訪問請求。步驟111:接收所述OAuth提供商發(fā)送的客戶端資源訪問響應；步驟112:將所述客戶端資源訪問響應發(fā)送給第三方應用。在上述實施例中，所述方法還可以包括:所述第三方應用在接收到包括請求令牌的響應消息時，根據(jù)所述請求令牌將客戶端重定向到OAuth提供商提供的客戶端統(tǒng)一資源定位符上進行鑒權和授權操作；在客戶端授權成功后，所述OAuth提供商將所述客戶端重定向到第三方應用的頁面上，所述第三方應用向OAuth代理發(fā)起獲取訪問令牌的請求消息。優(yōu)選的，在上述實施例中，所述方法還可以包括:所述第三方應用在接收到包括請求令牌的響應消息時，根據(jù)所述請求令牌將客戶端重定向到OAuth代理提供的指示頁面上進行指示操作；所述OAuth代理根據(jù)所述請求令牌查詢對應的第三方應用信息和被訪問的OAuth提供商信息；所述OAuth代理向客戶端展示所述第三方應用需要通過該OAuth代理向OAuth提供商訪問的客戶端隱私數(shù)據(jù)，并提示客戶端是否允許訪問所述客戶端隱私數(shù)據(jù)；所述OAuth代理在接收到客戶端允許訪問所述客戶端隱私數(shù)據(jù)的確認信息后，將客戶端重定向到OAuth提供商提供的統(tǒng)一資源定位符上，以便于客戶端在所述OAuth提供商提供的客戶端授權統(tǒng)一資源定位符上進行鑒權和授權操作；之后執(zhí)行步驟接收所述第三方應用發(fā)送的獲取訪問令牌的請求消息。也就是說，OAuth代理向所述第三方應用發(fā)送獲取請求令牌的響應消息，以使所述第三方應用根據(jù)所述請求令牌將客戶端重定向到OAuth代理或OAuth提供商提供的客戶端統(tǒng)一資源定位符上。OAuth代理將獲取到的所述請求令牌發(fā)送給第三方應用，第三方應用在接收到所述請求令牌后，將客戶端重定向OAuth代理提供的客戶端授權頁面上，或者將客戶端直接重定向到OAuth提供商提供的客戶端授權頁面上。在該實施例中，如果第三方應用直接將客戶端重定向到OAuth提供商提供的客戶端授權頁面上，客戶端就可以通過客戶端名、密碼等對中方式進行鑒權，登陸到OAuth提供商的客戶端授權頁面上，登陸成功后進行授權操作。如果第三方應用將客戶端重定向OAuth代理提供的指示頁面上，OAuth代理接收客戶端發(fā)送的客戶端授權請求,所述客戶端授權請求包括請求令牌；根據(jù)所述請求令牌查詢到對應的第三方應用信息和被訪問的OAuth提供商信息；0Auth代理向客戶端展示所述第三方應用需要通過OAuth代理向OAuth提供商訪問的客戶端隱私數(shù)據(jù)，并提示客戶端是否允許訪問所述客戶端隱私數(shù)據(jù)；以及在接收到客戶端允許訪問所述客戶端隱私數(shù)據(jù)的確認信息后，將客戶端重定向到OAuth提供商提供的統(tǒng)一資源定位符上，以便于客戶端在所述OAuth提供商提供的客戶端授權統(tǒng)一資源定位符上進行鑒權和授權操作。本發(fā)明實施例提供的一種OAuth代理的方法,通過代理OAuth provider提供的資源，由于代理暴露的接口也遵循OAuthl.0a標準，應用開發(fā)者可以重用已有的各種OAuth客戶端庫，而且應用只需要通過OAuth代理即可訪問后面多種被代理的OAuth provider提供的服務，而不需要在每個OAuth provider上注冊，簡化了第三方應用的開發(fā)，同時本方案通過兩次重定向的機制解決了在客戶端授權階段被授權應用(OAuth代理)與客戶端實際使用應用(第三方應用)不一致導致客戶端困惑的問題，提高了客戶端的體驗。相應的，本發(fā)明實施例還提供一種開放鑒權應用程序接口 OAuth代理裝置，其結構示意圖如圖2所示，所述OAuth代理裝置包括:第一接收單元21，第一查詢單元22，第一獲取單元23，第一發(fā)送單元24，第二接收單元25，第二查詢單元26，第二獲取單元27，第二發(fā)送單元28，第三接收單元29， 資源請求單元30，資源接收單元31，第三發(fā)送單元32，其中，所述第一接收單元21，用于接收客戶端通過第三方應用發(fā)送的獲取請求令牌的請求消息；第一查詢單元22,用于根據(jù)所述請求令牌的請求消息中的Oauth提供商字段查詢到Oauth提供商為oauth代理發(fā)布的消費者密鑰對及其請求令牌統(tǒng)一資源定位符，所述第一獲取單元23，用于利用所述安全密鑰對所述獲取請求令牌的請求消息進行簽名后，從與所述獲取請求令牌的請求消息對應的請求令牌統(tǒng)一資源定位符上獲取請求令牌；所述第一發(fā)送單元24，用于向所述第三方應用發(fā)送包括請求令牌的響應消息；所述第二接收單元25，用于接收所述第三方應用發(fā)送的獲取訪問令牌的請求消息；第二查詢單元26，用于根據(jù)所述訪問令牌的請求消息中的Oauth提供商字段查詢到Oauth提供商為oauth代理發(fā)布的安全密鑰鑰對及其請求令牌統(tǒng)一資源定位符；所述第二獲取單元27，用于利用所述安全密鑰和請求令牌對所述獲取訪問令牌的請求消息進行重新簽名后，從與所述獲取訪問令牌的請求消息對應的訪問令牌統(tǒng)一資源定位符上獲取訪問令牌；所述第二發(fā)送單元28，用于向所述第三方應用發(fā)送包括訪問令牌的響應消息；所述第三接收單元29，用于接收第三方應用發(fā)送的客戶端資源訪問請求；所述資源請求單元30，用于根據(jù)所述訪問令牌對所述客戶端資源訪問請求進行重新簽名后，向與所述客戶端資源訪問請求對應的OAuth提供商發(fā)起客戶端資源訪問請求；所述資源接收單元31，用于接收所述OAuth提供商的發(fā)送的客戶端資源訪問響應；所述第三發(fā)送單元32，用于向第三方應用發(fā)送所述客戶端資源訪問響應。在上述實施例中，所述第一獲取單元可以包括:第一重簽名單元，請求令牌發(fā)送單元，請求令牌接收單元和第一存儲單元，其中，所述第一重簽名單元，用于利用所述OAuth提供商為Oauth代理發(fā)布的安全密鑰對所述獲取請求令牌的請求消息進行重新簽名；所述請求令牌發(fā)送單元，用于將重新簽名后的獲取請求令牌的請求消息發(fā)送給OAuth提供商；所述請求令牌接收單元，用于接收所述OAuth提供商發(fā)送的包括請求令牌的響應消息；所述第一存儲單元，用于存儲所述請求令牌與所述第三方應用和OAuth提供商的映射關系。在上述實施例中，所述第二獲取單元可以包括:第二重新簽名單元，第二重新簽名單元，訪問令牌發(fā)送單元，訪問令牌接收單元和第二存儲單元，其中，所述第二重新簽名單元，用于根據(jù)所述OAuth提供商發(fā)布的安全密鑰和請求令牌對所述獲取訪問令牌的請求消息進行重新簽名；所述訪問令牌發(fā)送單元，用于將重新簽名后的獲取訪問令牌的請求消息發(fā)送給所述OAuth提供商；所述訪問令牌接收單元，用于接收所述OAuth提供商發(fā)送的包括訪問令牌的響應消息；所述第二存儲單元，用于存儲所述訪問令牌與所述第三方應用和OAuth提供商的映射關系。在上述實施例中，所述資源請求單元包括:第三重新簽名單元和第四發(fā)送單元，其中，所述第三重新簽名單元，具體用于根據(jù)所述OAuth提供商提供的安全密鑰和訪問令牌對所述客戶端資源訪問請求進行重新簽名；所述第四發(fā)送單元，用于將第三重新簽名單元重新簽名后的客戶端資源訪問請求發(fā)送給對應的所述OAuth提供商。優(yōu)選的，如果第三方應用在接收到包括請求令牌的響應消息時，將客戶端重定向到所述OAuth代理裝置提供的指示頁面上，所述裝置還包括:第三查詢單元，展示單元，提示單元，確認信息接收單元和重 定向單元，其中，所述第三查詢單元，與第一發(fā)送單元連接，用于根據(jù)所述請求令牌查詢對應的第三方應用信息和被訪問的OAuth提供商信息；所述展示單元，用于向客戶端展示所述第三方應用需要通過該OAuth代理向OAuth提供商訪問的客戶端隱私數(shù)據(jù)；所述提示單元，用于在所述展示單元展示客戶端隱私數(shù)據(jù)后，提示客戶端是否允許訪問所述客戶端隱私數(shù)據(jù)；所述確認信息接收單元，用于在接收到客戶端允許訪問所述客戶端隱私數(shù)據(jù)的確認信息；所述重定向單元，與第二接收單元連接，用于在確認信息接收單元接收到客戶端的確認信息后，將客戶端重定向到OAuth提供商提供的統(tǒng)一資源定位符上，以便于客戶端在所述OAuth提供商提供的客戶端授權統(tǒng)一資源定位符上進行鑒權和授權操作。 優(yōu)選的，所述OAuth代理裝置可以集成在業(yè)務路由器中，也可以獨立部署，本實施例不作限制。相應的，本發(fā)明實施例還提供一種開放鑒權應用程序接口 OAuth代理裝置，及其結構示意圖如圖3所示,所述OAuth代理包括:請求令牌獲取端點(Get RequestTokenEndpoint)311,客戶端授權端點(User Authorization Endpoint) 321，訪問令牌端點(GetAccessToken Endpoint) 331 和應用程序接口代理(OAuth API proxy) 341,其中，所述請求令牌獲取端點311，用于接收第三方應用發(fā)送的獲取請求令牌的請求消息，根據(jù)所述獲取請求令牌的請求消息選擇對應的OAuth提供商，并根據(jù)OAuth代理在所述OAuth提供商上所擁有的消費者密鑰鍵和消費者密鑰對所述獲取請求令牌的請求消息進行重新簽名后，向OAuth提供商發(fā)起重新簽名后的獲取請求令牌的請求消息，并在接收到所述OAuth提供商發(fā)送的獲取請求令牌的響應消息后，存儲所述請求令牌、第三方應用及OAuth提供商之間的映射關系，以及向所述第三方應用發(fā)送獲取請求令牌響應消息；也就是說,所述請求令牌獲取端點311:用于滿足第三方應用Request Token請求，對接收到請求令牌的請求進行驗證，并在驗證成功后選擇合適的OAuth提供商，并根據(jù)OAuth proxy 在此 OAuth provider 上所擁有的 consumer key 和 consumer secret 對請求消息進行重新簽名后，向OAuth provider發(fā)起Get RequestToken請求,將收到包括請求令牌Request Token的響應消息后,存儲請求令牌。第三方應用及OAuth提供商之間的映射關系，并將包括請求令牌的響應消息返回給第三方應用。所述客戶端授權端點321，用于在將接收到客戶端的鑒權和授權請求消息時，根據(jù)所述請求消息中的請求令牌查詢到對應的第三方應用信息和被訪問的OAuth提供商信息，并告知客戶端，所述第三方應用需要通過本OAuth代理裝置去訪問OAuth提供商上的客戶端隱私數(shù)據(jù)，并為客戶端提供確認按鈕，以及在客戶端確認后，將客戶端重定向到OAuth提供商提供的客戶端授權頁面上；也就是說，客戶端授權端點321用于滿足客戶端的鑒權和授權請求，該客戶端授權端點直接和客戶端交互，主要為了防止客戶端在OAuth provider上進行真實的登陸授權時引起混淆和誤解，該客戶端授權端點根據(jù)請求消息中的request token查詢到對應的第三方應用信息和被訪問的OAuth provider信息，根據(jù)這些信息展示給客戶端告知客戶端第三方應用需要通過本OAuth proxy平臺去訪問OAuth provider上的客戶端信息,并最終返回重定向響應，將客戶端重定向到OAuth provider提供的User Authorization頁面上。其中，在該過程中，可選的是的，，客戶端授權端點321可以提供確認按鈕，讓客戶端確認，如果客戶端同意，再將客戶端重定 向到OAuth provider提供的User Authorization頁面上。所述訪問令牌端點331，用于在接收到第三方應用的獲取訪問令牌的請求消息，根據(jù)所述獲取訪問令牌的請求消息中的請求令牌找到對應的OAuth提供商，并根據(jù)本身在OAuth提供商上擁有的消費者密鑰鍵和消費者密鑰對所述獲取訪問令牌的請求消息進行重新簽名后，向發(fā)起OAuth提供商發(fā)起重新簽名后的獲取訪問令牌的請求消息，接收所述OAuth提供商反饋的獲取訪問令牌的響應消息，并存儲獲取的訪問令牌、第三方應用及OAuth提供商的映射關系，以及并將獲取的訪問令牌返回給所述第三方應用；也就是說，訪問令牌端點331滿足第三方應用的GetAccessToken請求，接收請求并且驗證成功后，會根據(jù)請求消息中的RequestToken信息找到合適的OAuth provider,并根據(jù)本身在OAuth provider上擁有的consumer key和consumer secret等信息對消息進行重新簽名后發(fā)起Get AccessToken請求,并再接收到OAuth provider反饋的包括accesstoken的響應后,保存響應消息中的access token、第三方應用及OAuth provider之間的映射關系，并將包括access token的響應返回給請求者，即第三方應用。所述應用程序接口代理341，用于接收所述第三方應用發(fā)送的包括訪問令牌的資源訪問請求，根據(jù)其在所述OAuth提供商上所擁有的消費者密鑰鍵、消費者密鑰和訪問令牌對所述客戶端資源訪問請求進行重新簽名后，向所述OAuth提供商的應用程序接口終端發(fā)起重新簽名后的客戶端資源訪問請求，并在接收OAuth提供商的應用程序接口終端發(fā)送的客戶端資源訪問響應后，向所述第三方應用發(fā)送所述客戶端資源訪問響應。也就是說，應用程序接口代理341接收第三方應用發(fā)送的資源訪問請求，并對所述資源訪問請求進行合適處理后，對OAuth provider發(fā)起真實的資源訪問請求并將響應路由給請求者，即第三方應用。優(yōu)選的，所述OAuth代理裝置可以集成在業(yè)務路由器中，也可獨立部署，本實施例不作限制。相應的，本發(fā)明還提供一種開放鑒權應用程序接口 OAuth代理系統(tǒng)，其結構如圖4所示，所述OAuth系統(tǒng)包括:第三方應用41、0Auth代理裝置42和OAuth提供商43。其中，所述第三方應用41，用于將接收到客戶端發(fā)送的獲取請求令牌的請求消息轉發(fā)給所述OAuth代理裝置；接收所述OAuth代理裝置發(fā)送的包括請求令牌的響應消息；以及將接收到客戶端發(fā)送的獲取訪問令牌的請求消息轉發(fā)給OAuth代理裝置；接收所述OAuth代理裝置發(fā)送的包括訪問令牌的響應消息；以及，向所述OAuth代理裝置發(fā)送客戶端資源訪問請求；接收所述OAuth代理裝置發(fā)送的客戶端資源訪問響應；所述OAuth代理裝置42，用于接收客戶端通過第三方應用發(fā)送的獲取請求令牌的請求消息；根據(jù)所述請求令牌的請求消息中的Oauth提供商字段查詢到Oauth提供商為Oauth代理發(fā)布的安全密鑰對及其請求令牌統(tǒng)一資源定位符；利用所述安全密鑰對所述獲取請求令牌的請求消息進行簽名后，從所述獲取請求令牌的請求消息對應的請求令牌統(tǒng)一資源定位符上獲取請求令牌；向所述第三方應用發(fā)送包括請求令牌的響應消息；接收所述第三方應用發(fā)送的獲取訪問令牌的請求消息；根據(jù)所述訪問令牌的請求消息中的Oauth提供商字段查詢到Oauth提供商為Oauth代理發(fā)布的安全密鑰對及其請求令牌統(tǒng)一資源定位符；利用所述安全密鑰和請求令牌對所述獲取訪問令牌的請求消息進行重新簽名后，從與所述獲取訪問令牌的請求消息對應的訪問令牌統(tǒng)一資源定位符上獲取訪問令牌；向所述第三方應用發(fā)送包括訪問令牌的響應消息；接收第三方應用發(fā)送的客戶端資源訪問請求；根據(jù)所述訪問令牌對所述客戶端資 源訪問請求進行重新簽名后，向與所述客戶端資源訪問請求對應的OAuth提供商發(fā)起客戶端資源訪問請求；接收所述OAuth提供商的發(fā)送的客戶端資源訪問響應，并將所述客戶端資源訪問響應發(fā)送給第三方應用。在該實施例中，所述OAuth代理裝置中包括的各個單元的詳見上述對應實施例中的描述，在此不再贅述。優(yōu)選的，所述第三方應用，還用于在接收到包括請求令牌的響應消息時，根據(jù)所述請求令牌將客戶端重定向到OAuth提供商提供的客戶端統(tǒng)一資源定位符上進行鑒權和授權操作；在客戶端授權成功后，所述OAuth提供商將所述客戶端重定向到第三方應用的頁面上，所述第三方應用向OAuth代理發(fā)起獲取訪問令牌的請求消息。優(yōu)選的，所述第三方應用，還用于在接收到包括請求令牌的響應消息時，根據(jù)所述請求令牌將客戶端重定向到OAuth代理提供的指示頁面上進行指示操作；所述OAuth代理，還用于根據(jù)所述請求令牌查詢對應的第三方應用信息和被訪問的OAuth提供商信息，并向客戶端展示所述第三方應用需要通過該OAuth代理向OAuth提供商訪問的客戶端隱私數(shù)據(jù)，并提示客戶端是否允許訪問所述客戶端隱私數(shù)據(jù)；以及在接收到客戶端允許訪問所述客戶端隱私數(shù)據(jù)的確認信息后，將客戶端重定向到OAuth提供商提供的統(tǒng)一資源定位符上，以便于客戶端在所述OAuth提供商提供的客戶端授權統(tǒng)一資源定位符上進行鑒權和授權操作；并接收所述第三方應用發(fā)送的獲取訪問令牌的請求消息。本發(fā)明實施例提供的一種OAuth代理的方法,通過代理OAuth provider提供的資源，由于代理暴露的接口也遵循OAuthl.0a標準，應用開發(fā)者可以重用已有的各種OAuth客戶端庫，而且應用只需要通過OAuth代理即可訪問后面多種被代理的OAuth provider提供的服務，而不需要在每個OAuth provider上注冊，簡化了第三方應用的開發(fā)，同時本方案通過兩次重定向的機制解決了在客戶端授權階段被授權應用(OAuth代理)與客戶端實際使用應用(第三方應用)不一致導致客戶端困惑的問題，提高了客戶端的體驗。為了便于本領域技術人員的理解，下面依據(jù)圖的實例來說明。請參閱圖5，為本發(fā)明提供的第一實施例的流程圖。在該實施例中，主要說明OAuthproxy為OAuth消息代理的具體流程,包括的實體為:客戶端(User agent)、第三方應用(3th APP)、OAuth 代理(OAuth proxy)、proxy 提供商(OAuth provider),其具體過程包括:步驟501:客戶端訪問第三方應用(Access app)，并且觸發(fā)應用需要訪問客戶端在某個OAuth提供商(OAuth provider)上存儲的客戶端隱私數(shù)據(jù)；步驟502:第三方應用向OAuth代理(OAuth proxy)發(fā)送獲取請求令牌的請求消息(Send request token request)；步驟503:0Auth proxy 向 OAuth provider 發(fā)起獲取 RequestToken 請求,其中，所述獲取RequestToken請求為利用OAuth 提供商發(fā)布的安全密鑰進行重新簽名后的所述請求；在該步驟中，OAuth proxy對該請求消息進行簽名驗證后，并根據(jù)請求消息的Oauth provider字段查詢到合適的OAuth provider,以及根據(jù)所述OAuth provider發(fā)布的安全密鑰對所述請求消息進行重新簽名后向OAuth provider發(fā)起獲取RequestToken請求；步驟504:0Auth proxy 接收 OAuth provider 返回的包括 RequestToken 的響應消息；步驟505:OAuth proxy 保存 RequestToken,以及及 RequestToken 與 OAuthprovider, OAuth consumer 之間的映射關系；步驟506:OAuth proxy將Request Token返回給第三方應用；步驟507:第三方應用將客戶端(User Agent)重定向到OAuth proxy提供的指示頁面上，或者將客戶端(User Agent)直接重定向到OAuth provider提供的客戶端授權(User Authorization)頁面上,如果第三方應用將客戶端重定向到OAuth provider提供的User Authorization頁面,則跳轉到步驟510 ;如果第三方應用將客戶端重定向到OAuthproxy提供的指示頁面上,執(zhí)行步驟508 ；步驟508:0Auth proxy根據(jù)請求消息中request token查詢到對應的第三方應用和要被訪問的OAuth provider等信息,展示相應的信息，該信息中至少包括第三方應用需要通過OAuth proxy去訪問某個OAuth provider上的客戶端隱私信息；進一步,在該步驟中，還可以為客戶端提供確認按鈕，以便于客戶端進行確認，下述步驟可以是接收到客戶端確認信息后執(zhí)行的步驟，也可以直接執(zhí)行該步驟。步驟509:OAuth proxy 將客戶端(User Agent)重定向到 OAuth provider 上的客戶端授權User Authorization頁面上；步驟510:客戶端通過客戶端名，密碼或瀏覽器中的信息(cookie)等多種方式鑒權、登錄OAuth provider的User Authorization頁面，并在登錄成功后進行授權操作；步驟511:授權成功后，OAuth provider將客戶端(User Agent)重定向到第三方應用的頁面上；步驟512:客戶端被重定向到第三方應用的頁面上，并攜帶有滿足OAuth標準的OAuth 驗證客戶端(0Auth_verifier)和 0Auth_token 等信息；步驟513:第三方應用向OAuth proxy發(fā)起獲取訪問令牌(AccessToken)的請求；步驟514:0Auth proxy驗證請求并查詢到合適的OAuth provider,并通過consumer key和consumer secret及request token對請求消息進行重新簽名，并向OAuthprovider 發(fā)起獲取 AccessToken 請求；步驟515:OAuth proxy 接收獲取 AccessToken 響應消息；步驟516:OAuth proxy 保存該 AccessToken 及其與 OAuth provider 和第三方應用的映射關系；步驟517:OAuth proxy將access token返回給第三方應用；步驟518:0Auth proxy接收第三方應用發(fā)起的客戶端資源訪問請求；步驟519:0Auth proxy 根據(jù)其在 OAuth provider 上的 consumer key 和 consumersecret及access token等信息對信息進行重新簽名后，向OAuth provider發(fā)起客戶端資源訪問請求；步驟520:OAuth proxy 接收OAuth provider的應用程序接口終端發(fā)送的客戶端資源訪問響應；步驟521:0Auth proxy將所述響應發(fā)送給第三方應用。還請參閱圖6，為本發(fā)明實施例提供第二應用實例的流程圖，在本實施例中，Oauth代理包括業(yè)務目錄和業(yè)務路由器，但并不限于此，并且，所述業(yè)務目錄和業(yè)務路由器共享數(shù)據(jù)庫；其中，業(yè)務目錄，用于為客戶端提供注冊，展示各種API信息，所述API信息為基于Oauth協(xié)議開放的API信息，業(yè)務目錄保存Oauth Provider的相關信息，其中，Oauth Provider的相關信息包括Oauthl.0標準中的獲取請求令牌統(tǒng)一資源標識符(GetRequestToken URL),客戶端授權統(tǒng)一資源標識符(User Authorization URL)和獲取訪問統(tǒng)一資源標識符(Get AccessToken URL)及Oauth provider為業(yè)務目錄和業(yè)務路由器發(fā)布的consumer key和consumer secret,客戶端簽名并驗證業(yè)務路由器發(fā)送的請求,第三方應用在業(yè)務目錄上注冊并獲取業(yè)務目錄發(fā)布的consumer key和consumer secret,同時第三方應用在業(yè)務目錄上發(fā)現(xiàn)并訂閱了某個Oauth provider提供的基于Oauth協(xié)議開放的API。所述業(yè)務路由器,用于完成具體的API proxy功能,提供Oauth標準中定義的三個URL (Get RequestToken URL,User Authorization URL和 Get AccessToken URL)endpoint,并對發(fā)送過來的請求消息進行實際的路由功能。本實施例中，業(yè)務目錄&業(yè)務路由器已在第三方Oauth provider上注冊并且擁有其發(fā)布的 consumer token (consumerkey 4sina, consumer secret 4sina)；業(yè)務目錄&業(yè)務路由器已存儲Oauth provider所提供的三個Oauth URL地址(GetRequestToken URL, User Authorization URL和 Get AccessToken URL)第三方應用已在業(yè)務目錄上注冊，并獲得業(yè)務目錄&業(yè)務路由器發(fā)布的consumertoken(consumerkey, consumersecret)。
在滿足上述條件下，本實施例的具體流程包括:步驟601:客戶端訪問第三方應用，并且觸發(fā)應用需要訪問客戶端在某個oauthprovider上存儲的客戶端隱私數(shù)據(jù)；步驟602:第三方應用向業(yè)務路由器發(fā)起獲取RequestToken請求；其中，請求的格式為:其中，oauth_consumer_key為業(yè)務目錄&業(yè)務路由器為應用發(fā)布的consumer key, sina為Oauth provider在業(yè)務目錄上注冊的域名標示符，oauth_callback 為應用提供的回調(diào)地址，oauth_signature 為通過 consumer key 和 consumer
secret對請求消息進行簽名后的簽名值:
POST /getrequesttoken/sina HTTP/1.1 //http請求行，請求uri中包含oauth provider字段sina
Host: www.servicerouter.com //主機名，指向oauth代理服務器 Authorization: OAuth realm="Photos", "oauth 鑒權域
oauth—consumer—key= “consumerkey”，//oauth代理為第三方應用提供的消費者密鑰鍵
oauth—signature—method=”HMAC-SHAl '，,//簽名算法 oauth—timestamp=”137131200”, //時間戮 oauth_nonce="wIjqoS",
oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready “ Jl
回調(diào)地址
oauth_signature="74KNZJeDHnMBpOEMJ9ZHt%2FXKycU%3D “ //
通過消費者密鑰和密鑰鍵使用前面所述的簽名算法對本消息標準化后的字符串進行簽名后的簽名值步驟603:業(yè)務路由器向 Oauth provider 發(fā)起 Get RequestToken 請求；在該步驟中，業(yè)務路由器對請求消息進行驗證成功后，根據(jù)請求消息中的Oauthprovider字段，例如” sina”找到合適的Oauth provider,并利用Oauth provider發(fā)布的consumer key (consumerkey4sina)和 consumer secret 對消息進行重新簽名，然后向 Oauthprovider發(fā)起Get RequestToken請求,消息格式如下，Oauth provider字段不僅僅限定來源于path部分，也可能會來至http url的query字段，http head或http body體:POST /oauth/request—token HTTP/1.l//uri,指向oauth provider提供的請求密鑰uri
Host: ap1.t.sina.com.cn//主機名，指向oauth provider的服務器
地址
Authorization: OAuth realm="Photos",
oauth—consumer—key=“consumerkey4sina” ,//oauth provider為oauth代理提供的消費者密鑰鍵，
oauth—signature—method=”HMAC- SHAl",o auth—time stamp=” 13 71312 O O ”，oauth—nonce=” wljqoS ”，
oauth—callback=”http%3A%2F%2Fprinter.example.com%2Fready“，
oauth_signature="74KNZJeDHnMBpOEMJ9ZHt%2FXKycU%3DtV/ 通過
消費者密鑰鍵和消費者密鑰對請求消息進行簽名后的簽名值，步驟604:業(yè)務路由器接收Oauth provider發(fā) 送過來的響應消息；其中，消息格式如下:oauth_token = tokenl&oauth_token_secret = secretl&oauth_callback_confirmed = true//tokenl 即為 oauth provider 返回白勺 i青求 token 值，secretl 即為token I對應的密鑰步驟605:業(yè)務路由器記錄下request token(tokenl, secretl)及其與第三方應用和oauth provider的映射關系；步驟606:業(yè)務路由器將步驟604中接收到的響應消息返回給第三方應用；步驟607:第三方應用將客戶端(user agent)重定向到業(yè)務路由器的指示頁面上;比如,https://www.servicerouter.com/accounts/OAuthAuthorizeToken oauth_token = tokenl,或者將客戶端(User Agent)直接重定向到Oauth provider提供的UserAuthorization 頁面，t匕如，http://ap1.t.sina.com.cn/oauth/authorize oauth_token=tokenl 上；如果重定向到Oauth provider提供的User Authorization頁面，則跳轉到步驟610 ;如果重定向到業(yè)務路由器的指示頁面，字則執(zhí)行步驟608 ；步驟608:業(yè)務路由器根據(jù)請求消息中oauth_token字段查詢到對應的第三方應用和要被訪問的Oauth provider等信息,展示相應的信息，即包括第三方應用需要通過業(yè)務路由器去訪問某個oauth provider上的客戶端隱私信息；進一步，還可以提供確認按鈕讓客戶端進行確認；
步驟609:業(yè)務路由器將客戶端(user agent)重定向到oauth provider的客戶端授權頁面上，比如:http 請求 URL 為 http://ap1.t.sina.com.cn/oauth/authorize oauth_token=tokenl步驟610:客戶端通過客戶端名，密碼或cookie等多種方式鑒權、登錄Oauthprovider的User Authorization頁面，登錄成功后進行授權操作；步驟611:授權成功后，Oauth provider將客戶端(User Agent)重定向到第三方應用的頁面上，比如，http url 地址為 http://printer.example, com/ready oauth_verifier = hfdp7dh39dks988&oauth_token = tokenl ；步驟612:客戶端被重定向到第三方應用的頁面上，并攜帶有滿足oauth標準的oauth_verif ier 和 oauth_token 等信息；步驟613:第三方應用向業(yè)務路 由器發(fā)起獲取AccessToken請求；請求消息格式如下，其中oauth_signature 為通過 consumerkey 和 requesttoken
進行共同簽名后的值:
POST /getaccesstokenrequest/sina HTTP/1.l//oauth代理提供的訪問令 牌URI, sina即為oauth provider字段對應的值 Host: www.servicerouter.com Authorization: OAuth realm="Photos", oauth—consumer—key=” consumerkey ”， oauth—token=“tokenl”, //請求token oauth—signature—method="HMAC-SHAI ”,//簽名算法 oauth—timestamp=” 137131201", oauth—nonce=” walatlh”， oauth_verifier="hfdp7dh39dks9884",
oauth_signature="gKgrFCywp7rOOOXSjdot%2FIHF7IU%3DtV/ 通過消費者密鑰對和請求token及請求token對應的密鑰按消息中規(guī)定的簽名算法對請求消息標準化后的字符串進行簽名后產(chǎn)生的值步驟614:業(yè)務路由器對請求消息進行重新簽名后向該URL發(fā)起獲取AccessToken請求；在該步驟中，業(yè)務路由器通過簽名對請求消息進行驗證，驗證成功后，根據(jù)tokenl及 consumerkey 查詢至Ij 目的 oauth provider 的 Get AccessToken URL 及 consumer key 等信息，通過對請求消息進行重新簽名后向該URL發(fā)起獲取AccessToken請求,請求格式如下，其中consumerkey4sina為oauth provider為業(yè)務目錄&業(yè)務路由器發(fā)布的 consumerkey, tokenl為步驟604中業(yè)務路由器接收到的request token:POST / oauth/accesstoken HTTP/1.1//oauth provider 提供的訪問
令牌URI,
Host: ap1.t.sina.com.cn//oauth provider提供的主機地址， Authorization: OAuth realm="Photos",
oauth—consumer—key=”consumerkey4sina”,"oauth 提供者為 oauth代理發(fā)布的消費者密鑰鍵，
oauth—token=“tokenl",
oauth—signature—method=”HMAC-SHAl",
oauth—timestamp=” 137131201",
oauth—nonce=” walatlh”，
oauth_verifier="hfdp7dh39dks9884",
oauth_signature=“xxxxxbbbbxxxbbbxxxbbbxbb”// 通過消費者密鑰對和請求令牌及請求令牌對應的 密鑰鍵按oauth—signature—method提供的簽名算法對消息進行簽名后的值，步驟615:0auth provider 返回 access token pair 的響應消息;其中，accesstoken pair 包括:accesstokenl, secrettokenl),響應消息如oauth_token = accesstokenl&oauth_token_secret = secrettokenl；//accesstokenl 即為訪問令牌的值，secrettokenl為該訪問令牌對應的密鑰；步驟616:業(yè)務路由器記錄下該access token及其映射關系步驟617:業(yè)務路由器將該access token返回給第三方應用步驟618:業(yè)務路由器接收第三方應用發(fā)送的訪問資源請求；消息格式如下，其中oauth_consumer_key為業(yè)務目錄&業(yè)務路由器為第三方應用發(fā)布的consumer key, oauth_token為步驟615步中業(yè)務路由器接收到的oauth_token:
GET /photos file=vacation.jpg&size=original HTTP/1.1 Host: www.servicerouter.com Authorization: OAuth realm="Photos",
oauth—consumer—key=”consumerkey”,//oauth 代理為第三方應用發(fā)布的消費者密鑰鍵，
oauth—token=" accesstoken I", //對應前述步驟中獲得的訪問令牌，oauth—signature—method=”HMAC- SHAl", oauth—timestamp=” 137131202", oauth_nonce="chapoH",
oauth—signature='’MdpQcU8iPSUjWoN%2FUDMsK2sui9I%3D”步驟619:業(yè)務路由器根據(jù)簽名驗證請求后，查詢到業(yè)務目錄&業(yè)務路由器在Oauth provider 上的 consumer key 和 consumer secret,并結合 access token 對消息進行重新簽名后將消息發(fā)送給oauth provider的API endpoint ;詳細格式如下,其中oauth_consumer_key為oauth provider為業(yè)務目錄&業(yè)務路由器發(fā)布的consumer key,:
GET /photos file=vacation.jpg&size=original HTTP/1.1 Host: ap1.t.sina.com.cn Authorization: OAuth realm="Photos",
oauth—consumer—key=”consumerkey4sina”,//oauth提供者為 oauth代理發(fā)布的消費者 密鑰鍵，
oauth_token="accesstokenl ”,//訪問令牌，oauth—signature—method=”HMAC- SHAl",oauth—timestamp=" 137131202",oauth—nonce=" chapoH”，
oauth—signature= “χχχχ1ι1ι1ι1ιχχχχ1ι1ι1ι!ιχχχχ1ι1 1ιχ，，.
步驟620:業(yè)務路由器接收所述OAuth提供商發(fā)送的客戶端資源訪問響應；步驟621:業(yè)務路由器將所述客戶端資源訪問響應發(fā)送給第三方應用。本發(fā)明實施例提供一種開放鑒權應用程序接口 OAuth代理的方法、裝置及系統(tǒng)，通過本方案能夠通過代理Oauth provider提供的資源，由于代理暴露的接口也遵循Oauthl.0a標準，應用開發(fā)者可以重用已有的各種oauth客戶端庫，而且應用只需要通過oauth代理即可訪問后面多種被代理的oauth provider提供的服務,而不需要在每個oauth provider上注冊,簡化了第三方應用的開發(fā)，同時本方案通過兩次重定向的機制解決了在客戶端授權階段被授權應用(oauth代理)與客戶端實際使用應用(第三方應用)不一致導致客戶端困惑的問題，提高了客戶端的體驗。需要說明的是，在本文中，諸如第一和第二等之類的關系術語僅僅用來將一個實體或者操作與另一個實體或操作區(qū)分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關系或者順序。而且，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設備
所固有的要素。在沒有更多限制的情況下，由語句“包括一個......”限定的要素，并不排
除在包括所述要素的過程、方法、物品或者設備中還存在另外的相同要素。通過以上的實施方式的描述，本領域的技術人員可以清楚地了解到本發(fā)明可借助軟件加必需的通用硬件平臺的方式來實現(xiàn)，當然也可以通過硬件，但很多情況下前者是更佳的實施方式?；谶@樣的理解，本發(fā)明的技術方案本質上或者說對現(xiàn)有技術做出貢獻的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計算機軟件產(chǎn)品可以存儲在存儲介質中，如ROM/RAM、磁碟、光盤等，包括若干指令用以使得一臺計算機設備(可以是個人計算機，服務器，或者網(wǎng)絡設備等)執(zhí)行本發(fā)明各個實施例或者實施例的某些部分所述的方法。以上所述僅是本發(fā)明的優(yōu)選實施方式，應當指出，對于本技術領域的普通技術人員來說，在不脫離本發(fā)明原理的前提下，還可以作出 若干改進和潤飾，這些改進和潤飾也應視為本發(fā)明的保護范圍。
權利要求
1.一種開放鑒權應用程序接口 OAuth代理的方法，其特征在于，包括: 接收第三方應用發(fā)送的獲取請求令牌的請求消息； 根據(jù)所述請求令牌的請求消息中的Oauth提供商字段查詢到Oauth提供商為Oauth代理發(fā)布的安全密鑰對及其請求令牌統(tǒng)一資源定位符； 利用所述安全密鑰對所述獲取請求令牌的請求消息進行簽名后，從所述獲取請求令牌的請求消息對應的請求令牌統(tǒng)一資源定位符上獲取請求令牌； 向所述第三方應用發(fā)送包括請求令牌的響應消息； 接收所述第三方應用發(fā)送的獲取訪問令牌的請求消息； 根據(jù)所述訪問令牌的請求消息中的Oauth提供商字段查詢到Oauth提供商為Oauth代理發(fā)布的安全密鑰對及其請求令牌統(tǒng)一資源定位符； 利用所述安全密鑰和請求令牌對所述獲取訪問令牌的請求消息進行簽名后，從所述獲取訪問令牌的請求消息對應的訪問令牌統(tǒng)一資源定位符上獲取訪問令牌； 向所述第三方應用發(fā)送包括訪問令牌的響應消息； 接收第三方應用發(fā)送的客戶端資源訪問請求； 根據(jù)所述訪問令牌對所述客戶端資源訪問請求進行簽名后，向所述客戶端資源訪問請求對應的OAuth提供商發(fā)起客戶端資源訪問請求； 接收所述OAuth提供商發(fā)送的客戶端資源訪問響應； 將所述客戶端資源訪問響應發(fā)送給第三方應用。
2.根據(jù)權利要求1所述的方法，其特征在于，所述利用所述安全密鑰對所述獲取請求令牌的請求消息進行簽名后，從所述獲取請求令牌的請求消息對應的請求令牌統(tǒng)一資源定位符上獲取請求令牌，具體包括: 根據(jù)所述OAuth提供商為Oauth代理發(fā)布的發(fā)布的安全密鑰對所述獲取請求令牌的請求消息進行重新簽名； 將重新簽名后的獲取請求令牌的請求消息發(fā)送給OAuth提供商； 接收所述OAuth提供商發(fā)送的包括請求令牌的響應消息； 存儲所述請求令牌與所述第三方應用和OAuth提供商的映射關系。
3.根據(jù)權利要求2所述的方法，其特征在于，所述利用所述安全密鑰和請求令牌對所述獲取訪問令牌的請求消息進行簽名后，從所述獲取訪問令牌的請求消息對應的訪問令牌統(tǒng)一資源定位符上獲取訪問令牌，具體包括: 根據(jù)所述OAuth提供商為Oauth代理發(fā)布的安全密鑰發(fā)布的安全密鑰和請求令牌對所述獲取訪問令牌的請求消息進行重新簽名； 將重新簽名后的獲取訪問令牌的請求消息發(fā)送給所述OAuth提供商； 接收所述OAuth提供商發(fā)送的包括訪問令牌的響應消息； 存儲所述訪問令牌與所述第三方應用和OAuth提供商的映射關系。
4.根據(jù)權利要求3所述的方法，其特征在于，所述根據(jù)所述訪問令牌對所述客戶端資源訪問請求進行重新簽名的方式為: 根據(jù)所述OAuth提供商提供的安全密鑰和訪問令牌對所述客戶端資源訪問請求進行重新簽名。
5.根據(jù)權利要求1至4任一項所述的方法， 其特征在于，所述方法還包括:所述第三方應用在接收到包括請求令牌的響應消息時，根據(jù)所述請求令牌將客戶端重定向到OAuth提供商提供的客戶端統(tǒng)一資源定位符上進行鑒權和授權操作； 在客戶端授權成功后，所述OAuth提供商將所述客戶端重定向到第三方應用的頁面上，所述第三方應用向OAuth代理發(fā)起獲取訪問令牌的請求消息。
6.根據(jù)權利要求1至4任一項所述的方法，其特征在于，所述方法還包括: 所述第三方應用在接收到包括請求令牌的響應消息時，根據(jù)所述請求令牌將客戶端重定向到OAuth代理提供的指示頁面上進行指示操作； 所述OAuth代理根據(jù)所述請求令牌查詢對應的第三方應用信息和被訪問的OAuth提供商信息； 所述OAuth代理向客戶端展示所述第三方應用需要通過該OAuth代理向OAuth提供商訪問的客戶端隱私數(shù)據(jù)，并提示客戶端是否允許訪問所述客戶端隱私數(shù)據(jù)； 所述OAuth代理在接收到客戶端允許訪問所述客戶端隱私數(shù)據(jù)的確認信息后，將客戶端重定向到OAuth提供商提供的統(tǒng)一資源定位符上，以便于客戶端在所述OAuth提供商提供的客戶端授權統(tǒng)一資源定位符上進行鑒權和授權操作；之后執(zhí)行步驟接收所述第三方應用發(fā)送的獲取訪問令牌的請求消息。
7.根據(jù)權利要求1至4任一項所述的方法，其特征在于，所述請求令牌包括:密鑰鍵和密鑰；所述安全密鑰包括:消費者密鑰鍵和消費者密鑰。
8.一種開放鑒權應用程序接口 OAuth代理裝置，其特征在于，包括: 第一接收單元，用于接收第三方應用發(fā)送的獲取請求令牌的請求消息； 第一查詢單元，用于根據(jù)所述請求令牌的請求消息中的Oauth提供商字段查詢到Oauth提供商為oauth代理發(fā)布的消費者密鑰對及其請求令牌統(tǒng)一資源定位符； 第一獲取單元，用于利用所述安全密鑰對所述獲取請求令牌的請求消息進行簽名后，從所述獲取請求令牌的請求消息對應的請求令牌統(tǒng)一資源定位符上獲取請求令牌； 第一發(fā)送單元，用于向所述第三方應用發(fā)送包括請求令牌的響應消息； 第二接收單元，用于接收所述第三方應用發(fā)送的獲取訪問令牌的請求消息； 第二查詢單元，用于根據(jù)所述訪問令牌的請求消息中的Oauth提供商字段查詢到Oauth提供商為oauth代理發(fā)布的安全密鑰鑰對及其請求令牌統(tǒng)一資源定位符； 第二獲取單元，用于利用所述安全密鑰和請求令牌對所述獲取訪問令牌的請求消息進行重新簽名后，從所述獲取訪問令牌的請求消息對應的訪問令牌統(tǒng)一資源定位符上獲取訪問令牌； 第二發(fā)送單元，用于向所述第三方應用發(fā)送包括訪問令牌的響應消息； 第三接收單元，用于接收第三方應用發(fā)送的客戶端資源訪問請求； 資源請求單元，用于根據(jù)所述訪問令牌對所述客戶端資源訪問請求進行重新簽名后，向所述客戶端資源訪問請求對應的OAuth提供商發(fā)起客戶端資源訪問請求； 資源接收單元，用于接收所述OAuth提供商的發(fā)送的客戶端資源訪問響應； 第三發(fā)送單元，用于向第三方應用發(fā)送所述客戶端資源訪問響應。
9.根據(jù)權利要求8所述的裝置，其特征在于，所述第一獲取單元包括:第一重簽名單元，用于利用所述OAuth提供商為Oauth代理發(fā)布的安全密鑰對所述獲取請求令牌的請求消息進行重新簽名；請求令牌發(fā)送單元，用于將重新簽名后的獲取請求令牌的請求消息發(fā)送給OAuth提供商； 請求令牌接收單元，用于接收所述OAuth提供商發(fā)送的包括請求令牌的響應消息； 第一存儲單元，用于存儲所述請求令牌與所述第三方應用和OAuth提供商的映射關系O
10.根據(jù)權利要求9所述的裝置，其特征在于，所述第二獲取單元包括: 第二重新簽名單元，用于根據(jù)所述OAuth提供商為Oauth代理發(fā)布的安全密鑰和請求令牌對所述獲取訪問令牌的請求消息進行重新簽名； 訪問令牌發(fā)送單元，用于將重新簽名后的獲取訪問令牌的請求消息發(fā)送給所述OAuth提供商； 訪問令牌接收單元，用于接收所述OAuth提供商發(fā)送的包括訪問令牌的響應消息； 第二存儲單元，用于存儲所述訪問令牌與所述第三方應用和OAuth提供商的映射關系
11.根據(jù)權利要求10所述的裝置，其特征在于，所述資源請求單元包括: 第三重新簽名單元，具體用于根據(jù)所述OAuth提供商提供的安全密鑰和訪問令牌對所述客戶端資源訪問請求進行重新簽名； 第四發(fā)送單元，用于將第三重新簽名單元重新簽名后的客戶端資源訪問請求發(fā)送給對應的所述OAuth提供商。
12.根據(jù)權利要求8至11任一項所述的裝置，其特征在于，如果第三方應用在接收到包括請求令牌的響應消息時，將客戶端重定向到所述OAuth代理裝置提供的指示頁面上，所述裝置還包括: 第三查詢單元，與第一發(fā)送單元連接，用于根據(jù)所述請求令牌查詢對應的第三方應用信息和被訪問的OAuth提供商信息； 展示單元，用于向客戶端展示所述第三方應用需要通過該OAuth代理向OAuth提供商訪問的客戶端隱私數(shù)據(jù)； 提示單元，用于在所述展示單元展示客戶端隱私數(shù)據(jù)后，提示客戶端是否允許訪問所述客戶端隱私數(shù)據(jù)； 確認信息接收單元，用于在接收到客戶端允許訪問所述客戶端隱私數(shù)據(jù)的確認信息；重定向單元，與第二接收單元連接，用于在確認信息接收單元接收到客戶端的確認信息后，將客戶端重定向到OAuth提供商提供的統(tǒng)一資源定位符上，以便于客戶端在所述OAuth提供商提供的客戶端授權統(tǒng)一資源定位符上進行鑒權和授權操作。
13.根據(jù)權利要求8至11任一項所述的裝置，其特征在于，所述OAuth代理裝置集成在業(yè)務路由器中，或獨立部署。
14.一種開放鑒權應用程序接口 OAuth代理系統(tǒng)，其特征在于，包括:第三方應用、OAuth代理裝置和OAuth提供商，其中， 所述第三方應用，用于將接收到客戶端發(fā)送的獲取請求令牌的請求消息轉發(fā)給所述OAuth代理裝置；接收所述OAuth代理裝置發(fā)送的包括請求令牌的響應消息；以及將接收到客戶端發(fā)送的獲取訪問令牌的請求消息轉發(fā)給OAuth代理裝置；接收所述OAuth代理裝置發(fā)送的包括訪問令牌的響應消息；以及，向所述OAuth代理裝置發(fā)送客戶端資源訪問請求；接收所述OAuth代理裝置發(fā)送的客戶端資源訪問響應； 所述OAuth代理裝置，用于接收客戶端通過第三方應用發(fā)送的獲取請求令牌的請求消息；根據(jù)所述請求令牌的請求消息中的Oauth提供商字段查詢到Oauth提供商為Oauth代理發(fā)布的安全密鑰對及其請求令牌統(tǒng)一資源定位符；利用所述安全密鑰對所述獲取請求令牌的請求消息進行簽名后，從所述獲取請求令牌的請求消息對應的請求令牌統(tǒng)一資源定位符上獲取請求令牌；向所述第三方應用發(fā)送包括請求令牌的響應消息；接收所述第三方應用發(fā)送的獲取訪問令牌的請求消息；根據(jù)所述訪問令牌的請求消息中的Oauth提供商字段查詢到Oauth提供商為Oauth代理發(fā)布的安全密鑰對及其請求令牌統(tǒng)一資源定位符；利用所述安全密鑰和請求令牌對所述獲取訪問令牌的請求消息進行重新簽名后，從所述獲取訪問令牌的請求消息對應的訪問令牌統(tǒng)一資源定位符上獲取訪問令牌；向所述第三方應用發(fā)送包括訪問令牌的響應消息；接收第三方應用發(fā)送的客戶端資源訪問請求；根據(jù)所述訪問令牌對所述客戶端資源訪問請求進行重新簽名后，向所述客戶端資源訪問請求對應的OAuth提供商發(fā)起客戶端資源訪問請求；接收所述OAuth提供商的發(fā)送的客戶端資源訪問響應，并將所述客戶端資源訪問響應發(fā)送給第三方應用。
15.根據(jù)權利要求14所述的系統(tǒng)，其特征在于， 所述第三方應用，還用于在接收到包括請求令牌的響應消息時，根據(jù)所述請求令牌將客戶端重定向到OAuth提供商提供的客戶端統(tǒng)一資源定位符上進行鑒權和授權操作； 在客戶端授權成功后，所述OAuth提供商將所述客戶端重定向到第三方應用的頁面上，所述第三方應用向OAuth代理發(fā)起獲取訪問令牌的請求消息。
16.根據(jù)權利要求15所述的系統(tǒng)，其特征在于， 所述第三方應用，還用于在接收到包括請求令牌的響應消息時，根據(jù)所述請求令牌將客戶端重定向到OAuth代理提供的指示頁面上進行指示操作； 所述OAuth代理，還用于根據(jù)所述請求令牌查詢對應的第三方應用信息和被訪問的OAuth提供商信息，并向客戶端展示所述第三方應用需要通過該OAuth代理向OAuth提供商訪問的客戶端隱私數(shù)據(jù)，并提示客戶端是否允許訪問所述客戶端隱私數(shù)據(jù)；以及在接收到客戶端允許訪問所述客戶端隱私數(shù)據(jù)的確認信息后，將客戶端重定向到OAuth提供商提供的統(tǒng)一資源定位符上，以便于客戶端在所述OAuth提供商提供的客戶端授權統(tǒng)一資源定位符上進行鑒權和授權操作；并接收所述第三方應用發(fā)送的獲取訪問令牌的請求消息。
全文摘要
本發(fā)明提供一種開放鑒權應用程序接口OAuth代理的方法、裝置及系統(tǒng)，通過代理OAuth提供商提供的資源，應用開發(fā)者可以重用已有的各種OAuth客戶端庫，而且應用只需要通過OAuth代理即可訪問后面多種被代理的OAuth提供商提供的服務，而不需要在每個OAuth提供商上注冊，簡化了第三方應用的開發(fā)，同時本方案通過兩次重定向的機制解決了在客戶端授權階段被授權應用(即OAuth代理)與客戶端實際使用的應用(即第三方應用)不一致導致客戶端困惑的問題，提高了客戶端的體驗。
文檔編號H04L29/06GK103220261SQ20121001979
公開日2013年7月24日 申請日期2012年1月21日 優(yōu)先權日2012年1月21日
發(fā)明者鄒現(xiàn)軍 申請人:華為技術有限公司