本發(fā)明涉及一種面向服務技術框架下不同應用間統(tǒng)一授權認證的方法。

背景技術：

隨著近年來soa(面向服務技術架構)的興起，越來越多的應用系統(tǒng)開始進行分布式的設計和部署。系統(tǒng)由原來單一的技術架構變成面向服務的多系統(tǒng)架構。原來在一個系統(tǒng)之間可以完成的業(yè)務流程，通過多系統(tǒng)之間多次交互來實現(xiàn)，再加上不同系統(tǒng)訪問第三方應用的情況，導致各個服務系統(tǒng)的互訪存在規(guī)則混亂、標準不統(tǒng)一、安全度不夠和重復建設等問題。

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

為克服上述現(xiàn)有技術的缺陷，本發(fā)明實施例提供了一種面向服務技術框架下不同應用間統(tǒng)一授權認證的方法，為系統(tǒng)內大量的面向服務的應用之間提供統(tǒng)一授權認證，并由統(tǒng)一認證中心規(guī)范系統(tǒng)內應用和第三方應用訪問的授權和令牌的管理問題。

為了達到上述目的，提供一種面向服務技術框架下不同應用間統(tǒng)一授權認證的方法，該方法設置有一統(tǒng)一認證中心，包括如下步驟：

a)終端通過統(tǒng)一認證中心綁定應用系統(tǒng)，統(tǒng)一認證中心向終端返回一統(tǒng)一令牌；

b)終端使用統(tǒng)一令牌向應用系統(tǒng)請求數(shù)據(jù)；

c)應用系統(tǒng)向統(tǒng)一認證中心請求認證；

d)統(tǒng)一認證中心進行認證，并向應用系統(tǒng)返回認證結果；

e)若認證結果校驗成功，應用系統(tǒng)向終端返回請求的數(shù)據(jù)；否則，應用系統(tǒng)向終端返回校驗失敗信息。

優(yōu)選的，步驟a)的實現(xiàn)方法為：終端向統(tǒng)一認證中心提交注冊信息，注冊綁定成功后，統(tǒng)一認證中心向終端返回統(tǒng)一令牌；若終端存在與第三方應用有授權認證的情況，需先向第三方應用請求授權認證，得到第三方應用發(fā)放的第三方令牌后，將第三方令牌和第三方的認證渠道信息在統(tǒng)一認證中心與統(tǒng)一令牌進行映射綁定。

優(yōu)選的，步驟b)中，終端向應用系統(tǒng)請求數(shù)據(jù)時，發(fā)送統(tǒng)一令牌時一并發(fā)送認證渠道，認證渠道包括第三方應用授權認證渠道與統(tǒng)一認證中心認證渠道。

優(yōu)選的，若認證渠道為統(tǒng)一認證中心認證渠道，步驟c)中的認證由統(tǒng)一認證中心認證；若認證渠道為第三方應用授權認證渠道，步驟c)中的認證經統(tǒng)一認證中心根據(jù)映射綁定向第三方應用請求認證。

優(yōu)選的，統(tǒng)一認證中心向第三方應用請求認證時，若第三方令牌過期，統(tǒng)一認證中心使用終端的注冊信息向第三方應用請求更新第三方令牌，第三方應用生成新的第三方令牌，并重新將新的第三方令牌與統(tǒng)一令牌進行映射綁定。

優(yōu)選的，若終端請求信息返回結果為統(tǒng)一令牌已過期，則需要重新向統(tǒng)一認證中心請求新的統(tǒng)一令牌，并用該統(tǒng)一令牌再次發(fā)起數(shù)據(jù)請求。

優(yōu)選的，終端至少有一個，應用系統(tǒng)至少有一個。

優(yōu)選的，統(tǒng)一令牌為統(tǒng)一認證token令牌。

優(yōu)選的，第三方令牌為第三方token令牌。

優(yōu)選的，統(tǒng)一令牌與第三方令牌均具有一定的有效期。

本發(fā)明與現(xiàn)有技術相比的優(yōu)點為：

