專利名稱：一種適用于客戶端平臺的認證授權(quán)方法和系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及互聯(lián)網(wǎng)交互中的安全技術(shù)領(lǐng)域，尤其涉及一種互聯(lián)網(wǎng)平臺服務(wù)接ロ(客戶端平臺)的安全認證和授權(quán)方法及其系統(tǒng)，屬于互聯(lián)網(wǎng)安全技術(shù)領(lǐng)域。
背景技術(shù)：
在互聯(lián)網(wǎng)時代，某些平臺會將自身的服務(wù)封裝為接ロ，供第三方開發(fā)者使用。這些平臺我們一般稱為開放平臺。第三方開發(fā)者通過調(diào)用開放平臺提供的接ロ，可以很方便的導(dǎo)入用戶信息、提供諸如充值等服務(wù)，為第三方開發(fā)者提高了開發(fā)效率、節(jié)約了大量的開發(fā)與運營成本。對開放平臺來說，因為要將用戶信息提供給第三方開發(fā)者，這就涉及到用戶的認證與授權(quán)。由此，OAuth認證授權(quán)協(xié)議應(yīng)運而生，讓你可以在Web或桌面程序中使用簡單而標準的，安全的API認證。用戶希望在第三網(wǎng)站和應(yīng)用上使用他在社會性網(wǎng)絡(luò)服務(wù)SNS網(wǎng)站上的用戶信息，這些第三方網(wǎng)站聯(lián)系SNS網(wǎng)站，但是由于沒有用戶認證信息，這時這些用戶信息是不允許訪問的。比如團購網(wǎng)站，你需要把一條團購信息發(fā)到你的新浪微博上并通知你的好友，以前的方法是你需要在團購網(wǎng)站輸入你的新浪微博賬號，密碼才能調(diào)用，雖然網(wǎng)站上可能都自謂“不保留新浪微博用戶名密碼”，但實際可能并沒有清除棹，OAuth就由此而產(chǎn)生，即用戶訪問第三方資源，不再需要網(wǎng)站提交你的用戶名，密碼。這樣好處自己是安全，而且不會泄露你的隱私給不信任的一方。OAuth 協(xié)議(見 “RFC 5849”The OAuth I. OProtocol ；以及“Draft-ietf-oauth-v2_23，，:The OAuth 2. OAuthorization Protocol,等關(guān)于OAuth協(xié)議)致力于使網(wǎng)站和應(yīng)用程序(應(yīng)用)App/Application(統(tǒng)稱為消費方)能夠在無須用戶透露其認證證書的情況下，通過API訪問某個web服務(wù)(統(tǒng)稱為服務(wù)提供方)的受保護資源。更一般地說，OAuth為API認證提供了ー個可自由實現(xiàn)且通用的方法。ー個典型的例子是某打印服務(wù)提供商printer, example. com(消費方)，希望在無須用戶提供其照片存儲站點密碼的情況下，訪問用戶儲存在photos, example, net (服務(wù)提供方)上的個人照片。如今很多網(wǎng)站的功能都強調(diào)彼此間的交互，因此我們需要一種簡單，標準的解決方案來安全的完成應(yīng)用(應(yīng)用程序/程序)的授權(quán)，即應(yīng)運而生的OAuth。ー個典型的OAuth應(yīng)用通常包括三種角色(認證和授權(quán)的過程中涉及的三方)，分別是Consumer :消費方(客戶端)，要訪問服務(wù)提供方資源的第三方應(yīng)用，通常是網(wǎng)站，如提供照片打印服務(wù)的網(wǎng)站。在認證過程之前，客戶端要向服務(wù)提供者申請客戶端標識。(上述所說的團購網(wǎng)站，也叫第三方網(wǎng)站)。Service Provider :服務(wù)提供者(服務(wù)提供方)，用戶使用服務(wù)提供方來存儲受保護的資源，如照片，視頻，聯(lián)系人列表。(例如上述所說的新浪微博)。User :用戶，存放在服務(wù)提供方的受保護的資源的擁有者。再舉例如下假設(shè)我們做了ー個SNS，它有ー個功能，可以讓會員把他們在Google上的聯(lián)系人導(dǎo)入到SNS上，那么此時的消費方就是SNS，而服務(wù)提供者則是Google，用戶為SNS使用者。通常，使用OAuth進行認證和授權(quán)的過程如下所示I、第三方網(wǎng)站向SNS網(wǎng)站授權(quán)服務(wù)發(fā)出獲取請求令牌request token的請求,SNS授權(quán)服務(wù)響應(yīng)請求，返回一個尚未認證的request token。2、第三方網(wǎng)站獲取響應(yīng)中包含的request token,按照協(xié)議規(guī)范，附帶這個request token,將其重定向到SNS提供的授權(quán)頁面(User Authorization URL)。如果用戶沒有登錄，用戶向普通登錄ー樣，輸入用戶名和密碼完成登錄。如果用戶已經(jīng)登錄(使用記錄Cookie的方式)，會出現(xiàn)ー個頁面，問用戶是否允授權(quán)共享他的SNS信息給第三方網(wǎng)站。3、一旦用戶選擇授權(quán)第三方網(wǎng)站，SNS網(wǎng)站將把Web瀏覽器重定向到第三方網(wǎng)站，同時把SNS的用戶信息傳遞過去。用戶決定允許或拒絕授權(quán)給第三方網(wǎng)站，如果用戶拒絕授權(quán)給此第三方應(yīng)用，則被重定向到SNS的頁面，而不會再回到第三方應(yīng)用的頁面上。如果用戶授權(quán)給第三方網(wǎng)站，那么，SNS授權(quán)服務(wù)接收此請求，將用戶重定向到第三方網(wǎng)站提供的頁面上，并傳遞被認證了的request token。這樣第三方網(wǎng)站就可以訪問SNS網(wǎng)站的用戶信息了。4、第三方網(wǎng)站接收到認證的request token后，再次向SNS賬號服務(wù)發(fā)起一次HTTP請求，以換取訪問令牌access token。SNS賬戶授權(quán)服務(wù)接收請求,驗證是否合法。如果合法，則返回一個access token。OAuth的安全機制，比如使用的簽名加密方法有HMAC-SHA1，RSA-SHAl (可以自定義)。如HMAC-SHA1這種加密碼方法，可以使用私鑰來加密要在網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)，而這個私鑰只有Consumer及服務(wù)提供商知道，試圖攻擊的人即使得到傳輸在網(wǎng)絡(luò)上的字符串，沒有私鑰也無法攻擊。私鑰如consumer secret&token secret (哈兩個密碼加一起)，要加密的字符串是除oauth_signature外的其它要傳輸?shù)臄?shù)據(jù)。按參數(shù)名字符排列，如果一樣，則按內(nèi)容排。比如domain = kejibo. com&oauth_consumer_key = XYZ&word
=welcome......................前面提的加密里面都是固定的字符串，由于oauth_
timestamp, oauth_nonce這兩個是變化的,攻擊者也不能直接偷取使用；而且服務(wù)器會驗證ー個nonce (混淆碼)是否已經(jīng)被使用。那么這樣攻擊者就無法自己生成簽名，或者偷用戶的簽名來使用。到目前為止，OAuth協(xié)議有兩個版本被大家廣泛使用，分別為OAuthl. Oa與0Auth2. O。在OAuthl. Oa中，應(yīng)用方(消費方)需要預(yù)先申請ー個請求令牌RequestToken (如，未授權(quán)的請求令牌。其通常用于消費方向用戶請求對訪問受保護資源的授權(quán)。經(jīng)過用戶授權(quán)的請求令牌可以換取一個訪問令牌，只能使用一次，不得用于其他用途。建議為請求令牌設(shè)置ー個有限的生命期)，在用戶授權(quán)后(用戶授權(quán)請求令牌)，應(yīng)用可以獲得一個授權(quán)過的請求令牌Request Token,在后端將此請求令牌Request Token更換為訪問令牌Access Token(如，消費方用請求令牌換取訪問令牌。其通常用于消費方代表用戶訪問受保護資源。訪問令牌可以被用于限制訪問特定資源，可以只有有限的生命期。服務(wù)提供方應(yīng)當(dāng)允許用戶收回訪問令牌。應(yīng)當(dāng)只 有訪問令牌被用于訪問受保護資源)，此后均使用這個訪問令牌Access Token調(diào)用開放平臺的服務(wù)接ロ。在0Auth2. O中，應(yīng)用方直接要求用戶授權(quán)，在用戶授權(quán)后，應(yīng)用可以獲得ー個授權(quán)過的驗證碼(授權(quán)碼)Auth Code,在后端將此驗證碼Auth Code更換為訪問令牌AccessToken,此后均使用這個訪問令牌Access Token調(diào)用開放平臺的服務(wù)接ロ。OAuth目前支持的OAuth I. Oa和0Auth2. O兩個版本的流程。下面將介紹Oauthl. Oa的流程(詳細流程見圖I)。I :消費方請求 Request Token2 :服務(wù)提供者授權(quán)Request Token3 :消費方定向用戶到服務(wù)提供者4 :獲得用戶授權(quán)后，服務(wù)提供者定向用戶到消費方5 :消費方請求 Access Token6 :服務(wù)提供者授權(quán)Access Token7 :消費方訪問受保護的資源OAuthl. O 定義了三種角色User、Service Provider、Consumer。而0Auth2. 0則定義了四種角色資源擁有者Resource Owner、資源服務(wù)器Resource Server、客戶端 Client、授權(quán)服務(wù)器 Authorization Server 資源擁有者Resource Owner :用戶 User資源服務(wù)器Resource Server :服務(wù)提供者 Service Provider客戶端Client :消費方 Consumer授權(quán)服務(wù)器Authorization Server :服務(wù)提供者 Service Provider0Auth2. O服務(wù)支持以下3種獲取Access Token的方式A.授權(quán)碼Authorization Code :網(wǎng)絡(luò)服務(wù)器流Web Server Flow,適用于所有有服務(wù)器Server端配合的應(yīng)用。B.固有/隱性許可Implicit Grant :用戶代理流User-Agent Flow,適用于所有無Server端配合的應(yīng)用。C刷新令牌Refresh Token :令牌刷新方式,適用于所有有Server端配合的應(yīng)用?；诜桨窤的具體流程見圖2 標準OAuth流程并未提及用戶如何登錄，如果以網(wǎng)頁形式展示登錄頁，并不適合應(yīng)用的接入客戶端形式的平臺，多個應(yīng)用間很難共享用戶的登錄狀態(tài)。標準OAuth流程都是用戶通過獨立的用戶代理User Agent訪問開放平臺的登錄、授權(quán)頁面的。在客戶端形式的平臺上，User Agent與后端的Resource Server實際上是ー個整體，有一部分流程可以取消或者修改，提高整體效率。同時對于服務(wù)提供方(應(yīng)用方)來說，為防止釣魚，必須要在申請應(yīng)用時提供回調(diào)頁面，也提升了應(yīng)用方開發(fā)流程的復(fù)雜程度。在OAuth標準流程中，不良應(yīng)用可能偽造登錄、授權(quán)頁，假的頁面可以做的和真的一祥，用戶如果不注意網(wǎng)址就會上當(dāng)，因而存在網(wǎng)絡(luò)(互聯(lián)網(wǎng))訪問和交互的安全隱患。另外，由于用戶是在用戶客戶端形式的平臺，在打開應(yīng)用時需要先添加應(yīng)用，我們可以認為添加應(yīng)用就是ー個低級別的授權(quán)。用戶ID這樣的用戶最基本信息，可以不用走正式的授權(quán)的流程，平臺可以直接提供給應(yīng)用。但OAuth流程里所有信息都需要用戶授權(quán)后 才能提供，用戶總需要授權(quán)，用戶體驗較差，因而網(wǎng)絡(luò)(互聯(lián)網(wǎng))訪問和交互的效率低下。由此可見，當(dāng)我們的開放平臺需要以客戶端軟件形式對外提供服務(wù)時(客戶端平臺)，上述幾個認證流程并不合適。對于上述流程來說，用戶登錄也需要依靠頁面跳轉(zhuǎn)，應(yīng)用無法獲取到用戶在客戶端平臺上的登錄狀態(tài)；另外，由于授權(quán)頁通過頁面跳轉(zhuǎn)展示，用戶很難分辨授權(quán)頁是否為開放平臺提供，容易產(chǎn)生釣魚的風(fēng)險。

