單點登錄技術(shù)中的主令牌獲取方法、單點登錄方法及系統(tǒng)的制作方法
【專利摘要】本發(fā)明提供的單點登錄技術(shù)中的主令牌獲取方法，涉及互聯(lián)網(wǎng)領(lǐng)域，該方法通過手機端首先要通過識別碼下發(fā)服務(wù)器的驗證來換取識別碼，之后在期望獲取主令牌的時候，使用手機端將該識別碼發(fā)送給令牌頒發(fā)服務(wù)器，之后令牌頒發(fā)服務(wù)器將該識別碼提供給識別碼下發(fā)服務(wù)器進行驗證，只有該次驗證通過后，令牌頒發(fā)服務(wù)器才會將對應(yīng)的主令牌提供給手機端，這樣，即使外部設(shè)備知悉了賬戶和密碼，由于外部設(shè)備無法通過識別碼下發(fā)服務(wù)器的驗證，導(dǎo)致其依舊無法獲取主令牌，保證了主令牌下發(fā)的安全性，也就保證了單點登錄整體的安全性。
【專利說明】
單點登錄技術(shù)中的主令牌獲取方法、單點登錄方法及系統(tǒng)
技術(shù)領(lǐng)域
[0001] 本發(fā)明涉及互聯(lián)網(wǎng)領(lǐng)域，具體而言，涉及單點登錄技術(shù)中的主令牌獲取方法、登錄 方法及系統(tǒng)。
【背景技術(shù)】
[0002] 傳統(tǒng)的互聯(lián)網(wǎng)服務(wù)技術(shù)通常是由兩端通過數(shù)據(jù)交互完成的，這兩端分別是用戶操 作的終端(如手機、平板電腦)和網(wǎng)絡(luò)服務(wù)商所提供的網(wǎng)絡(luò)端(如各種類型的服務(wù)器）。在用 戶上線，或者用戶發(fā)起操作之前，網(wǎng)絡(luò)端需要對用戶的身份進行認證，以確保用戶是合法用 戶。隨著網(wǎng)絡(luò)服務(wù)商所提供網(wǎng)絡(luò)應(yīng)用的數(shù)量的增加，用戶每操作一個應(yīng)用，就需要對應(yīng)的網(wǎng) 絡(luò)端對該用戶進行一次認證，這使得用戶的使用不同的應(yīng)用時變得很繁瑣，而且需要記錄 大量的賬號和密碼。針對此種情況，后續(xù)出現(xiàn)了單點登錄記錄。
[0003] 首先，對單點登錄技術(shù)(Single Sign On)進行簡要介紹，該技術(shù)簡稱為SS0,是目 前比較流行的企業(yè)業(yè)務(wù)整合的解決方案之一。SS0的定義是在多個應(yīng)用系統(tǒng)中，用戶只需要 登錄一次就可以訪問所有相互信任的應(yīng)用系統(tǒng)。
[0004] 之后，隨著移動互聯(lián)網(wǎng)技術(shù)的發(fā)展，也出現(xiàn)了為移動端（用戶所操作的終端)進行 單點登錄驗證的技術(shù)，這種針對移動端進行單點登錄驗證的技術(shù)稱為NAPPS是Native App SS0的縮寫，即移動應(yīng)用程序單點登錄。
[0005] 通常情況下，NAPPS只支持0IDC協(xié)議的單點登錄，并且，傳統(tǒng)的單點登錄技術(shù)的安 全性較差。

【發(fā)明內(nèi)容】