本發(fā)明通過使用了建立統(tǒng)一認證中心的應用，解決了不同應用之間授權認證的問題，以及多個終端(app、web)和不同第三方應用授權認證后，證書和令牌多而混亂，存在網(wǎng)絡狀信息交互、管理不方便的問題。對于企業(yè)的系統(tǒng)框架來說，建立一個統(tǒng)一認證中心，方便和規(guī)范了應用系統(tǒng)間的訪問認證問題，減少了不同應用間功能的重復建設，解決不同應用間多證書和多令牌管理，簡化網(wǎng)絡拓撲結構，減少了企業(yè)軟件開發(fā)成本。

附圖說明

圖1是本發(fā)明終端和應用系統(tǒng)綁定的流程示意圖；

圖2是本發(fā)明終端向soa應用請求受保護資源的流程示意圖。

具體實施方式

在本發(fā)明描述中,術語“上”、“下”、“前”及“后”等指示的方位或位置關系為基于附圖所示的方位或位置關系，僅是為了便于描述本發(fā)明而不是要求本發(fā)明必須以特定的方位構造和操作，因此不能理解為對本發(fā)明的限制。

下面結合附圖對本發(fā)明的具體實施方式作進一步說明。

作為優(yōu)選實施例，本發(fā)明提出了一種基于oauth開放的授權標準,解決soa面向服務技術框架下不同應用間統(tǒng)一授權認證的方法，該方法包括以下步驟：

1、終端(app、web)和應用系統(tǒng)綁定步驟，具體參照圖1。

s01，終端向統(tǒng)一認證中心發(fā)起注冊認證和綁定申請，如果終端是app的情況，需要提交終端app的appkey、appid和認證渠道等信息給統(tǒng)一認證中心；

s02，注冊綁定成功后，統(tǒng)一認證中心對終端發(fā)放統(tǒng)一認證token令牌，統(tǒng)一認證token令牌存在有效期；

s03，終端存在和第三方應用有授權認證的情況，比如使用qq、微信、微博等賬號登錄系統(tǒng)，需先向第三方應用請求授權認證；

s04，第三方應用成功返回授權認證信息，終端得到第三方應用發(fā)放的第三方token令牌；

s05，終端將第三方token令牌、用戶id等信息向統(tǒng)一認證中心提交綁定；

s06，統(tǒng)一認證中心將第三方token令牌和認證渠道等信息與統(tǒng)一認證token令牌進行映射綁定。

2、終端(app、web)向soa應用請求受保護資源的步驟，具體參照圖2。

s07，終端向soa服務框架的應用請求數(shù)據(jù)的時候，需將統(tǒng)一認證token令牌和認證渠道等信息發(fā)送給服務提供方；

s08，服務提供方在收到請求后，將統(tǒng)一認證token令牌和認證渠道等信息發(fā)給統(tǒng)一認證中心做校驗；統(tǒng)一認證中心收到統(tǒng)一認證token令牌和認證渠道，根據(jù)認證渠道判斷是系統(tǒng)內校驗，還是第三方應用校驗。

s09，若認證渠道為統(tǒng)一認證中心認證渠道，則為系統(tǒng)內的渠道，僅需要由統(tǒng)一認證中心本身做校驗即可；

s10，若認證渠道為第三方應用認證渠道，則由統(tǒng)一認證中心根據(jù)映射綁定關系，獲取第三方token令牌，再向第三方應用發(fā)起認證請求；倘若第三方token令牌已經過期，還是由統(tǒng)一認證中心根據(jù)終端提供的appkey和appid向第三方應用請求更新第三方token令牌，并將新的第三方token令牌和統(tǒng)一認證token令牌重新做綁定關系；

s11，第三方應用將認證結果反饋給統(tǒng)一認證中心；

s12，統(tǒng)一認證中心做完認證或收到第三方應用認證結果后，并將校驗結果返回給服務提供方；

s13，服務提供方根據(jù)校驗結果，倘若校驗成功，則返回數(shù)據(jù)請求；否則，返回校驗失敗信息；

s14，倘若終端請求信息返回結果為：統(tǒng)一認證token令牌已過期，則需要重新向統(tǒng)一認證中心請求新的統(tǒng)一認證token令牌，并用該統(tǒng)一認證token令牌再次發(fā)起soa服務應用請求，即從步驟s07重新開始。

當然，上述方法中的oauth開放的授權標準，可以用任何成熟的其他技術框架所替代，統(tǒng)一令牌與第三方令牌種類可以根據(jù)實際情況進行改變。