發(fā)明內(nèi)容
本發(fā)明所要解決的技術(shù)問題在于提供ー種能克服現(xiàn)有技術(shù)存在的客戶端平臺(網(wǎng)絡(luò)訪問交互吋)認證和授權(quán)有安全隱患和低效率的缺陷的技術(shù)方案，其能夠在客戶端形式的平臺上，使用戶在使用不同應(yīng)用時只登錄一次；使用客戶端形式的登錄、授權(quán)頁，避免應(yīng)用偽造授權(quán) 頁；取消頁面跳轉(zhuǎn)這ー步驟，提升用戶體驗，并避免用戶需要提前在后臺錄入回調(diào)地址這ー復(fù)雜步驟(提高效率)；以及，進ー步的，允許用戶在添加應(yīng)用后，無需用戶正式的授權(quán)，直接獲取用戶的ー些最基本信息。為解決上述技術(shù)問題，本發(fā)明提供一種用于客戶端平臺的認證授權(quán)方法和系統(tǒng)，其通過改造OAuth協(xié)議、由客戶端平臺為接入的應(yīng)用方提供JS (Javascript)接ロ以完成用戶的登錄、授權(quán)。該方法包括由客戶端平臺為接入的應(yīng)用方提供JS接ロ，且均通過該客戶端平臺提供的JS接ロ進行用戶登錄、授權(quán)認證；啟動客戶端平臺的至少ー個應(yīng)用程序；應(yīng)用程序調(diào)用客戶端平臺JS接ロ獲取當(dāng)前登錄用戶的至少包含用戶名的基本信息；如果返回用戶未登錄、但應(yīng)用程序要求用戶必須登錄時，則應(yīng)用程序調(diào)用登錄JS接ロ ；通過JS接ロ回調(diào)返回所述基本信息和用戶的簽名給應(yīng)用程序；如果應(yīng)用程序判斷此時僅獲得所述用戶名和所述簽名的信息已經(jīng)足夠，則允許用戶進入應(yīng)用程序。該系統(tǒng)由客戶端平臺為接入的應(yīng)用方提供JS接ロ，且均通過該客戶端平臺提供的JS接ロ進行用戶登錄、授權(quán)認證，包括；用于啟動客戶端平臺的至少ー個應(yīng)用程序的裝置；用于應(yīng)用程序調(diào)用客戶端平臺JS接ロ獲取當(dāng)前登錄用戶的至少包含用戶名的基本信息的裝置；用于如果返回的是用戶未登錄但應(yīng)用程序要求用戶必須登錄時，則應(yīng)用程序調(diào)用登錄JS接ロ的裝置；用于通過JS接ロ回調(diào)返回所述基本信息和用戶的簽名給應(yīng)用程序的裝置；用于如果應(yīng)用程序判斷此時僅獲得所述用戶名和所述簽名的信息已經(jīng)足夠，則允許用戶進入應(yīng)用程序的裝置。