[0006] 本發(fā)明的目的在于提供單點登錄技術(shù)中的主令牌獲取方法、登錄方法及系統(tǒng)，以 提高單點登錄的安全性。
[0007] 第一方面，本發(fā)明實施例提供了單點登錄技術(shù)中的主令牌獲取方法，包括：
[0008] 手機端的認證請求模塊向識別碼下發(fā)服務(wù)器發(fā)出獲取識別碼請求；
[0009] 識別碼下發(fā)服務(wù)器對所述獲取識別碼請求進行驗證，若驗證通過，則識別碼下發(fā) 服務(wù)器向所述認證請求模塊返回第一驗證通過信息，所述第一驗證通過信息中攜帶有識別 碼；
[0010] 所述認證請求模塊向所述手機端的令牌轉(zhuǎn)發(fā)模塊發(fā)送獲取主令牌請求，所述獲取 主令牌請求中攜帶有識別碼；
[0011] 所述令牌轉(zhuǎn)發(fā)模塊將所述獲取主令牌請求向令牌頒發(fā)服務(wù)器轉(zhuǎn)發(fā)；
[0012] 令牌頒發(fā)服務(wù)器向所述識別碼下發(fā)服務(wù)器發(fā)送所述獲取主令牌請求中的識別碼；
[0013] 識別碼下發(fā)服務(wù)器驗證所述識別碼；
[0014] 若所述識別碼下發(fā)服務(wù)器驗證所述獲取主令牌請求中的識別碼為真，則識別碼下 發(fā)服務(wù)器向令牌頒發(fā)服務(wù)器發(fā)出第二驗證通過信息；
[0015] 令牌頒發(fā)服務(wù)器在接收到所述第二驗證通過信息后，向所述令牌轉(zhuǎn)發(fā)模塊頒發(fā)用 于進行單點登錄驗證的主令牌。
[0016] 第二方面，本發(fā)明實施例還提供了單點登錄技術(shù)中的主令牌獲取系統(tǒng)，包括：
[0017] 手機端的認證請求模塊，用于向識別碼下發(fā)服務(wù)器發(fā)出獲取識別碼請求；
[0018] 識別碼下發(fā)服務(wù)器，用于對所述獲取識別碼請求進行驗證，若驗證通過，則識別碼 下發(fā)服務(wù)器，進一步用于向所述認證請求模塊返回第一驗證通過信息，所述第一驗證通過 信息中攜帶有識別碼；
[0019] 所述認證請求模塊，還用于向所述手機端的令牌轉(zhuǎn)發(fā)模塊發(fā)送獲取主令牌請求， 所述獲取主令牌請求中攜帶有識別碼；
[0020] 所述令牌轉(zhuǎn)發(fā)模塊，用于將所述獲取主令牌請求向令牌頒發(fā)服務(wù)器轉(zhuǎn)發(fā)；
[0021] 令牌頒發(fā)服務(wù)器，用于向所述識別碼下發(fā)服務(wù)器發(fā)送所述獲取主令牌請求中的識 別碼；
[0022]識別碼下發(fā)服務(wù)器，還用于驗證所述識別碼；
[0023] 若所述識別碼下發(fā)服務(wù)器驗證所述獲取主令牌請求中的識別碼為真，則識別碼下 發(fā)服務(wù)器，進一步用于向令牌頒發(fā)服務(wù)器發(fā)出第二驗證通過信息；
[0024] 令牌頒發(fā)服務(wù)器，還用于在接收到所述第二驗證通過信息后，向所述令牌轉(zhuǎn)發(fā)模 塊頒發(fā)用于進行單點登錄驗證的主令牌。
[0025] 第三方面，本發(fā)明實施例還提供了單點登錄方法，包括如第一方面的單點登錄技 術(shù)中的主令牌獲取方法，還包括：
[0026] 手機端的接口調(diào)用模塊在獲取到登錄指令后，向所述令牌轉(zhuǎn)發(fā)模塊發(fā)送登錄指令 所對應(yīng)的子賬戶用戶名和子應(yīng)用標(biāo)識；
[0027] 令牌轉(zhuǎn)發(fā)模塊向令牌頒發(fā)服務(wù)器發(fā)送獲取子令牌請求，所述獲取子令牌請求中攜 帶有所述子賬戶用戶名、所述子應(yīng)用標(biāo)識和所述主令牌；
[0028]令牌頒發(fā)服務(wù)器根據(jù)子應(yīng)用標(biāo)識驗證所述手機端是否已經(jīng)在令牌頒發(fā)服務(wù)器中 注冊過；
[0029] 若是，則令牌頒發(fā)服務(wù)器根據(jù)子應(yīng)用標(biāo)識，將所述子賬戶用戶名和所述主令牌發(fā) 送至相應(yīng)的驗證服務(wù)器；
[0030] 驗證服務(wù)器驗證所述子賬戶用戶名和所述主令牌是否符合預(yù)設(shè)要求;若是，則驗 證服務(wù)器將所述子賬戶用戶名所對應(yīng)的子令牌發(fā)送至令牌頒發(fā)服務(wù)器；
[0031 ]令牌頒發(fā)服務(wù)器將所述子令牌發(fā)送至所述令牌轉(zhuǎn)發(fā)模塊；
[0032] 所述令牌轉(zhuǎn)發(fā)模塊將所述子令牌發(fā)送至手機端的應(yīng)用模塊；
[0033] 所述應(yīng)用模塊向所述應(yīng)用服務(wù)器發(fā)起登錄請求，所述登錄請求中攜帶有所述子令 牌；
[0034]所述應(yīng)用服務(wù)器驗證所述子令牌是否為真，或是，則所述登錄請求通過。
[0035]第四方面，本發(fā)明實施例還提供了單點登錄系統(tǒng)，包括如第二的單點登錄技術(shù)中 的主令牌獲取系統(tǒng)，還包括：
[0036]手機端的接口調(diào)用模塊，用于在獲取到登錄指令后，向所述令牌轉(zhuǎn)發(fā)模塊發(fā)送登 錄指令所對應(yīng)的子賬戶用戶名和子應(yīng)用標(biāo)識；
[0037]令牌轉(zhuǎn)發(fā)模塊，還用于向令牌頒發(fā)服務(wù)器發(fā)送獲取子令牌請求，所述獲取子令牌 請求中攜帶有所述子賬戶用戶名、所述子應(yīng)用標(biāo)識和所述主令牌；
[0038] 令牌頒發(fā)服務(wù)器，還用于根據(jù)子應(yīng)用標(biāo)識驗證所述手機端是否已經(jīng)在令牌頒發(fā)服 務(wù)器中注冊過；
[0039] 若是，則令牌頒發(fā)服務(wù)器，還用于根據(jù)子應(yīng)用標(biāo)識，將所述子賬戶用戶名和所述主 令牌發(fā)送至相應(yīng)的驗證服務(wù)器；
[0040] 驗證服務(wù)器驗證，用于所述子賬戶用戶名和所述主令牌是否符合預(yù)設(shè)要求;若是， 則驗證服務(wù)器，進一步用于將所述子賬戶用戶名所對應(yīng)的子令牌發(fā)送至令牌頒發(fā)服務(wù)器； [0041 ]令牌頒發(fā)服務(wù)器，還用于將所述子令牌發(fā)送至所述令牌轉(zhuǎn)發(fā)模塊；
[0042] 所述令牌轉(zhuǎn)發(fā)模塊，還用于將所述子令牌發(fā)送至手機端的應(yīng)用模塊；
[0043] 所述應(yīng)用模塊，用于向所述應(yīng)用服務(wù)器發(fā)起登錄請求，所述登錄請求中攜帶有所 述子令牌；
[0044] 所述應(yīng)用服務(wù)器，用于驗證所述子令牌是否為真，或是，則所述登錄請求通過。
[0045] 本發(fā)明實施例提供的單點登錄技術(shù)中的主令牌獲取方法，采用只有在期望獲取主 令牌的手機端在識別碼下發(fā)服務(wù)器進行二次驗證后才能夠獲取主令牌，與現(xiàn)有技術(shù)中期望 獲取主令牌的手機需要通過多個步驟的驗證，以及code(認證碼）的傳遞才能夠通過用戶名 和密碼獲取訪問用的令牌相比，其通過手機端首先要通過識別碼下發(fā)服務(wù)器的驗證來換取 識別碼，之后在期望獲取主令牌的時候，使用手機端將該識別碼發(fā)送給令牌頒發(fā)服務(wù)器，之 后令牌頒發(fā)服務(wù)器將該識別碼提供給識別碼下發(fā)服務(wù)器進行驗證，只有該詞驗證通過后， 令牌頒發(fā)服務(wù)器才會將對應(yīng)的主令牌提供給手機端，這樣，即使外部設(shè)備知悉了賬戶和密 碼，由于外部設(shè)備無法通過識別碼下發(fā)服務(wù)器的驗證，導(dǎo)致其依舊無法獲取主令牌，保證了 主令牌下發(fā)的安全性，也就保證了單點登錄整體的安全性。
[0046]為使本發(fā)明的上述目的、特征和優(yōu)點能更明顯易懂，下文特舉較佳實施例，并配合 所附附圖，作詳細說明如下。
【附圖說明】
[0047] 為了更清楚地說明本發(fā)明實施例的技術(shù)方案，下面將對實施例中所需要使用的附 圖作簡單地介紹，應(yīng)當(dāng)理解，以下附圖僅示出了本發(fā)明的某些實施例，因此不應(yīng)被看作是對 范圍的限定，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這 些附圖獲得其他相關(guān)的附圖。
[0048] 圖1示出了相關(guān)技術(shù)中，進行單點登錄的網(wǎng)絡(luò)框架示意圖；
[0049] 圖2示出了本發(fā)明實施例所提供的單點登錄技術(shù)中的主令牌獲取方法的基本流程 圖；
[0050] 圖3示出了本發(fā)明實施例所提供的單點登錄技術(shù)的一種網(wǎng)絡(luò)框架實例示意圖；
[0051 ]圖4示出了本發(fā)明實施例所提供的單點登錄技術(shù)的基本流程圖；
[0052] 圖5示出了本發(fā)明實施例所提供的單點登錄技術(shù)的另一種網(wǎng)絡(luò)框架實例示意圖；
[0053] 圖6示出了本發(fā)明實施例所提供的單點登錄技術(shù)中，進行單點退出流程的網(wǎng)絡(luò)框 架示意圖。
【具體實施方式】
[0054]下面將結(jié)合本發(fā)明實施例中附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整 地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例。通常在 此處附圖中描述和示出的本發(fā)明實施例的組件可以以各種不同的配置來布置和設(shè)計。因 此，以下對在附圖中提供的本發(fā)明的實施例的詳細描述并非旨在限制要求保護的本發(fā)明的 范圍，而是僅僅表示本發(fā)明的選定實施例?；诒景l(fā)明的實施例，本領(lǐng)域技術(shù)人員在沒有做 出創(chuàng)造性勞動的前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。
[0055] 隨著網(wǎng)絡(luò)技術(shù)的發(fā)展，網(wǎng)絡(luò)供應(yīng)商所提供的而網(wǎng)絡(luò)服務(wù)也越來越多，如微信、迅雷 等等。網(wǎng)絡(luò)服務(wù)的網(wǎng)絡(luò)框架通?？梢杂蓛啥私M成，也就是網(wǎng)絡(luò)供應(yīng)商所控制的網(wǎng)絡(luò)端(通常 也被稱為服務(wù)器)和由用戶所控制的終端(如手機）。為了提高用戶使用的便捷性，技術(shù)人員 研發(fā)出了單點登錄技術(shù)，之后，進一步的開發(fā)出了針對移動應(yīng)用程序的單點登錄技術(shù)。但是 傳統(tǒng)的單點登錄技術(shù)有一定的弊端，如圖1所示，提供了傳統(tǒng)的單點登錄技術(shù)的網(wǎng)絡(luò)架構(gòu) 圖，對應(yīng)的具體流程如下：
[0056] 1，TA提供用戶名/密碼或其它進行認證，并且獲取PT;通常，該步驟發(fā)生在內(nèi)置或 是共享的瀏覽器上；
[0057] 2，TA利用code(認證碼)換取PT(主令牌），為將來換取ST(子令牌)做準(zhǔn)備；
[0058] 3，TA為一個應(yīng)用發(fā)起獲取令牌的請求；
[0059] 4，AS(令牌服務(wù)器)返回子令牌；
[0060] 5，TA轉(zhuǎn)交ST給相應(yīng)的App;
[0061 ] 6，App使用ST訪問應(yīng)用RS受保護的資源；
[0062] 7，RS(資源服務(wù)器)在AS處通過自我校驗或通過AS驗證簽名，驗證AT是否正確，決 定是否放行。
[0063]圖1中，TA(Token Agent)令牌代理，用于存儲并發(fā)送令牌;AS為用于驗證令牌的服 務(wù)器;存儲有Appl-App3三個應(yīng)用程序的終端是用戶的手機，存儲有RS1-RS3的服務(wù)器是網(wǎng) 絡(luò)服務(wù)商提供的存儲有服務(wù)程序的服務(wù)器，其中，RS1-RS3服務(wù)程序和Appl-App3三個應(yīng)用 程序是相對應(yīng)的;PT是令牌，用于證明用戶身份。
[0064]可見傳統(tǒng)的單點登錄流程中獲取令牌的過程是通過層層的認證來獲取的，其根本 是使用用戶名和密碼進行驗證，當(dāng)用戶名和密碼泄露之后，其安全性也就難以得到保證了。 有鑒于此，本申請?zhí)峁┝藛吸c登錄技術(shù)中的主令牌獲取方法，如圖1所示，包括如下步驟： [0065] S101，手機端的認證請求模塊向識別碼下發(fā)服務(wù)器發(fā)出獲取識別碼請求；
[0066] S102，識別碼下發(fā)服務(wù)器對獲取識別碼請求進行驗證，若驗證通過，則識別碼下發(fā) 服務(wù)器向認證請求模塊返回第一驗證通過信息，第一驗證通過信息中攜帶有識別碼；
[0067] S103,認證請求模塊向手機端的令牌轉(zhuǎn)發(fā)模塊發(fā)送獲取主令牌請求，獲取主令牌 請求中攜帶有識別碼；
[0068] S104,令牌轉(zhuǎn)發(fā)模塊將獲取主令牌請求向令牌頒發(fā)服務(wù)器轉(zhuǎn)發(fā)；
[0069] S105,令牌頒發(fā)服務(wù)器向識別碼下發(fā)服務(wù)器發(fā)送獲取主令牌請求中的識別碼；
[0070] S106，識別碼下發(fā)服務(wù)器驗證識別碼；
[0071] S107,若識別碼下發(fā)服務(wù)器驗證獲取主令牌請求中的識別碼為真，則識別碼下發(fā) 服務(wù)器向令牌頒發(fā)服務(wù)器發(fā)出第二驗證通過信息；
[0072] S108,令牌頒發(fā)服務(wù)器在接收到第二驗證通過信息后，向令牌轉(zhuǎn)發(fā)模塊頒發(fā)用于 進行單點登錄驗證的主令牌。
[0073] 如圖3所示，提供了圖2所示方法的網(wǎng)絡(luò)框架示意圖。圖中，Client為手機端的認證 請求模塊，TA為手機端的令牌轉(zhuǎn)發(fā)模塊，IDS為令牌頒發(fā)服務(wù)器，Server為識別碼下發(fā)服務(wù) 器。
[0074] 通過上述流程可知，本申請所提供的方法中，如果手機端期望獲取主令牌，則需要 先在向識別碼下發(fā)服務(wù)器進行驗證，只有驗證通過后(驗證通過，則說明識別碼下發(fā)服務(wù)器 認為該手機端的認證請求模塊是合法的），識別碼下發(fā)服務(wù)器才會將識別碼提供給手機端。 之后，手機端在需要獲取主令牌的時候，是使用獲取到的識別碼來換取，具體的換取過程是 先將該識別碼發(fā)送給主令牌頒發(fā)服務(wù)器，由于該服務(wù)器無法驗證識別碼的真?zhèn)危ㄗR別碼有 識別碼下發(fā)服務(wù)器才知曉），因此，需要將識別碼轉(zhuǎn)發(fā)給識別碼下發(fā)服務(wù)器進行識別。前序 步驟(S102)中，識別碼下發(fā)服務(wù)器在向手機端返回第一驗證通過信息的同時，還會存儲該 識別碼。之后識別碼下發(fā)服務(wù)器比對接收到的識別碼和步驟S102中所發(fā)出的識別碼是否相 同，如果相同就向令牌頒發(fā)服務(wù)器發(fā)出第二驗證通過信息，以表達手機端所發(fā)出的識別碼 是真實有效的。之后，令牌頒發(fā)服務(wù)器才會將主令牌提供給手機端。該過程中，由于手機端 獲取主令牌前需要由識別碼下發(fā)服務(wù)器進行校驗，其校驗的是該設(shè)備是否通過了步驟S102 的驗證(驗證后便視為該設(shè)備注冊過），進而保證了只有注冊過的設(shè)備才能夠得到主令牌， 而其他設(shè)備即使了解了賬號、密碼也無法獲取主令牌(其他設(shè)備無法得到步驟S102中的識 別碼）。
[0075]具體的，執(zhí)行步驟S101-步驟S108有兩種具體情況，第一種情況是手機端還未進行 注冊，也就是首次使用的時候，需要使用識別碼下發(fā)服務(wù)器所提供的激活鏈接進行識別碼 的獲取，以保證安全性。在該種情況下，獲取識別碼請求中存在的是用戶通過點擊激活鏈接 而生成的激活碼。也就是:若獲取識別碼請求中攜帶有激活碼，則識別碼下發(fā)服務(wù)器對獲取 識別碼請求進行驗證包括：
[0076]識別碼下發(fā)服務(wù)器驗證激活碼是否為真;若是，則驗證通過；
[0077] 其中，激活碼是通過以下步驟生成的：
[0078] 識別碼下發(fā)服務(wù)器向手機端發(fā)送激活鏈接；
[0079] 手機端觸發(fā)激活鏈接，以獲取激活碼。
[0080] 其中，手機端觸發(fā)激活鏈接可以理解為用戶通過按壓觸屏，或者其他指令下達方 式向手機端下達了打開激活鏈接的指令，之后手機端通過讀取激活鏈接，來自動生成了激 活碼，并且將該激活碼發(fā)送給了識別碼下發(fā)服務(wù)器。由于該過程完全是受到激活鏈接的控 制，而且激活鏈接是有識別碼下發(fā)服務(wù)器所下達的，因此，保證了識別碼獲取的安全性，進 而保證了后續(xù)步驟中獲取識別碼和進行單點登錄的安全性。
[0081] 另一種方式是手機端已經(jīng)進行了注冊，則不再需要通過激活碼來獲取識別碼，此 時手機端再想識別碼下發(fā)服務(wù)器發(fā)送請求的時候，需要將該描述設(shè)備和用戶的信息一同發(fā) 送給識別碼下發(fā)服務(wù)器，以換取識別碼。具體而言，若獲取識別碼請求中攜帶有主賬戶用戶 名、驗證密碼和設(shè)備編號，則識別碼下發(fā)服務(wù)器對獲取識別碼請求進行驗證包括：
[0082]識別碼下發(fā)服務(wù)器分別對主賬戶用戶名、驗證密碼和設(shè)備編號進行驗證;若主賬 戶用戶名、驗證密碼和設(shè)備編號均為真，則驗證通過。
[0083]其中，主賬戶用戶名是和驗證密碼是存儲在手機端中的，與相關(guān)技術(shù)匯總相類似 的，這兩個信息容易發(fā)生泄密。而設(shè)備編號是跟隨著硬件設(shè)備的生產(chǎn)一同生成的，無法進行 修改，因此通過設(shè)備編號，便能夠保證獲取識別碼的安全性(使用其他設(shè)備發(fā)送獲取識別碼 請求時，由于設(shè)備編號不同，是無法通過識別碼下發(fā)服務(wù)器所進行的驗證的）。
[0084]為了進一步提高安全性，還可以是令牌頒發(fā)服務(wù)器先對手機端進行查驗，只有查 驗通過了才會將識別碼交給識別碼下發(fā)服務(wù)器進行驗證，具體的，在步驟S105，令牌頒發(fā)服 務(wù)器向識別碼下發(fā)服務(wù)器發(fā)送獲取主令牌請求中的識別碼之前，還包括：
[0085]令牌頒發(fā)服務(wù)器根據(jù)獲取主令牌請求中的APPKey和APPSecret，驗證手機端是否 已經(jīng)在令牌頒發(fā)服務(wù)器中的注冊表中注冊過，若注冊過，則執(zhí)行步驟令牌頒發(fā)服務(wù)器向識 別碼下發(fā)服務(wù)器發(fā)送獲取主令牌請求中的識別碼。
[0086] 具體而言，令牌頒發(fā)服務(wù)器會在其存儲區(qū)的注冊表中查找是否存在接收到的 APPKey和APPSecret，如果二者均存在，則說明該手機端進行過注冊（該注冊的預(yù)先完成 的），才可以執(zhí)行步驟S105。
[0087] 下面提供兩個實例來說明本申請所提供的單點登錄技術(shù)中的主令牌獲取方法：
[0088] 首先對實例1-4中所設(shè)計的符號進行說明，具體如下表1所示，
[0089] 表1

[0092]實例1，當(dāng)手機端未在識別碼下發(fā)服務(wù)器中進行注冊的情況下，需要通過如下步驟 獲取主令牌，參見圖3的步驟1-7:
[0093]①用戶通過操作手機端，點擊收到激活郵件中的激活鏈接，Client(即手機端的認 證請求模塊）向Server (識別碼下發(fā)服務(wù)器)發(fā)起Http請求，該請求中包括:username (用戶 名）、DeviCe ID(設(shè)備編號）、pinc〇de(激活碼），請求綁定設(shè)備；其中，用戶名可以是用戶自 己定義的名稱，激活碼是通過觸發(fā)激活鏈接后得到的，設(shè)備編號是手機端出廠時便確認的 號碼，用以區(qū)分不同的手機；
[0094] ②Server收到請求后，驗證激活碼（由于此激活碼就是Server自己通過激活鏈接 發(fā)送的，所以Server可以驗證激活碼是否正確），如果激活碼正確，貝ijServer向Client發(fā)送 secret數(shù)據(jù)，secret數(shù)據(jù)中包括:Host Id (Server中某個用戶的唯一標(biāo)識，即識別碼），IDS (令牌頒發(fā)服務(wù)器）的URL(鏈接地址），用于手機端訪問令牌頒發(fā)服務(wù)器使用，并注銷激活 碼，確保激活碼只能使用一次，以提高安全性；
[0095]③Client收到secret數(shù)據(jù)后，向TA(即手機端的令牌轉(zhuǎn)發(fā)模塊)發(fā)送Http請求，該 請求中攜帶Device ID，APPKey，APPSecret和secret數(shù)據(jù)，請求頒發(fā)PT;
[0096] ④由于secret數(shù)據(jù)是Server端發(fā)送的，只有Server自己可以驗證secret數(shù)據(jù)的真 偽，TA無法判斷secret是否正確，所以TA收到后將請求轉(zhuǎn)發(fā)給IDS，此處只是轉(zhuǎn)發(fā)，無其它附 加操作；
[0097] ⑤由于secret數(shù)據(jù)是Server端發(fā)送的，只有Server自己可以驗證secret數(shù)據(jù)的真 偽，IDS也無法判斷secret數(shù)據(jù)是否正確，所以IDS收到請求后，先通過查找IDS中TA的注冊 表中是否存在要校驗的六??1(^，4??56(^的，驗證了4是否在105注冊過，注冊過105才會提供 服務(wù)；如果通過驗證，IDS提取secret數(shù)據(jù)中的識別碼，并將該識別碼通過http請求發(fā)送給 Server；
[0098] ⑥Server收到請求后，驗證識別碼，并根據(jù)驗證結(jié)果返回相應(yīng)的數(shù)據(jù);如果驗證通 過，則返回username(主帳戶用戶名）給IDS;如果驗證失敗，返回錯誤碼；
[0099] ⑦IDS收到通知后，根據(jù)返回結(jié)果決定頒發(fā)token還是返回拒絕；如果IDS收到 username(主帳戶用戶名），則向TA頒發(fā)PT(Primary Token)，TA接收到PT后，將其存儲起來， 用戶之后可以繼續(xù)使用這個私有令牌進行訪問，至此獲取PT過程完成；如果IDS收到錯誤 碼，則通知TA獲取PT失敗。
[0100] 實例2,當(dāng)手機端已經(jīng)在識別碼下發(fā)服務(wù)器中進行注冊的情況下，需要通過如下步 驟獲取主令牌，同樣可以參考圖3的步驟1-7(以下步驟中的名詞解釋可以參考實例1):
[0101 ] ①用戶在Client端（即手機端的認證請求模塊）向Server發(fā)送Http請求，請求中包 括:username(主帳戶用戶名）、password(密碼），Device ID(設(shè)備編號），請求secret數(shù)據(jù)； [0102] ②Server收到請求后，驗證username(主帳戶用戶名）、password(密碼），Device ID(設(shè)備編號），如果三者全部正確，Server向Client發(fā)送secret數(shù)據(jù)；
[0103]③Client收到secret數(shù)據(jù)后，向TA(即手機端的令牌轉(zhuǎn)發(fā)模塊)發(fā)送Http請求，請 求中包括:secret數(shù)據(jù)，Device ID，請求TA頒發(fā)PT;
[0104] ④由于secret數(shù)據(jù)是Server端發(fā)送的，只有Server自己可以驗證secret數(shù)據(jù)的真 偽，TA無法判斷secret是否正確，所以TA收到后將請求轉(zhuǎn)發(fā)給IDS，此處只是轉(zhuǎn)發(fā)，無其它附 加操作；
[0105] ⑤由于secret數(shù)據(jù)是Server端發(fā)送的，只有Server自己可以驗證secret數(shù)據(jù)的真 偽，IDS也無法判斷secret數(shù)據(jù)是否正確，所以將以上secret數(shù)據(jù)中的識別碼包裝成JS0N格 式后，轉(zhuǎn)發(fā)給Server;
[01 06] ⑥Server收到識別碼后，驗證secret數(shù)據(jù)中的識別碼，將驗證結(jié)果通知IDS;
[0107]⑦IDS收到通知后，根據(jù)結(jié)果決定頒發(fā)token還是返回拒絕，如果成功向TA頒發(fā)PT (Primary Token)，TA接收到PT后，將其存儲在安全的應(yīng)用空間中，用戶之后可以繼續(xù)使用 這個私有令牌進行訪問，至此獲取PT過程完成;如果失敗，通知TA獲取PT失敗。
[0108]獲取主令牌的目的是進行單點登錄，下面本發(fā)明還提供了基于上述單點登錄技術(shù) 中的主令牌獲取方法的單點登錄方法，除了包括步驟S101-S108,還包括如下步驟，如圖4所 示：
[0109] S201，手機端的接口調(diào)用模塊在獲取到登錄指令后，向令牌轉(zhuǎn)發(fā)模塊發(fā)送登錄指 令所對應(yīng)的子賬戶用戶名和子應(yīng)用標(biāo)識；
[0110] S202,令牌轉(zhuǎn)發(fā)模塊向令牌頒發(fā)服務(wù)器發(fā)送獲取子令牌請求，獲取子令牌請求中 攜帶有子賬戶用戶名、子應(yīng)用標(biāo)識和主令牌； S203,令牌頒發(fā)服務(wù)器根據(jù)子應(yīng)用標(biāo)識驗證手機端是否已經(jīng)在令牌頒發(fā)服務(wù)器中 注冊過；
[0112] S204,若是，則令牌頒發(fā)服務(wù)器根據(jù)子應(yīng)用標(biāo)識，將子賬戶用戶名和主令牌發(fā)送至 相應(yīng)的驗證服務(wù)器；
[0113] S205,驗證服務(wù)器驗證子賬戶用戶名和主令牌是否符合預(yù)設(shè)要求;若是，則驗證服 務(wù)器將子賬戶用戶名所對應(yīng)的子令牌發(fā)送至令牌頒發(fā)服務(wù)器；
[0114] S206，令牌頒發(fā)服務(wù)器將子令牌發(fā)送至令牌轉(zhuǎn)發(fā)模塊；
[0115] S207,令牌轉(zhuǎn)發(fā)模塊將子令牌發(fā)送至手機端的應(yīng)用模塊；
[0116] S208,應(yīng)用模塊向應(yīng)用服務(wù)器發(fā)起登錄請求，登錄請求中攜帶有子令牌；
[0117] S209，應(yīng)用服務(wù)器驗證子令牌是否為真，或是，則登錄請求通過。
[0118] 其中，登錄指令是由用戶通過按壓手機端的觸摸屏或者其他指令下達方式傳達給 手機的。
[0119]優(yōu)選的，步驟S205中，驗證服務(wù)器驗證子賬戶用戶名和主令牌是否符合預(yù)設(shè)要求 可以按照如下方式執(zhí)行：
[0120]驗證服務(wù)器驗證子賬戶用戶名和主令牌所對應(yīng)的主賬戶用戶名是否已經(jīng)授權(quán)關(guān) 聯(lián)。如果已經(jīng)授權(quán)關(guān)聯(lián)，則說明驗證服務(wù)器可以將子賬戶用戶名所對應(yīng)的子令牌發(fā)送至令 牌頒發(fā)服務(wù)器。
[0121] 本申請所提供的登錄方法，在執(zhí)行過程中會有兩種情況，是按照協(xié)議的不同，需要 由不同的驗證服務(wù)器來驗證子賬戶用戶名和主令牌是否能夠?qū)?yīng)上。因此，為了將子賬戶 用戶名和主令牌發(fā)送到對應(yīng)的服務(wù)器進行驗證，則需要首選確定協(xié)議所對應(yīng)的認證方式， 再按照認證方式所對應(yīng)的記錄，將這兩個信息發(fā)送到對應(yīng)的驗證服務(wù)器中。具體的，步驟 S205中，令牌頒發(fā)服務(wù)器根據(jù)子應(yīng)用標(biāo)識，將子賬戶用戶名和主令牌發(fā)送至相應(yīng)的驗證服 務(wù)器包括如下步驟：
[0122] 令牌頒發(fā)服務(wù)器查找子應(yīng)用標(biāo)識查找對應(yīng)的認證方式；
[0123] 令牌頒發(fā)服務(wù)器將子賬戶用戶名和主令牌發(fā)送至認證方式所對應(yīng)的驗證服務(wù)器。
[0124] 優(yōu)選的，還可以根據(jù)使用的場景來調(diào)整步驟S209中的驗證子令牌的步驟，以使整 體步驟更為安全，具體的，應(yīng)用服務(wù)器驗證子令牌是否為真的步驟可以由如下步驟組合而 成：
[0125] 應(yīng)用服務(wù)器將子令牌轉(zhuǎn)發(fā)至驗證服務(wù)器；
[0126] 驗證服務(wù)器驗證子令牌是否已經(jīng)注冊，若是，則向應(yīng)用服務(wù)器返回驗證通過信息；
[0127] 若應(yīng)用服務(wù)器接收到驗證通過信息，則驗證子令牌為真。
[0128] 上述步驟S201-S209中，驗證服務(wù)器有兩種存在形式，分別是和令牌頒發(fā)服務(wù)器位 于同一個物理服務(wù)器中的形式，和驗證服務(wù)器與令牌頒發(fā)服務(wù)器位于不同的物理服務(wù)器中 的形式。
[0129] 下面給出兩個具體的實例還說明本申請所提供的單點登錄方法，以下兩種實例均 有共同的前提條件，即假設(shè)用戶綁定設(shè)備(手機端)并獲取PT后（已登錄主應(yīng)用），在后續(xù)的 使用中，沒有進行SL0(單點退出），然后繼續(xù)進行SS0的過程。這兩個實例要求先在TA上已經(jīng) 有相應(yīng)的PT。如果要實現(xiàn)單點登錄，首先要在IDS中，將RP APP的子用戶名username與 Client的主用戶名username進行帳戶授權(quán)關(guān)聯(lián)，并將對應(yīng)關(guān)系表存儲在IDS中，后續(xù)單點登 錄時用來決定是否可以進行授權(quán)認證。具體實例如下，請參照圖3所示：
[0130] 實例3,該種情況是針對AS無權(quán)限進行認證，需要外部服務(wù)KDC進行認證，圖3中R1 ~R10,其中R8和R9為可選項。該過程是針對IDS需要使用外置的KDC來輔助發(fā)放應(yīng)用的ST， 主要針對的協(xié)議如Kerberos等協(xié)議。
[0131] R1，TA發(fā)起和APP發(fā)起的區(qū)別在于這一步有還是沒有，有的話，用戶點擊RP APP準(zhǔn) 備登錄時，SDK(即手機端的接口調(diào)用模塊）向TA發(fā)起SS0請求，請求中包括:RP username (子 帳戶用戶名）和FacetID(子應(yīng)用RP APP的唯一標(biāo)識，即子應(yīng)用標(biāo)識），請求TA頒發(fā)允許訪問 RP Server的ST(Secondary Token)；
[0132] R2，TA收到請求后，攜帶其存儲的PT，向IDS發(fā)起Http請求，請求頒發(fā)允許訪問RP Server的ST(Secondary Token)，請求中包括:PT，RP username(子帳戶用戶名），F(xiàn)acetID (子應(yīng)用RP APP的唯一標(biāo)識）；
[0133] R3，IDS收到請求后，會首先驗證FacetID所代表的RP APP是否在IDS注冊，通過查 找IDS中RP APP的注冊表是否存在要校驗的FacetID，如果有，則代表FacetID合法;驗證通 過后，IDS會根據(jù)FacetID找到對應(yīng)RP Server配置的認證方式，確定是否將數(shù)據(jù)提交給AS處 理就可以，還是需要到KDC(密匙分配中心，即驗證服務(wù)器)進行認證;比如Kerberos協(xié)議，其 配置的認證方式，需要將RP username(子帳戶用戶名），SPN(加密虛擬網(wǎng)絡(luò))提交給KDC;
[0134] R4，KDC處理提交的請求：認證子帳戶用戶身份及訪問權(quán)限，允許訪問時，將ST (Secondary Token)返回給IDS;
[0135] R5, IDS收到ST后，發(fā)送給TA;
[0136] R6，TA將ST轉(zhuǎn)發(fā)給TA SDK并通過RP SDK接口回傳給RP APP;
[0137] R7，RP APP(即手機端的應(yīng)用模塊)收到ST后，攜帶ST向RP Server發(fā)起http請求， 請求訪問資源，RP Server(應(yīng)用服務(wù)器)根據(jù)需要（即自身可以校驗ST)，校驗ST正確與否；
[0138] R8,（可選項)或者RP Server根據(jù)需要（即自身不可以校驗ST)，將收到的請求轉(zhuǎn)發(fā) 給KDC校驗，校驗ST是否有訪問權(quán)限；
[0139] R9，（可選項）在R8執(zhí)行的情況下，則KDC驗證ST，如果校驗通過，通知RP Server允 許訪問；如果校驗失敗，將失敗的結(jié)果返回到RP Server;
[0140] R10，RP Server根據(jù)返回的結(jié)果，提示RP APP訪問成功或失??；如果成功，允許RP APP訪問并提供相應(yīng)資源，至此用戶完成單點登錄。
[0141] 實例4，該種情況是針對AS有權(quán)限進行認證，內(nèi)部認證，圖5中R1-R10，其中R8和R9 為可選項。該過程是針對IDS本身內(nèi)置的AS就可以直接發(fā)放應(yīng)用的ST，主要針對的協(xié)議如 0Auth，0IDC 等。
[0142] R1，用戶點擊RP APP準(zhǔn)備登錄時，SDK(即手機端的認證請求模塊）向TA發(fā)起SS0請 求，請求中包括:RP username(子帳戶用戶名）和FacetID(子應(yīng)用RP APP的唯一標(biāo)識，即）， 請求TA頒發(fā)允許訪問RP Server的ST(Secondary Token);
[0143] R2，TA收到請求后，攜帶其存儲的PT，向IDS發(fā)起Http請求，請求頒發(fā)允許訪問RP Server的ST(Secondary Token)，請求中包括:PT，RP username(子帳戶用戶名），F(xiàn)acetID (子應(yīng)用RP APP的唯一標(biāo)識）；
[0144] R3，IDS收到請求后，會首先驗證FacetID所代表的RP APP是否在IDS注冊，通過查 找IDS中RP APP的注冊表是否存在要校驗的FacetID，如果有，則代表FacetID合法;驗證通 過后，IDS會根據(jù)FacetID找到對應(yīng)RP Server配置的認證方式，確定是否將數(shù)據(jù)提交給KDC (密匙分配中心)進行認證;如果是0Auth，BasiC，0IDC等協(xié)議，其配置的認證方式，需要將數(shù) 據(jù)提交給IDS Server內(nèi)置的AS(驗證服務(wù)器)進行認證；
[0145] R4，AS進行認證處理：因為AS內(nèi)置于IDS，所以可以查詢RP APP的子帳戶Username 是否與IDS中的主帳戶Username授權(quán)關(guān)聯(lián)，如果未關(guān)聯(lián)，則返回響應(yīng)錯誤碼;如果已關(guān)聯(lián)，則 認證子帳戶用戶身份及訪問權(quán)限，根據(jù)該應(yīng)用注冊的額外限制，如AppKey(也就是OAuth Client ID)，將ST(Secondary Token)返回給IDS;
[0146] R5, IDS收到ST后，返回給TA;
[0147] R6，TA將ST轉(zhuǎn)送給SDK并通過接口回傳給RP APP;
[0148] R7，RP APP(即手機端的應(yīng)用模塊)攜帶ST向RP Server發(fā)起http請求，請求訪問資 源，RP Server根據(jù)認證協(xié)議的需要（比如Bas ic協(xié)議下的ST，RP可以自己解析），判斷ST正確 與否；
[0149] R8,（可選項）或者RP Server根據(jù)認證協(xié)議的需要（比如0Auth，0IDC等協(xié)議下的 ST，RP不能自己解析），將收到的請求轉(zhuǎn)發(fā)給AS校驗，校驗ST是否有訪問權(quán)限；
[0150] R9，（可選項）如果步驟R8執(zhí)行的情況下，則AS驗證ST，校驗通過，返回RP APP的 Username，并通知RP Server允許訪問；校驗失敗，將失敗的結(jié)果返回到RP Server;
[0151] R10，RP Server根據(jù)返回的結(jié)果，提示RP APP訪問成功或失??；如果成功，允許RP APP訪問并提供相應(yīng)資源，至此用戶完成單點登錄。
[0152] 本發(fā)明實施例還提供了與上述登錄方法相適應(yīng)的單點退出流程，如圖6所示，包括 如下流程：
[0153] R1，用戶點擊Client或某個RP APP(如ST1)退出登錄，TA或SDK發(fā)起SL0(單點退出） 請求(一個廣播，所有集成了 TA或SDK的應(yīng)用都能收到這個廣播）；
[0154] R2，TA將請求提交給IDS，請求清除IDS中的PT;
[0155] R3，IDS驗證請求內(nèi)容，如果驗證成功，則清除PT，IDS清除PT后，向TA發(fā)送SL0請求 回復(fù)，通知TA清除各應(yīng)用本地ST;
[0156] R4，TA將按照本地存儲的ST列表順序(如ST1，ST2，ST3...)通知各個SDK，依次清除 各應(yīng)用本地ST;
[0157] R5，TA清除完最后一個ST后，通過接口回傳給RP APP，跳轉(zhuǎn)到登錄頁面，至此單點 退出流程完成。
[0158] 其中：Secret在Client上并不保留，所以TA沒有單獨通知Client去清除。
[0159]整體來看本申請所提供的登錄方法，有如下幾點需要說明：
[0160]第一點，本申請所提供的方法和標(biāo)準(zhǔn)NAPPS方法在流程上的區(qū)別及如何保障安全 性
[0161] 前提條件：
[0162] 客戶端與服務(wù)端的傳輸已加密，端對端的傳輸過程認為是安全的。
[0163] 1，標(biāo)準(zhǔn)結(jié)構(gòu)分析：
[0164] 標(biāo)準(zhǔn)NAPPS流程只定義了流程，至于每一步攜帶哪些數(shù)據(jù)，并未做具體規(guī)范。
[0165] 標(biāo)準(zhǔn)NAPPS流程中，用戶訪問應(yīng)用時，有時在客戶端(Token Agent)使用內(nèi)置的瀏 覽器內(nèi)輸入用戶名密碼，提交給服務(wù)器(AS)驗證，由于用戶在身份認證時使用了第三方的 應(yīng)用(瀏覽器），所以信息的傳輸過程中過程被認為是不安全的，故添加 code作為驗證信息， 確保傳輸過程的安全性，只有每步的驗證全部通過，才可以通過用戶名密碼換取AT(訪問應(yīng) 用的令牌）。
[0166] 2,本申請所提供的方法的分析：
[0167] 與標(biāo)準(zhǔn)結(jié)構(gòu)相比，本申請?zhí)峁┑慕鉀Q方案多了硬件設(shè)備注冊的過程，即"步驟 S102"。這樣即使有了帳戶和密碼，也只允許注冊過的信任設(shè)備進行訪問來獲取PT，相比原 來流程更加安全。
[0168] 本申請所提供的方案，主要針對的是移動端，客戶端應(yīng)用直接集成在TA(不通過瀏 覽器），用戶登錄時進行身份認證的過程，是應(yīng)用APP端直接與服務(wù)器端的信息直接通過 HTTP Client交互，這個過程通過HTTPS，并且不涉及第三方(共享通道），所以傳輸過程是安 全的，故不需要code來做驗證，直接就可以換取PT(AT)。
[0169] 3,結(jié)論：
[0170]與標(biāo)準(zhǔn)NAPPS比起來，本申請所提供的方法增加了硬件設(shè)備注冊流程，只允許受信 任設(shè)備訪問其應(yīng)用下對應(yīng)的資源服務(wù)器，并且將客戶端應(yīng)用登錄直接集成在TA，不經(jīng)過瀏 覽器，在不降低安全性的前提下，用戶使用起來更便捷，用戶體驗更好。
[0171] 二，為什么本申請所提供的方案能讓其他企業(yè)快速集成？
[0172] 1，標(biāo)準(zhǔn)結(jié)構(gòu)分析：
[0173] 標(biāo)準(zhǔn)結(jié)構(gòu)由三部分組成:客戶端(App)、服務(wù)器端(RS)、令牌代理(TA)、認證服務(wù)器 端(AS)。其中客戶端、服務(wù)器端均需要相應(yīng)的NAPPS協(xié)議實現(xiàn)代碼。
[0174] 因此企業(yè)如果想集成NAPPS功能，必須實現(xiàn)客戶端、服務(wù)器端的NAPPS協(xié)議。這樣就 使得開發(fā)成本和周期就經(jīng)較高。
[0175] 本申請所提供的解決方案分析：
[0176]與標(biāo)準(zhǔn)結(jié)構(gòu)相比，本申請的解決方案多了RP App(認證主應(yīng)用客戶端），及相應(yīng)RP Server，SDK(RP App客戶端軟件開發(fā)包及RP Server對應(yīng)的服務(wù)端軟件開發(fā)包），IDS(認證 服務(wù)端），KDC(密鑰分發(fā)中心）。此種解決方案以提供服務(wù)端的SDK、A卯端的I0S及Android SDK的方式提供服務(wù)，這樣很多代碼都是封裝過的，配合SDK文檔和樣本程序，開發(fā)者集成 NAPPS功能非常方便，提高了第三方RP應(yīng)用服務(wù)使用NAPPS協(xié)議的效率。
[0177] 同時，增加 RP APP CLIENT及相應(yīng)RP Server的目的是：IDS本身可以使用第三方的 認證機制，便于和已有的帳戶和認證的統(tǒng)一；
[0178] 增加 SDK的目的是:將復(fù)雜的服務(wù)器連接/請求等封裝，應(yīng)用只需調(diào)用接口，而不用 關(guān)心其實現(xiàn)過程；
[0179]增加 IDS的目的是:控制各RP集成的權(quán)限，不能讓未授權(quán)的RP集成，同時集中管理 各個RP應(yīng)用需要的訪問令牌ST;
[0180] 增加 KDC的目的是:有些令牌如Kerberos等，IDS并沒有能力去發(fā)布和管理ST，這樣 需要一個管理員帳戶去換取各個用戶的子ST，起到免密碼登錄的效果。
[0181] 3,結(jié)論：
[0182] 與標(biāo)準(zhǔn)結(jié)構(gòu)比起來，本公司此種解決方案以"統(tǒng)一認證，單點登錄"的思想，保證各 RP重用一個TA SDK實現(xiàn)。因此能顯著降低RP開發(fā)成本，并且讓RP快速集成。
[0183] 三，為什么本申請的方案在不降低安全性的同時，讓NAPPS實現(xiàn)多種認證協(xié)議
[0184] 1，標(biāo)準(zhǔn) NAPPS 分析：
[0185] NAPPS的規(guī)范是世界上頂級的移動安全人員在一起實現(xiàn)的。盡管NAPPS只定義了 0IDC-種規(guī)范的實現(xiàn)，仍可以保證流程是安全的。
[0186] 2,本申請的解決方案分析：
[0187] 與標(biāo)準(zhǔn)NAPPS相比，本申請的解決方案在支持0IDC的基礎(chǔ)上，擴展了對第三方設(shè)備 管理和統(tǒng)一認證的實現(xiàn);擴展了對除0IDC外其它認證協(xié)議如SAML，Kerberos，CAS等的實現(xiàn)。 因為使用了一樣的流程，只是傳遞的ID_token(0IDC令牌），變成了其它的各種協(xié)議對應(yīng) token，整個流程更嚴格了，所以可以認為這個過程也是足夠安全的。
[0188] 3,結(jié)論：
[0189] 與標(biāo)準(zhǔn)NAPPS比起來，本申請的解決方案以"統(tǒng)一認證，單點登錄"的思想，解決了 多個移動應(yīng)用的單點登錄問題。與標(biāo)準(zhǔn)NAPPS相比，本申請的解決方案在支持0IDC的基礎(chǔ) 上，增加了Basic，OAuth，Kerberos，SMAL等協(xié)議的支持，同時提供相應(yīng)的RP APP客戶端和服 務(wù)端SDK及演示代碼。這樣大大方便開發(fā)者在移動端集成RP APP，提高了NAPPS的兼容性，并 且在保證安全的同時，提供了最佳的用戶體驗。
[0190] 本申請實施例還提供了與單點登錄技術(shù)中的主令牌獲取方法相對應(yīng)的單點登錄 技術(shù)中的主令牌獲取系統(tǒng)，包括：
[0191] 手機端的認證請求模塊，用于向識別碼下發(fā)服務(wù)器發(fā)出獲取識別碼請求；
[0192] 識別碼下發(fā)服務(wù)器，用于對所述獲取識別碼請求進行驗證，若驗證通過，則識別碼 下發(fā)服務(wù)器，進一步用于向所述認證請求模塊返回第一驗證通過信息，所述第一驗證通過 信息中攜帶有識別碼；
[0193] 所述認證請求模塊，還用于向所述手機端的令牌轉(zhuǎn)發(fā)模塊發(fā)送獲取主令牌請求， 所述獲取主令牌請求中攜帶有識別碼；
[0194] 所述令牌轉(zhuǎn)發(fā)模塊，用于將所述獲取主令牌請求向令牌頒發(fā)服務(wù)器轉(zhuǎn)發(fā)；
[0195] 令牌頒發(fā)服務(wù)器，用于向所述識別碼下發(fā)服務(wù)器發(fā)送所述獲取主令牌請求中的識 別碼；
[0196] 識別碼下發(fā)服務(wù)器，還用于驗證所述識別碼；
[0197] 若所述識別碼下發(fā)服務(wù)器驗證所述獲取主令牌請求中的識別碼為真，則識別碼下 發(fā)服務(wù)器，進一步用于向令牌頒發(fā)服務(wù)器發(fā)出第二驗證通過信息；
[0198] 令牌頒發(fā)服務(wù)器，還用于在接收到所述第二驗證通過信息后，向所述令牌轉(zhuǎn)發(fā)模 塊頒發(fā)用于進行單點登錄驗證的主令牌。
[0199] 本申請實施例還提供了與單點登錄方法相對應(yīng)的單點登錄系統(tǒng)，包括單點登錄技 術(shù)中的主令牌獲取系統(tǒng)，還包括：
[0200] 手機端的接口調(diào)用模塊，用于在獲取到登錄指令后，向所述令牌轉(zhuǎn)發(fā)模塊發(fā)送登 錄指令所對應(yīng)的子賬戶用戶名和子應(yīng)用標(biāo)識；
[0201 ]令牌轉(zhuǎn)發(fā)模塊，還用于向令牌頒發(fā)服務(wù)器發(fā)送獲取子令牌請求，所述獲取子令牌 請求中攜帶有所述子賬戶用戶名、所述子應(yīng)用標(biāo)識和所述主令牌；
[0202]令牌頒發(fā)服務(wù)器，還用于根據(jù)子應(yīng)用標(biāo)識驗證所述手機端是否已經(jīng)在令牌頒發(fā)服 務(wù)器中注冊過；
[0203]若是，則令牌頒發(fā)服務(wù)器，還用于根據(jù)子應(yīng)用標(biāo)識，將所述子賬戶用戶名和所述主 令牌發(fā)送至相應(yīng)的驗證服務(wù)器；
[0204]驗證服務(wù)器驗證，用于所述子賬戶用戶名和所述主令牌是否符合預(yù)設(shè)要求;若是， 則驗證服務(wù)器，進一步用于將所述子賬戶用戶名所對應(yīng)的子令牌發(fā)送至令牌頒發(fā)服務(wù)器；
[0205] 令牌頒發(fā)服務(wù)器，還用于將所述子令牌發(fā)送至所述令牌轉(zhuǎn)發(fā)模塊；
[0206] 所述令牌轉(zhuǎn)發(fā)模塊，還用于將所述子令牌發(fā)送至手機端的應(yīng)用模塊；
[0207] 所述應(yīng)用模塊，用于向所述應(yīng)用服務(wù)器發(fā)起登錄請求，所述登錄請求中攜帶有所 述子令牌；
[0208] 所述應(yīng)用服務(wù)器，用于驗證所述子令牌是否為真，或是，則所述登錄請求通過。 [0209]所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯 示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個 網(wǎng)絡(luò)單元上。可以根據(jù)實際的需要選擇其中的部分或者全部單元來實現(xiàn)本實施例方案的目 的。
[0210] 另外，在本發(fā)明各個實施例中的各功能單元可以集成在一個處理單元中，也可以 是各個單元單獨物理存在，也可以兩個或兩個以上單元集成在一個單元中。
[0211] 所述功能如果以軟件功能單元的形式實現(xiàn)并作為獨立的產(chǎn)品銷售或使用時，可以 存儲在一個計算機可讀取存儲介質(zhì)中。基于這樣的理解，本發(fā)明的技術(shù)方案本質(zhì)上或者說 對現(xiàn)有技術(shù)做出貢獻的部分或者該技術(shù)方案的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計 算機軟件產(chǎn)品存儲在一個存儲介質(zhì)中，包括若干指令用以使得一臺計算機設(shè)備(可以是個 人計算機，服務(wù)器，或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行本發(fā)明各個實施例所述方法的全部或部分步驟。 而前述的存儲介質(zhì)包括:U盤、移動硬盤、只讀存儲器(R0M，Read-0nly Memory)、隨機存取存 儲器(RAM，Random Access Memory)、磁碟或者光盤等各種可以存儲程序代碼的介質(zhì)。
[0212] 以上所述，僅為本發(fā)明的【具體實施方式】，但本發(fā)明的保護范圍并不局限于此，任何 熟悉本技術(shù)領(lǐng)域的技術(shù)人員在本發(fā)明揭露的技術(shù)范圍內(nèi)，可輕易想到變化或替換，都應(yīng)涵 蓋在本發(fā)明的保護范圍之內(nèi)。因此，本發(fā)明的保護范圍應(yīng)所述以權(quán)利要求的保護范圍為準(zhǔn)。
【主權(quán)項】
1. 單點登錄技術(shù)中的主令牌獲取方法，其特征在于，包括： 手機端的認證請求模塊向識別碼下發(fā)服務(wù)器發(fā)出獲取識別碼請求； 識別碼下發(fā)服務(wù)器對所述獲取識別碼請求進行驗證，若驗證通過，則識別碼下發(fā)服務(wù) 器向所述認證請求模塊返回第一驗證通過信息，所述第一驗證通過信息中攜帶有識別碼； 所述認證請求模塊向所述手機端的令牌轉(zhuǎn)發(fā)模塊發(fā)送獲取主令牌請求，所述獲取主令 牌請求中攜帶有識別碼； 所述令牌轉(zhuǎn)發(fā)模塊將所述獲取主令牌請求向令牌頒發(fā)服務(wù)器轉(zhuǎn)發(fā)； 令牌頒發(fā)服務(wù)器向所述識別碼下發(fā)服務(wù)器發(fā)送所述獲取主令牌請求中的識別碼； 識別碼下發(fā)服務(wù)器驗證所述識別碼； 若所述識別碼下發(fā)服務(wù)器驗證所述獲取主令牌請求中的識別碼為真，則識別碼下發(fā)服 務(wù)器向令牌頒發(fā)服務(wù)器發(fā)出第二驗證通過信息； 令牌頒發(fā)服務(wù)器在接收到所述第二驗證通過信息后，向所述令牌轉(zhuǎn)發(fā)模塊頒發(fā)用于進 行單點登錄驗證的主令牌。2. 根據(jù)權(quán)利要求1所述的方法，其特征在于，若所述獲取識別碼請求中攜帶有激活碼， 則所述識別碼下發(fā)服務(wù)器對所述獲取識別碼請求進行驗證包括： 所述識別碼下發(fā)服務(wù)器驗證激活碼是否為真;若是，則驗證通過； 其中，所述激活碼是通過以下步驟生成的： 所述識別碼下發(fā)服務(wù)器向所述手機端發(fā)送激活鏈接； 所述手機端觸發(fā)所述激活鏈接，以獲取所述激活碼。3. 根據(jù)權(quán)利要求1所述的方法，其特征在于，若所述獲取識別碼請求中攜帶有主賬戶用 戶名、驗證密碼和設(shè)備編號，則所述識別碼下發(fā)服務(wù)器對所述獲取識別碼請求進行驗證包 括： 所述識別碼下發(fā)服務(wù)器分別對所述主賬戶用戶名、驗證密碼和設(shè)備編號進行驗證;若 所述主賬戶用戶名、驗證密碼和設(shè)備編號均為真，則驗證通過。4. 根據(jù)權(quán)利要求1所述的方法，其特征在于，在步驟所述令牌頒發(fā)服務(wù)器向所述識別碼 下發(fā)服務(wù)器發(fā)送所述獲取主令牌請求中的識別碼之前，還包括： 所述令牌頒發(fā)服務(wù)器根據(jù)所述獲取主令牌請求中的APPKey和APPSecret，驗證所述手 機端是否已經(jīng)在令牌頒發(fā)服務(wù)器中的注冊表中注冊過，若注冊過，則執(zhí)行步驟所述令牌頒 發(fā)服務(wù)器向所述識別碼下發(fā)服務(wù)器發(fā)送所述獲取主令牌請求中的識別碼。5. 單點登錄技術(shù)中的主令牌獲取系統(tǒng)，其特征在于，包括： 手機端的認證請求模塊，用于向識別碼下發(fā)服務(wù)器發(fā)出獲取識別碼請求； 識別碼下發(fā)服務(wù)器，用于對所述獲取識別碼請求進行驗證，若驗證通過，則識別碼下發(fā) 服務(wù)器，進一步用于向所述認證請求模塊返回第一驗證通過信息，所述第一驗證通過信息 中攜帶有識別碼； 所述認證請求模塊，還用于向所述手機端的令牌轉(zhuǎn)發(fā)模塊發(fā)送獲取主令牌請求，所述 獲取主令牌請求中攜帶有識別碼； 所述令牌轉(zhuǎn)發(fā)模塊，用于將所述獲取主令牌請求向令牌頒發(fā)服務(wù)器轉(zhuǎn)發(fā)； 令牌頒發(fā)服務(wù)器，用于向所述識別碼下發(fā)服務(wù)器發(fā)送所述獲取主令牌請求中的識別 碼； 識別碼下發(fā)服務(wù)器，還用于驗證所述識別碼； 若所述識別碼下發(fā)服務(wù)器驗證所述獲取主令牌請求中的識別碼為真，則識別碼下發(fā)服 務(wù)器，進一步用于向令牌頒發(fā)服務(wù)器發(fā)出第二驗證通過信息； 令牌頒發(fā)服務(wù)器，還用于在接收到所述第二驗證通過信息后，向所述令牌轉(zhuǎn)發(fā)模塊頒 發(fā)用于進行單點登錄驗證的主令牌。6. 單點登錄方法，包括如權(quán)利要求1-5任一項所述的單點登錄技術(shù)中的主令牌獲取方 法，其特征在于，還包括： 手機端的接口調(diào)用模塊在獲取到登錄指令后，向所述令牌轉(zhuǎn)發(fā)模塊發(fā)送登錄指令所對 應(yīng)的子賬戶用戶名和子應(yīng)用標(biāo)識； 令牌轉(zhuǎn)發(fā)模塊向令牌頒發(fā)服務(wù)器發(fā)送獲取子令牌請求，所述獲取子令牌請求中攜帶有 所述子賬戶用戶名、所述子應(yīng)用標(biāo)識和所述主令牌； 令牌頒發(fā)服務(wù)器根據(jù)子應(yīng)用標(biāo)識驗證所述手機端是否已經(jīng)在令牌頒發(fā)服務(wù)器中注冊 過； 若是，則令牌頒發(fā)服務(wù)器根據(jù)子應(yīng)用標(biāo)識，將所述子賬戶用戶名和所述主令牌發(fā)送至 相應(yīng)的驗證服務(wù)器； 驗證服務(wù)器驗證所述子賬戶用戶名和所述主令牌是否符合預(yù)設(shè)要求;若是，則驗證服 務(wù)器將所述子賬戶用戶名所對應(yīng)的子令牌發(fā)送至令牌頒發(fā)服務(wù)器； 令牌頒發(fā)服務(wù)器將所述子令牌發(fā)送至所述令牌轉(zhuǎn)發(fā)模塊； 所述令牌轉(zhuǎn)發(fā)模塊將所述子令牌發(fā)送至手機端的應(yīng)用模塊； 所述應(yīng)用模塊向所述應(yīng)用服務(wù)器發(fā)起登錄請求，所述登錄請求中攜帶有所述子令牌； 所述應(yīng)用服務(wù)器驗證所述子令牌是否為真，或是，則所述登錄請求通過。7. 根據(jù)權(quán)利要求6所述的方法，其特征在于，所述驗證服務(wù)器驗證所述子賬戶用戶名和 所述主令牌是否符合預(yù)設(shè)要求包括： 所述驗證服務(wù)器驗證所述子賬戶用戶名和所述主令牌所對應(yīng)的主賬戶用戶名是否已 經(jīng)授權(quán)關(guān)聯(lián)。8. 根據(jù)權(quán)利要求7所述的方法，其特征在于，所述令牌頒發(fā)服務(wù)器根據(jù)子應(yīng)用標(biāo)識，將 所述子賬戶用戶名和所述主令牌發(fā)送至相應(yīng)的驗證服務(wù)器包括： 所述令牌頒發(fā)服務(wù)器查找所述子應(yīng)用標(biāo)識查找對應(yīng)的認證方式； 所述令牌頒發(fā)服務(wù)器將所述子賬戶用戶名和所述主令牌發(fā)送至認證方式所對應(yīng)的驗 證服務(wù)器。9. 根據(jù)權(quán)利要求6所述的方法，其特征在于，所述應(yīng)用服務(wù)器驗證所述子令牌是否為真 包括： 應(yīng)用服務(wù)器將所述子令牌轉(zhuǎn)發(fā)至所述驗證服務(wù)器； 所述驗證服務(wù)器驗證所述子令牌是否已經(jīng)注冊，若是，則向所述應(yīng)用服務(wù)器返回驗證 通過信息； 若所述應(yīng)用服務(wù)器接收到所述驗證通過信息，則驗證所述子令牌為真。10. 單點登錄系統(tǒng)，包括如權(quán)利要求6所述的單點登錄技術(shù)中的主令牌獲取系統(tǒng)，其特 征在于，還包括： 手機端的接口調(diào)用模塊，用于在獲取到登錄指令后，向所述令牌轉(zhuǎn)發(fā)模塊發(fā)送登錄指 令所對應(yīng)的子賬戶用戶名和子應(yīng)用標(biāo)識； 令牌轉(zhuǎn)發(fā)模塊，還用于向令牌頒發(fā)服務(wù)器發(fā)送獲取子令牌請求，所述獲取子令牌請求 中攜帶有所述子賬戶用戶名、所述子應(yīng)用標(biāo)識和所述主令牌； 令牌頒發(fā)服務(wù)器，還用于根據(jù)子應(yīng)用標(biāo)識驗證所述手機端是否已經(jīng)在令牌頒發(fā)服務(wù)器 中注冊過； 若是，則令牌頒發(fā)服務(wù)器，還用于根據(jù)子應(yīng)用標(biāo)識，將所述子賬戶用戶名和所述主令牌 發(fā)送至相應(yīng)的驗證服務(wù)器； 驗證服務(wù)器驗證，用于所述子賬戶用戶名和所述主令牌是否符合預(yù)設(shè)要求;若是，則驗 證服務(wù)器，進一步用于將所述子賬戶用戶名所對應(yīng)的子令牌發(fā)送至令牌頒發(fā)服務(wù)器； 令牌頒發(fā)服務(wù)器，還用于將所述子令牌發(fā)送至所述令牌轉(zhuǎn)發(fā)模塊； 所述令牌轉(zhuǎn)發(fā)模塊，還用于將所述子令牌發(fā)送至手機端的應(yīng)用模塊； 所述應(yīng)用模塊，用于向所述應(yīng)用服務(wù)器發(fā)起登錄請求，所述登錄請求中攜帶有所述子 令牌； 所述應(yīng)用服務(wù)器，用于驗證所述子令牌是否為真，或是，則所述登錄請求通過。
【文檔編號】H04L29/06GK105959267SQ201610261327
【公開日】2016年9月21日
【申請日】2016年4月25日
【發(fā)明人】尚春明, 熊巧玲, 李勝釗
【申請人】北京九州云騰科技有限公司