本實施例基于token的web后臺認證機制，采用oauth(開放授權)授權標準。

oauth開放的授權標準，允許用戶讓第三方應用訪問該用戶在某一web服務上存儲的私密的資源(如照片，視頻，聯(lián)系人列表)，而無需將用戶名和密碼提供給第三方應用。oauth允許用戶提供一個令牌，而不是用戶名和密碼來訪問他們存放在特定服務提供者的數(shù)據(jù)。每一個令牌授權一個特定的第三方系統(tǒng)(例如，視頻編輯網(wǎng)站)在特定的時段(例如，接下來的2小時內)內訪問特定的資源(例如僅僅是某一相冊中的視頻)。這樣，oauth讓用戶可以授權第三方網(wǎng)站訪問他們存儲在另外服務提供者的某些特定信息，而非所有內容。

而tokenauth的更是具有非常多的優(yōu)點：

(1)支持跨域訪問:cookie是不允許垮域訪問的，這一點對token機制是不存在的，前提是傳輸?shù)挠脩粽J證信息通過http頭傳輸。

(2)無狀態(tài)(也稱：服務端可擴展行):token機制在服務端不需要存儲session信息，因為token自身包含了所有登錄用戶的信息，只需要在終端的cookie或本地介質存儲狀態(tài)信息。

(3)更適用cdn:可以通過內容分發(fā)網(wǎng)絡請求你服務端的所有資料(如：javascript，html,圖片等)，而服務端只要提供api即可。

(4)去耦:不需要綁定到一個特定的身份驗證方案。token可以在任何地方生成，只要在api被調用的時候，進行token生成調用即可。

(5)更適用于移動應用:終端是一個原生平臺(ios,android，windows8等)時，cookie是不被支持的(需要通過cookie容器進行處理)，這時采用token認證機制就會簡單得多。

(6)csrf:因為不再依賴于cookie，所以不需要考慮對csrf(跨站請求偽造)的防范。

(7)性能:一次網(wǎng)絡往返時間(通過數(shù)據(jù)庫查詢session信息)總比做一次hmacsha256計算的token驗證和解析要費時得多。

(8)不需要為登錄頁面做特殊處理:如果使用protractor做功能測試的時候，不再需要為登錄頁面做特殊處理。

(9)基于標準化:api可以采用標準化的jsonwebtoken(jwt)。這個標準已經存在多個后端庫(.net,ruby,java,python,php)和多家公司的支持(如：firebase,google,microsoft)。

此外，面向服務技術架構系統(tǒng)之間是解耦，系統(tǒng)之間的通訊通過socket、ftp/文件共享服務器、數(shù)據(jù)庫共享數(shù)據(jù)和message等方式進行交互，上述方法解決了通過socket和message的方式進行交互的應用之間信任問題，以及統(tǒng)一規(guī)范不同應用間信任授權的問題。

綜上所述，本發(fā)明使用了建立統(tǒng)一認證中心的應用，解決了不同應用之間授權認證的問題，以及多個終端(app、web)和不同第三方應用授權認證后，證書和令牌多而混亂，存在網(wǎng)絡狀信息交互，管理不方便的問題。對于終端(app、web)只需要一次在統(tǒng)一認證中心注冊，登記渠道、appkey和appid等信息，并將涉及的第三方應用的令牌等信息在統(tǒng)一認證中心做綁定后，往后只需要管理統(tǒng)一認證中心發(fā)放的令牌即可，使用該令牌訪問服務框架內的任何服務。對于企業(yè)的系統(tǒng)框架來說，建立一個統(tǒng)一認證中心，方便和規(guī)范了應用系統(tǒng)間的訪問認證問題，減少了不同應用間功能的重復建設，解決不同應用間多證書和多令牌管理，簡化網(wǎng)絡拓撲結構，并減少了企業(yè)軟件開發(fā)成本。

根據(jù)上述說明書的揭示和教導，本發(fā)明所屬領域的技術人員還可以對上述實施方式進行變更和修改。因此，本發(fā)明并不局限于上面揭示和描述的具體實施方式，對本發(fā)明的一些修改和變更也應當落入本發(fā)明的權利要求的保護范圍內。此外，盡管本說明書中使用了一些特定的術語，但這些術語只是為了方便說明，并不對本發(fā)明構成任何限制。