為了更清楚地說明本發(fā)明實施例的技術(shù)方案，下面將對實施例描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。圖I為OAuthl的流程圖。圖2為0Auth2的流程圖。圖3為本發(fā)明具體實施方式
的基本流程圖。
具體實施例方式下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。本發(fā)明涉及的優(yōu)選實施方式的主體流程如圖3所示。根據(jù)圖3，詳述本發(fā)明的每ー個步驟。步驟1，用戶打開客戶端平臺上的某個應(yīng)用(即應(yīng)用程序，如充值服務(wù)的應(yīng)用/應(yīng)用程序等)。步驟2,應(yīng)用調(diào)用開放平臺JS(javascript)接ロ獲取當(dāng)前登錄用戶信息。步驟3 (判斷用戶是否登錄)，若當(dāng)前沒有用戶登錄，返回沒有用戶登錄信息給應(yīng)用(如，調(diào)用登錄接ロ、用戶登錄、返回登錄信息) ，如果當(dāng)前用戶已登錄，返回已登錄用戶的基本信息給應(yīng)用，需要附帯用戶信息的簽名。說明此處，如果用戶已登錄，客戶端平臺為保證用戶的隱私，也可以不返回用戶信息，只返回用戶是否登錄。本方案推薦，客戶端平臺返回用戶的基本信息。這樣，直接由客戶端平臺返回的基本信息(已有記錄的)，則不必毎次激活應(yīng)用時都要用戶進行登錄時的授權(quán)認證過程，避免用戶打開應(yīng)用時總是展示授權(quán)頁面，可以提升用戶體驗，提高網(wǎng)絡(luò)訪問和交互的效率。其中用戶簽名的算法可以使用應(yīng)用的App Secret (應(yīng)用/應(yīng)用程序密鑰)做為密鑰，此密鑰通過只有應(yīng)用方與開放平臺預(yù)先設(shè)置知道，所以可以避免用戶被偽造(網(wǎng)絡(luò)中利用算法安全保障)。此外，加密算法中可以加入當(dāng)前的時間戳，當(dāng)前時間戳(OAUTH_timestamp :發(fā)起請求的時間戳，其值是距197000:00:OOGMT的秒數(shù)，必須是大于O的整數(shù)；本次請求的時間戳必須大于或者等于上次的時間戳。參見“http://baike. baidu.com/view/3948029, htm")需要與簽名一起發(fā)送給應(yīng)用(可以預(yù)先設(shè)定ー個允許的時間偏差范圍，如前后兩次請求相差30秒內(nèi)則允許利用該請求反復(fù)進入應(yīng)用，但超出30秒則不允許，而要重新請求、重新提供簽名等)，應(yīng)用需要確定時間偏差在一個許可的范圍內(nèi)，因為如果此次請求被監(jiān)聽后，時間偏差沒有范圍限制(如為系統(tǒng)或程序的時間戳的范圍，而不是將時間偏差限制在ー個允許范圍內(nèi))，那么監(jiān)聽者可以一直用此次請求用的參數(shù)進入該應(yīng)用(到程序或系統(tǒng)溢出為止)，即允許的范圍的確定避免了監(jiān)聽者通過監(jiān)聽到的此次請求后就可以一直用此次請求的參數(shù)進入該應(yīng)用。校驗串算法類似(包括用諸如用戶身份信息用戶姓名、ID、角色和/或簽名等參數(shù)，和/或時間戳、應(yīng)用程序或其接ロ密鑰、密鑰對等參數(shù))md5($name. $id$avatar. $timestamp. $app_key. $app_secretj.說明此校驗算法只是ー個示例，客戶端平臺將用戶身份信息與$timestamp、$app_key、$app_secret 一起做一個哈希即可。步驟4:如果應(yīng)用需要用戶必須登錄，而當(dāng)前用戶沒有登錄，應(yīng)用可以調(diào)用登錄JS接ロ(客戶端授權(quán)接ロ)。說明由于登錄是ー個需要用戶參與的過程，需要在調(diào)用接ロ的時候注冊回調(diào)函數(shù)。此接ロ形式類似 login( ‘callback_fun’，paramA, paramB. · ·)。其中，callback_fun為應(yīng)用自己提供的回調(diào)函數(shù)名，paramA、paramB為login提供的其他參數(shù),與本發(fā)明的核心
流程無關(guān)。步驟5 (只需要用戶基本信息，常見的基本信息如最簡單“用戶名”和/或登錄“密碼，，):在用戶登錄后，會將用戶信息以及簽名通過JS回調(diào)，返回給應(yīng)用。
說明此步返回的信息同步驟3。步驟6 :如果應(yīng)用認為此時獲得的用戶信息已經(jīng)足夠(如用戶基本信息就夠用了，或者用戶基本信息和身份證號碼/電話號碼、或與其簽名信息結(jié)合才夠用等等情況，最簡單的基本信息如“用戶名”信息，就足以登錄觀看游戲模式或者不附加其他權(quán)限的閱讀/瀏覽等)，可以直接將用戶信息以及簽名一起傳入后端，應(yīng)用方校驗后，即可讓用戶進入應(yīng)用。說明校驗算法參見步驟3。步驟7 :如果應(yīng)用還需要用戶的更詳細信息或需要使用開放平臺提供的其他服務(wù)，此時需要調(diào)用授權(quán)的JS接ロ(客戶端授權(quán)接ロ)。說明此授權(quán)接ロ形式類似授權(quán)/許可authorize ( ‘callback_fun’，params_arr)。其中，callback_fun為應(yīng)用自己提供的回調(diào)函數(shù)名，params_arr為ー個授權(quán)參數(shù)的數(shù)組，包括選擇OAuthl. Oa還是0Auth2. O,包括授權(quán)的scope等參數(shù)。步驟8 :輸出交互，如桌面客戶端展示授權(quán)窗ロ。步驟9 :用戶同意授權(quán)后，客戶端平臺將相關(guān)信息提交到后端服務(wù)器，后端服務(wù)器返回授權(quán)的請求令牌 Request Token(OAuthl.Oa)或 Auth Code (0Auth2)。步驟10 :客戶端平臺通過JS回調(diào)(如通過JS的結(jié)果返回)，通知應(yīng)用RequestToken(0Auth I.0a)或 Auth Code (0Auth2)。說明此處的JS回調(diào)函數(shù)名正是步驟7中傳入的回調(diào)函數(shù)。步驟11 :應(yīng)用將 Request Token(0Auth 1.0a)或 Auth Code (0Auth2)傳入后端。(如JS接ロ傳遞授權(quán)結(jié)果時，只傳遞驗證碼(Auth Code)，驗證碼在應(yīng)用的服務(wù)端使用且僅使用一次)步驟12 :應(yīng)用后端換取訪問令牌Access Token,調(diào)用服務(wù)接ロ，如用戶詳細信息。步驟13 :應(yīng)用允許用戶進入應(yīng)用。由上述優(yōu)選方式的描述結(jié)合圖3的流程可知，認證授權(quán)相關(guān)的所有接ロ均通過客戶端平臺提供JS接ロ實現(xiàn)；授權(quán)頁通過新開窗ロ實現(xiàn)，可避免被應(yīng)用偽造JS傳遞授權(quán)結(jié)果時，只傳遞授權(quán)碼/驗證碼Auth Code，這個Auth Code需要在應(yīng)用的服務(wù)端使用，且只能使用一次，可避免在應(yīng)用方?jīng)]有https服務(wù)時,信息被監(jiān)聽而造成最終的Access Token泄漏；如果應(yīng)用只是想獲取用戶最基本信息，客戶端平臺可以跳過授權(quán)流程，直接返回用戶基本信息給應(yīng)用，以提高用戶體驗JS傳遞用戶信息給應(yīng)用時需要帶簽名，可避免用戶被惡意篡改，出現(xiàn)刷賬號的問題；ー些需要用戶參與才能返回結(jié)果的流程，需要通過Js回調(diào)返回相應(yīng)結(jié)果；通過識別JS授權(quán)相關(guān)接ロ是否存在，應(yīng)用可以判斷是否在客戶端平臺內(nèi)運行，以采取相應(yīng)的登錄授權(quán)流程。上述具體實施方式
的每個步驟還可以有相應(yīng)的實現(xiàn)裝置。本發(fā)明最終實現(xiàn)在同一客戶端平臺下的不同應(yīng)用間共享用戶登錄狀態(tài)；應(yīng)用接入認證授權(quán)流程無需頁面跳轉(zhuǎn)，所以開發(fā)者無需在申請應(yīng)用時，提前在后端錄入應(yīng)用的回跳地址，以防止釣魚問題；授權(quán)頁通過新開窗ロ實現(xiàn)，可避免應(yīng)用自己偽造授權(quán)頁面；用戶在添加應(yīng)用后，無需用戶正式的授權(quán)，應(yīng)用直接獲取用戶的ー些最基本信息，以提高用戶體驗。這樣提高了網(wǎng)絡(luò)訪問和交互的安全性、以及網(wǎng)絡(luò)訪問/交互的效率。本說明書中的各個實施例一般采用遞進的方式描述，每個實施例重點說明的都是與其他實施例的不同之處，各個實施例之間相同相似的部分互相參見即可。本申請可以在由計算機執(zhí)行的計算機可執(zhí)行指令的一般上下文中描述，例如程序模塊或単元。一般地，程序模塊或単元可以包括執(zhí)行特定任務(wù)或?qū)崿F(xiàn)特定抽象數(shù)據(jù)類型的例程、程序、對象、組件、數(shù)據(jù)結(jié)構(gòu)等等。一般來說，程序模塊或単元可以由軟件、硬件或兩者的結(jié)合來實現(xiàn)。也可以在分布式計算環(huán)境中實踐本申請，在這些分布式計算環(huán)境中，由通過通信網(wǎng)絡(luò)而被連接的遠程處理設(shè)備來執(zhí)行任務(wù)。在分布式計算環(huán)境中，程序模塊或単元可以位于包括存儲設(shè)備在內(nèi)的本地和遠程計算機存儲介質(zhì)中。最后，還需要說明的是，術(shù)語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設(shè)備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設(shè)備所固有的
要素。在沒有更多限制的情況下，由語句“包括ー個......”限定的要素，并不排除在包括
所述要素的過程、方法、商品或者設(shè)備中還存在另外的相同要素。
本文中應(yīng)用了具體個例對本申請的原理及實施方式進行了闡述，以上實施例的說明只是用于幫助理解本申請的方法及其主要思想；同時，對于本領(lǐng)域的一般技術(shù)人員，依據(jù)本申請的思想，在具體實施方式
及應(yīng)用范圍上均會有改變之處，綜上所述，本說明書內(nèi)容不應(yīng)理解為對本申請的限制。
權(quán)利要求
1.一種用于客戶端平臺的認證授權(quán)方法，其特征在于由客戶端平臺為接入的應(yīng)用方提供JS接ロ，且均通過該客戶端平臺提供的JS接ロ進行用戶登錄、授權(quán)認證，包括 啟動客戶端平臺的至少ー個應(yīng)用程序； 應(yīng)用程序調(diào)用客戶端平臺JS接ロ獲取當(dāng)前登錄用戶的至少包含用戶名的基本信息； 如果返回用戶未登錄、但應(yīng)用程序要求用戶必須登錄時，則應(yīng)用程序調(diào)用登錄JS接Π ； 通過JS接ロ回調(diào)返回所述基本信息和用戶的簽名給應(yīng)用程序； 如果應(yīng)用程序判斷此時僅獲得所述用戶名和所述簽名的信息已經(jīng)足夠，則允許用戶進入應(yīng)用程序。
2.如權(quán)利要求I所述的方法，其中，還包括 如果返回用戶已登錄，則返回用戶的所述基本信息給應(yīng)用程序，并附帶用戶信息的所述簽名。
3.如權(quán)利要求2所述的方法，其中，還包括允許用戶進入應(yīng)用程序之前 所述簽名的算法使用應(yīng)用程序的App Secret作為密鑰； 設(shè)定ー個允許的時間偏差允許范圍； 加密算法加入當(dāng)前時間戳，當(dāng)前時間戳與所述簽名一起發(fā)送給應(yīng)用程序； 應(yīng)用程序確定時間偏差在該允許范圍內(nèi)；以及 利用所述時間戳、密鑰和所述基本信息一起完成校驗。
4.如權(quán)利要求1、2或3所述的方法，其中還包括 如果應(yīng)用程序判斷僅獲得所述用戶名和所述簽名的信息不足夠使用，則調(diào)用授權(quán)的JS接ロ，并通過新開啟的窗ロ顯不授權(quán)頁； 當(dāng)授權(quán)得到同意，則客戶端平臺將相關(guān)信息提交到后端服務(wù)器，后端服務(wù)器返回授權(quán)的請求令牌或驗證碼； 當(dāng)授權(quán)未得到同意則認證授權(quán)流程結(jié)束。
5.如權(quán)利要求4所述的方法，其中，當(dāng)返回授權(quán)的請求令牌或驗證碼后，進ー步包括 客戶端通過JS接ロ回調(diào)，通知應(yīng)用程序請求令牌或驗證碼； 應(yīng)用程序?qū)⒄埱罅钆苹蝌炞C碼傳入后端服務(wù)器； 應(yīng)用程序在后端換取訪問令牌，調(diào)用服務(wù)接ロ ； 應(yīng)用程序允許用戶進入應(yīng)用程序。
6.如權(quán)利要求5所述的方法，其中，進ー步包括 上述通過JS接ロ回調(diào)、通知應(yīng)用程序請求令牌或驗證碼吋，只傳遞驗證碼(AuthCode, 0Auth2)或授權(quán)過的Request Token (OAuthl),驗證碼在應(yīng)用程序的服務(wù)端使用且僅使用一次。
7.如權(quán)利要求1、2、3、5或6所述的方法，其中還包括所述由客戶端平臺為接入的應(yīng)用方提供JS接ロ后，識別提供的JS接ロ是否存在，應(yīng)用程序判斷應(yīng)用程序的服務(wù)是否在客戶端平臺內(nèi)運行，以采取相應(yīng)的所述登錄、授權(quán)認征。
8.如權(quán)利要求1、2、3、5或6所述的方法，其中還包括 需要用戶授權(quán)的過程中，在調(diào)用JS接ロ的時候，注冊回調(diào)函數(shù)，并通過JS接ロ的回調(diào)返回相應(yīng)結(jié)果。
9.一種用于客戶端平臺的認證授權(quán)系統(tǒng)，其特征在于由客戶端平臺為接入的應(yīng)用方提供JS接ロ，且均通過該客戶端平臺提供的JS接ロ進行用戶登錄、授權(quán)認證，包括 用于啟動客戶端平臺的至少ー個應(yīng)用程序的裝置； 用于應(yīng)用程序調(diào)用客戶端平臺JS接ロ獲取當(dāng)前登錄用戶的至少包含用戶名的基本信息的裝置； 用于如果返回的是用戶未登錄但應(yīng)用程序要求用戶必須登錄時，則應(yīng)用程序調(diào)用登錄JS接ロ的裝置； 用于通過JS接ロ回調(diào)返回所述基本信息和用戶的簽名給應(yīng)用程序的裝置； 用于如果應(yīng)用程序判斷此時僅獲得所述用戶名和所述簽名的信息已經(jīng)足夠，則允許用戶進入應(yīng)用程序的裝置。
10.如權(quán)利要求9所述的系統(tǒng)，其中，還包括 用于如果返回的是用戶已登錄，則返回用戶的所述基本信息給應(yīng)用程序，并附帶用戶信息的所述簽名的裝置。
11.如權(quán)利要求10所述的系統(tǒng)，其中，還包括允許用戶進入應(yīng)用程序之前 用于所述簽名的算法使用應(yīng)用程序的App Secret作為密鑰的裝置； 用于設(shè)定一個允許的時間偏差允許范圍的裝置； 用于加密算法加入當(dāng)前時間戳，當(dāng)前時間戳與簽名一起發(fā)送給應(yīng)用程序的裝置； 用于應(yīng)用程序確定時間偏差在該允許范圍內(nèi)的裝置；以及 用于利用所述時間戳、密鑰和所述基本信息一起完成校驗的裝置。
12.如權(quán)利要求9、10或11所述的方法，其中還包括 用于如果應(yīng)用程序判斷僅獲得所述用戶名和所述簽名的信息不足夠使用則調(diào)用授權(quán)的JS接ロ、并通過新開啟的窗ロ顯示授權(quán)頁的裝置； 用于當(dāng)授權(quán)得到同意則客戶端平臺將相關(guān)信息提交到后端服務(wù)器、后端服務(wù)器返回授權(quán)的請求令牌或驗證碼的裝置； 用于當(dāng)授權(quán)未得到同意則認證授權(quán)流程結(jié)束的裝置。
13.如權(quán)利要求12所述的系統(tǒng)，其中，當(dāng)返回授權(quán)的請求令牌或驗證碼后，進ー步包括 用于客戶端通過JS接ロ回調(diào)、通知應(yīng)用程序請求令牌或驗證碼的裝置； 用于應(yīng)用程序?qū)⒄埱罅钆苹蝌炞C碼傳入后端服務(wù)器的裝置； 用于應(yīng)用程序在后端換取訪問令牌、調(diào)用服務(wù)接ロ的裝置； 用于應(yīng)用程序允許用戶進入應(yīng)用程序的裝置。
14.如權(quán)利要求13所述的系統(tǒng)，其中，進ー步包括 用于上述通過JS接ロ回調(diào)、通知應(yīng)用程序請求令牌或驗證碼吋，只傳遞驗證碼(AuthCode, 0Auth2)或授權(quán)過的Request Token (OAuthl)、驗證碼在應(yīng)用程序的服務(wù)端使用且僅使用一次的裝置。
15.如權(quán)利要求9、10、11、13或14所述的系統(tǒng)，其中還包括所述由客戶端平臺為接入的應(yīng)用方提供JS接ロ后， 用于識別提供的JS接ロ是否存在、應(yīng)用程序判斷應(yīng)用程序的服務(wù)是否在客戶端平臺內(nèi)運行、以采取相應(yīng)的所述登錄、授權(quán)認證的裝置。
16.如權(quán)利要求9、10、11、13或14所述的系統(tǒng)，其中還包括 用于需要用戶授權(quán)的過程中、在調(diào)用JS接ロ的時候注冊回調(diào)函數(shù)并通過JS接ロ的回調(diào)返回相應(yīng)結(jié)果的裝置。
全文摘要
本發(fā)明公開了一種用于客戶端平臺的認證授權(quán)方法和系統(tǒng)。該方法和系統(tǒng)基于協(xié)議的修改，均由客戶端平臺為接入的應(yīng)用方提供JS接口進行用戶登錄、授權(quán)認證；啟動客戶端平臺的至少一個應(yīng)用程序；應(yīng)用程序調(diào)用客戶端平臺JS接口獲取當(dāng)前登錄用戶的至少包含用戶名的基本信息；如果返回用戶未登錄、但應(yīng)用程序要求用戶必須登錄時，則應(yīng)用程序調(diào)用登錄JS接口；通過JS接口回調(diào)返回所述基本信息和用戶的簽名給應(yīng)用程序；如果應(yīng)用程序判斷此時僅獲得所述用戶名和所述簽名的信息已經(jīng)足夠，則允許用戶進入應(yīng)用程序。從而多用戶共享多應(yīng)用、避免應(yīng)用偽造授權(quán)頁、提升用戶體驗、無需提前后臺錄入回調(diào)地址、在添加應(yīng)用后無需用戶正式授權(quán)而獲取基本信息。
文檔編號H04L29/06GK102624739SQ201210091019
公開日2012年8月1日 申請日期2012年3月30日 優(yōu)先權(quán)日2012年3月30日
發(fā)明者東瑋 申請人:奇智軟件(北京)有限公司