麻豆精品无码国产在线播放,国产亚洲精品成人AA片新蒲金,国模无码大尺度一区二区三区,神马免费午夜福利剧场

一種平臺授權(quán)方法、平臺服務(wù)端及應(yīng)用客戶端和系統(tǒng)的制作方法

文檔序號:7810028閱讀:155來源:國知局
一種平臺授權(quán)方法、平臺服務(wù)端及應(yīng)用客戶端和系統(tǒng)的制作方法
【專利摘要】本發(fā)明實施例公開了一種平臺授權(quán)方法、平臺服務(wù)端及應(yīng)用客戶端和系統(tǒng),該方法包括:平臺服務(wù)端接收應(yīng)用客戶端通過第一路徑發(fā)送的第一驗證消息并獲取所述應(yīng)用客戶端的客戶端標識;所述平臺服務(wù)端對所接收的第一驗證消息與所述客戶端標識之間的映射關(guān)系進行記錄;所述平臺服務(wù)端接收所述應(yīng)用客戶端通過第二路徑發(fā)送的第二驗證消息;如果所述平臺服務(wù)端驗證所述第一驗證消息和第二驗證消息匹配,則根據(jù)所述第一驗證消息從所記錄的所述映射關(guān)系中提取所述客戶端標識,并根據(jù)所述客戶端標識生成授權(quán)訪問令牌,發(fā)送給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端。本發(fā)明實施例的技術(shù)方案能使得用戶對授權(quán)過程無感知,并能進一步提高授權(quán)的安全性。
【專利說明】一種平臺授權(quán)方法、平臺服務(wù)----?及應(yīng)用客戶----?和系統(tǒng)

【技術(shù)領(lǐng)域】
[0001] 本發(fā)明涉及計算機通信【技術(shù)領(lǐng)域】,尤其涉及一種平臺授權(quán)方法、平臺服務(wù)端及應(yīng) 用客戶端和系統(tǒng)。

【背景技術(shù)】
[0002] 開放平臺是指由網(wǎng)站提供的、面向第三方的開放式基礎(chǔ)服務(wù)平臺,例如百度、騰 訊、阿里、新浪微博等開放云平臺。第三方的應(yīng)用客戶端為了獲得這些開放平臺提供的各種 高價值的云能力和用戶數(shù)據(jù),都會去支持各大平臺所提供的開放授權(quán)接口,以獲取用戶在 這些平臺上給本應(yīng)用客戶端授權(quán)后產(chǎn)生的授權(quán)訪問令牌,并通過訪問令牌調(diào)用各大平臺提 供的 OpenAPI (Open Application Programming Interface,開放應(yīng)用程序接口)來獲取本 應(yīng)用客戶端需要的云能力和用戶在對應(yīng)開放平臺上的相關(guān)數(shù)據(jù)。
[0003] 現(xiàn)有技術(shù)中,用戶給應(yīng)用客戶端授權(quán)前需要先基于用戶的已有賬戶登錄該平臺, 否則平臺無法知道是哪個用戶要為對應(yīng)的應(yīng)用客戶端授權(quán),而為了保證安全,一般都需要 應(yīng)用客戶端提供網(wǎng)絡(luò)視圖(WebView)或外部瀏覽器來加載對應(yīng)平臺所提供的登錄授權(quán)頁 面,用戶在該登錄授權(quán)頁面進行登錄授權(quán),以便應(yīng)用客戶端不能直接接觸到用戶的賬號、密 碼等敏感信息。但這樣的流程體驗在很多時候是很不友好的:
[0004] 第一、由于授權(quán)時需要加載一個web頁(網(wǎng)頁),而web頁的加載速度取決于用戶 移動設(shè)備的網(wǎng)絡(luò)速度,在大多數(shù)2G環(huán)境下,這個頁面的加載速度是極慢的,用戶需要等待 很長時間才能看到登錄授權(quán)界面;
[0005] 第二、由于web頁是由開放平臺端統(tǒng)一提供的,第三方應(yīng)用一般是無法對該頁面 的風(fēng)格、布局、內(nèi)容等進行靈活自定義的,很多時候,這個頁面的風(fēng)格會與應(yīng)用客戶端自身 的風(fēng)格出入很大,使得第三方應(yīng)用難以接受,尤其是在第三方游戲應(yīng)用中;
[0006] 第三、應(yīng)用客戶端如果通過外部瀏覽器加載登錄授權(quán)頁則會導(dǎo)致用戶體驗的急劇 下降,如果通過WebView加載,則第三方應(yīng)用仍然是有辦法拿到用戶輸入的賬號、密碼等敏 感信息的,其安全性不夠高;
[0007] 第四、當應(yīng)用客戶端同時需要多個開放平臺所提供的用戶數(shù)據(jù)和云能力來實現(xiàn)一 項功能時,就得想辦法引導(dǎo)用戶挨個在多個平臺上進行登錄授權(quán),在每次登錄授權(quán)都要出 一個登錄授權(quán)界面的情況下,這樣的工作基本上無法有效開展的。應(yīng)用客戶端需要的是,在 用戶不受干擾的情況下,順暢完成多個平臺的授權(quán)問題,這樣才能獲得最大的轉(zhuǎn)化率。


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

[0008] 有鑒于此,本發(fā)明實施例提供一種平臺授權(quán)方法、平臺服務(wù)端及應(yīng)用客戶端,以改 善應(yīng)用客戶端得到平臺服務(wù)端授權(quán)的機制。
[0009] 第一方面,本發(fā)明實施例提供了一種平臺服務(wù)端的平臺授權(quán)方法,包括:
[0010] 平臺服務(wù)端接收應(yīng)用客戶端通過第一路徑發(fā)送的第一驗證消息并獲取所述應(yīng)用 客戶端的客戶端標識; toon] 所述平臺服務(wù)端對所接收的第一驗證消息與所述客戶端標識之間的映射關(guān)系進 行記錄;
[0012] 所述平臺服務(wù)端接收所述應(yīng)用客戶端通過第二路徑發(fā)送的第二驗證消息;
[0013] 如果所述平臺服務(wù)端驗證所述第一驗證消息和第二驗證消息匹配,則根據(jù)所述第 一驗證消息從所記錄的所述映射關(guān)系中提取所述客戶端標識,并根據(jù)所述客戶端標識生成 授權(quán)訪問令牌,發(fā)送給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端。
[0014] 第二方面,本發(fā)明實施例還提供了一種應(yīng)用客戶端的平臺授權(quán)方法,包括:
[0015] 應(yīng)用客戶端通過第一路徑向平臺服務(wù)端發(fā)送第一驗證消息,以供所述平臺服務(wù)端 對所述第一驗證消息與所述應(yīng)用客戶端的客戶端標識之間的映射關(guān)系進行記錄;
[0016] 應(yīng)用客戶端通過第二路徑向所述平臺服務(wù)端轉(zhuǎn)發(fā)第二驗證消息,以供如果所述平 臺服務(wù)端驗證所述第一驗證消息和第二驗證消息匹配,則根據(jù)所述第一驗證消息從所記錄 的所述映射關(guān)系中提取所述客戶端標識,并根據(jù)所述客戶端標識生成授權(quán)訪問令牌,發(fā)送 給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端;
[0017] 應(yīng)用客戶端接收所述平臺服務(wù)端發(fā)送的授權(quán)訪問令牌。
[0018] 第三方面,本發(fā)明實施例還提供了一種平臺授權(quán)方法,包括:
[0019] 應(yīng)用客戶端通過第一路徑向平臺服務(wù)端發(fā)送第一驗證消息;
[0020] 平臺服務(wù)端接收應(yīng)用客戶端通過第一路徑發(fā)送的第一驗證消息并獲取所述應(yīng)用 客戶端的客戶端標識;
[0021] 所述平臺服務(wù)端對所接收的第一驗證消息與所述客戶端標識之間的映射關(guān)系進 行記錄;
[0022] 應(yīng)用客戶端通過第二路徑向所述平臺服務(wù)端轉(zhuǎn)發(fā)第二驗證消息;
[0023] 所述平臺服務(wù)端接收所述應(yīng)用客戶端通過第二路徑發(fā)送的第二驗證消息;
[0024] 如果所述平臺服務(wù)端驗證所述第一驗證消息和第二驗證消息匹配,則根據(jù)所述第 一驗證消息從所記錄的所述映射關(guān)系中提取所述客戶端標識,并根據(jù)所述客戶端標識生成 授權(quán)訪問令牌,發(fā)送給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端;
[0025] 應(yīng)用客戶端接收所述平臺服務(wù)端和/或應(yīng)用服務(wù)端發(fā)送的授權(quán)訪問令牌。
[0026] 第四方面,本發(fā)明實施例還提供了一種平臺服務(wù)端,包括:
[0027] 第一驗證消息接收單元,用于接收應(yīng)用客戶端通過第一路徑發(fā)送的第一驗證消息 并獲取所述應(yīng)用客戶端的客戶端標識;
[0028] 映射關(guān)系記錄單元,用于對所接收的第一驗證消息與所述客戶端標識之間的映射 關(guān)系進行記錄;
[0029] 第二驗證消息接收單元,用于接收所述應(yīng)用客戶端通過第二路徑發(fā)送的第二驗證 消息;
[0030] 驗證與授權(quán)單元,用于如果驗證所述第一驗證消息和第二驗證消息匹配,則根據(jù) 所述第一驗證消息從所記錄的所述映射關(guān)系中提取所述客戶端標識,并根據(jù)所述客戶端標 識生成授權(quán)訪問令牌,發(fā)送給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端。
[0031] 第五方面,本發(fā)明實施例還提供了一種應(yīng)用客戶端,包括:
[0032] 第一驗證消息發(fā)送單元,用于通過第一路徑向平臺服務(wù)端發(fā)送第一驗證消息,以 供所述平臺服務(wù)端對所述第一驗證消息與所述應(yīng)用客戶端的客戶端標識之間的映射關(guān)系 進行記錄;
[0033] 第二驗證消息發(fā)送單元,用于通過第二路徑向所述平臺服務(wù)端轉(zhuǎn)發(fā)第二驗證消 息,以供如果所述平臺服務(wù)端驗證所述第一驗證消息和第二驗證消息匹配,則根據(jù)所述第 一驗證消息從所記錄的所述映射關(guān)系中提取所述客戶端標識,并根據(jù)所述客戶端標識生成 授權(quán)訪問令牌,發(fā)送給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端;
[0034] 授權(quán)訪問令牌接收單元,用于接收所述平臺服務(wù)端發(fā)送的授權(quán)訪問令牌。
[0035] 第六方面,本發(fā)明實施例還提供了一種平臺授權(quán)系統(tǒng),包括:本發(fā)明任意實施例所 提供的平臺服務(wù)端和本發(fā)明任意實施例所提供的應(yīng)用客戶端。
[0036] 本發(fā)明實施例提出的技術(shù)方案,應(yīng)用客戶端通過第一路徑向平臺服務(wù)端發(fā)送第一 驗證消息,并通過第二路徑發(fā)送的第二驗證消息,如果所述平臺服務(wù)端驗證所述第一驗證 消息和第二驗證消息匹配,則從所記錄的映射關(guān)系中提取所述客戶端標識,并根據(jù)所述客 戶端標識生成授權(quán)訪問令牌,發(fā)送給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端,無需通過網(wǎng)頁進 行登錄,能使得用戶對授權(quán)過程無感知,并能進一步提高授權(quán)的安全性。

【專利附圖】

【附圖說明】
[0037] 為了更清楚地說明本發(fā)明實施例中的技術(shù)方案,下面將對本發(fā)明實施例描述中所 需要使用的附圖作簡單的介紹,顯而易見地,下面描述中的附圖僅僅是本發(fā)明的一些實施 例,對于本領(lǐng)域普通技術(shù)人員來講,在不付出創(chuàng)造性勞動的前提下,還可以根據(jù)本發(fā)明實施 例的內(nèi)容和這些附圖獲得其他的附圖。
[0038] 圖1是本發(fā)明實施例一所述的平臺服務(wù)端的平臺授權(quán)方法的流程圖;
[0039] 圖2是本發(fā)明實施例二所述的平臺服務(wù)端的平臺授權(quán)方法的流程圖;
[0040] 圖3是本發(fā)明實施例三所述的應(yīng)用客戶端的平臺授權(quán)方法的流程圖;
[0041] 圖4是本發(fā)明實施例四所述的應(yīng)用客戶端的平臺授權(quán)方法的流程圖;
[0042] 圖5是本發(fā)明實施例五所述的平臺授權(quán)方法的流程圖;
[0043] 圖6是本發(fā)明實施例六所述的平臺服務(wù)端的結(jié)構(gòu)框圖;
[0044] 圖7是本發(fā)明實施例七所述的應(yīng)用客戶端的結(jié)構(gòu)框圖;
[0045] 圖8是本發(fā)明實施例八所述的平臺授權(quán)方法中平臺服務(wù)端與應(yīng)用客戶端以及應(yīng) 用服務(wù)端的交互示意圖。

【具體實施方式】
[0046] 為使本發(fā)明解決的技術(shù)問題、采用的技術(shù)方案和達到的技術(shù)效果更加清楚,下面 將結(jié)合附圖對本發(fā)明實施例的技術(shù)方案作進一步的詳細描述,顯然,所描述的實施例僅僅 是本發(fā)明一部分實施例,而不是全部的實施例。基于本發(fā)明中的實施例,本領(lǐng)域技術(shù)人員在 沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例,都屬于本發(fā)明保護的范圍。
[0047] 下面結(jié)合附圖并通過【具體實施方式】來進一步說明本發(fā)明的技術(shù)方案。
[0048] 實施例一
[0049] 圖1是本發(fā)明實施例一提供的平臺服務(wù)端的平臺授權(quán)方法流程圖,本實施例可適 用于應(yīng)用客戶端請求調(diào)用開放平臺中需要終端用戶授權(quán)的OpenAPI時獲取授權(quán)訪問令牌 情況,其中,所述應(yīng)用客戶端可以為安裝于終端上的應(yīng)用軟件、即時通訊客戶端、游戲娛樂 客戶端或終端上的系統(tǒng)工具,即第三方應(yīng)用。該方法可以由平臺服務(wù)端來執(zhí)行,平臺服務(wù)端 是能夠向第三方應(yīng)用提供平臺服務(wù)的服務(wù)器,如圖1所示,本實施例所述的平臺服務(wù)端的 平臺授權(quán)方法包括:
[0050] S101、平臺服務(wù)端接收應(yīng)用客戶端通過第一路徑發(fā)送的第一驗證消息并獲取所述 應(yīng)用客戶端所在終端的終端標識,所述第一驗證消息包括隨機字符串。
[0051] 為了防止應(yīng)用客戶端惡意獲取平臺方的用戶數(shù)據(jù),通過第一路徑發(fā)送的第一驗證 消息優(yōu)選為通過調(diào)用終端系統(tǒng)提供的系統(tǒng)接口向平臺服務(wù)端發(fā)送的第一驗證消息,例如可 調(diào)用短信接口通過短信網(wǎng)關(guān)轉(zhuǎn)發(fā)所述第一驗證消息。
[0052] 作為優(yōu)選,所述應(yīng)用客戶端生成隨機字符串,并創(chuàng)建包含所述隨機字符串且目的 地址為所述平臺服務(wù)端的驗證短信。所述應(yīng)用客戶端發(fā)送所述驗證短信至短信網(wǎng)關(guān),指示 所述短信網(wǎng)關(guān)將所述驗證短信進行協(xié)議轉(zhuǎn)換,生成包含所述隨機字符串的第一驗證消息, 發(fā)送給所述平臺服務(wù)端。短信網(wǎng)關(guān)可以從驗證短信中提取短信發(fā)送方的終端標識,攜帶在 第一驗證消息中進行發(fā)送,則所述平臺服務(wù)端接收后提取所述隨機字符串和終端標識。
[0053] S102、所述平臺服務(wù)端對所接收的隨機字符串與所述終端標識之間的映射關(guān)系進 行記錄。
[0054] 所述終端標識為用于唯一區(qū)分終端的標識碼,只要平臺服務(wù)端接收應(yīng)用客戶端通 過第一路徑發(fā)送的第一驗證消息時,能用來識別出是哪一個終端即可,所述終端標識包括 但不限于電話號碼和終端的設(shè)備標識。終端標識通常被用戶用來標識自己的賬戶,能據(jù)此 獲取賬戶信息。
[0055] S103、所述平臺服務(wù)端接收所述應(yīng)用客戶端通過應(yīng)用服務(wù)端轉(zhuǎn)發(fā)的第二驗證消 息,所述第二驗證消息包括所述隨機字符串和身份認證信息。
[0056] 為了安全起見,在注冊過程中,各應(yīng)用客戶端或應(yīng)用服務(wù)器還會向平臺服務(wù)端提 交身份認證信息(例如應(yīng)用密鑰),以進行身份認證。在平臺服務(wù)端會在數(shù)據(jù)庫中對所述身 份標識和所述身份認證信息之間的映射關(guān)系進行記錄,用于關(guān)聯(lián)查找。各應(yīng)用客戶端或應(yīng) 用服務(wù)器在向平臺服務(wù)端發(fā)起訪問請求時,需要發(fā)送身份認證信息用以進行身份認證,身 份認證信息包括包名和包簽名。
[0057] 進一步地,為了安全起見,所述平臺服務(wù)端接收到所述身份認證信息后,根據(jù)所述 隨機字符串從所記錄的所述映射關(guān)系中提取所述終端標識之前,還包括:如果所述平臺服 務(wù)器驗證所述身份認證信息為有效,則觸發(fā)后續(xù)操作。即平臺服務(wù)端先判斷所述身份認證 信息的有效性。若無效,則拒絕該應(yīng)用客戶端獲取平臺方的相關(guān)數(shù)據(jù),可返回對應(yīng)的錯誤信 息進行提示,若有效,則可允許進行后續(xù)操作。
[0058] -般來說,平臺方會為已注冊的各應(yīng)用客戶端設(shè)置有差異的權(quán)限信息,以控制各 應(yīng)用客戶端的數(shù)據(jù)訪問權(quán)限。若平臺服務(wù)端判定應(yīng)用客戶端的身份認證信息的有效,則需 要根據(jù)所述身份認證信息從數(shù)據(jù)庫中讀取出對應(yīng)的權(quán)限信息。
[0059] 進一步地,所述第二驗證消息還可包括所述應(yīng)用客戶端期望獲取的數(shù)據(jù)訪問權(quán)限 列表。
[0060] 作為優(yōu)選所述第二驗證消息可通過與第一路徑不同的第二路徑轉(zhuǎn)發(fā),為了保證安 全,所述第二路徑可基于SSL(Secure Sockets Layer,安全套接層)協(xié)議,進一步地,所述第 二路徑可基于 HTTPS (Hyper Text Transfer Protocol over Secure Socket Layer,安全 超文本傳輸協(xié)議)協(xié)議。例如,基于所述第二路徑發(fā)送的第二驗證消息可為基于HTTPS發(fā) 送的HTTPS請求。為了防止應(yīng)用客戶端利用所述第二路徑惡意獲取平臺方的用戶數(shù)據(jù),應(yīng) 用客戶端需要針對所述第二路徑作必要的安全防護以提升其他客戶端利用該路徑的難度 和成本,例如提供套接字SOCKET接口代替HTTP (Hypertext Transfer Protocol,超文本傳 輸協(xié)議)接口,對所述第二驗證消息作相應(yīng)的對稱加密或非對稱加密,增加防跨站請求偽 造攻擊處理策略等。
[0061] S104、如果所述平臺服務(wù)端驗證所述第一驗證消息和第二驗證消息中的隨機字符 串一致,則根據(jù)所述隨機字符串從所記錄的所述映射關(guān)系中提取所述終端標識,并根據(jù)所 述終端標識獲取對應(yīng)的用戶賬號信息。
[0062] S105、所述平臺服務(wù)端根據(jù)所述用戶賬號信息和所述身份認證信息生成授權(quán)訪問 令牌,發(fā)送給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端。
[0063] 平臺服務(wù)端可將生成授權(quán)訪問令牌通過所述第一路徑或與所述第一路徑不同的 第二路徑發(fā)送給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端,由于數(shù)據(jù)大小問題和對收到的數(shù)據(jù)使 用便捷性問題,優(yōu)選為通過所述第二路徑進行發(fā)送。
[0064] 可根據(jù)應(yīng)用客戶端的身份認證信息查找對應(yīng)的應(yīng)用服務(wù)端的身份認證信息,從而 再查找對應(yīng)的應(yīng)用服務(wù)端的地址,或者根據(jù)第二驗證消息的發(fā)送端的信息查找所述應(yīng)用服 務(wù)端對應(yīng)的第二路徑的地址,進而,授權(quán)訪問令牌通過第二路徑發(fā)送給應(yīng)用服務(wù)端。
[0065] 若平臺服務(wù)端將生成授權(quán)訪問令牌發(fā)送給應(yīng)用服務(wù)端,則所述應(yīng)用服務(wù)端接收到 授權(quán)訪問令牌后,可根據(jù)需要決定是否需要將訪問令牌在應(yīng)用服務(wù)端作保存,以及是否將 所述授權(quán)訪問令牌轉(zhuǎn)發(fā)給應(yīng)用客戶端,以進一步對應(yīng)用客戶端的授權(quán)安全性進行控制。 [0066] 第三方應(yīng)用的應(yīng)用客戶端從平臺服務(wù)端或應(yīng)用服務(wù)端獲取到的授權(quán)訪問令牌后, 即可通過所述授權(quán)訪問令牌調(diào)用平臺方提供的OpenAPI接口來獲取相應(yīng)的云能力和用戶 數(shù)據(jù)。
[0067] 作為優(yōu)選,所述第二驗證消息還包括所述應(yīng)用客戶端期望數(shù)據(jù)訪問權(quán)限列表,本 操作還可包括:根據(jù)所述用戶賬號信息、所述身份認證信息和期望數(shù)據(jù)訪問權(quán)限列表生成 授權(quán)訪問令牌。
[0068] 進一步地,如果根據(jù)所述終端標識獲取對應(yīng)的用戶賬號信息的操作失敗,則根據(jù) 所述終端標識注冊獲取新的用戶賬號信息。即,如果不存在所述賬號信息,可以根據(jù)通過所 述第一路徑獲取的終端標識自動注冊一個用戶賬號。
[0069] 進一步地,所述訪問令牌中還可包含所述平臺服務(wù)端為所述應(yīng)用客戶端開通的權(quán) 限信息和/或期望獲取的數(shù)據(jù)訪問權(quán)限列表。需要說明的是,本實施例可適用于一個應(yīng)用 客戶端請求獲取一個或一個以上的開放平臺的授權(quán)訪問令牌情況。
[0070] 需要說明的是,應(yīng)用客戶端通過第一路徑發(fā)送第一驗證消息和通過應(yīng)用服務(wù)端轉(zhuǎn) 發(fā)第二驗證消息的時機可以相同,也可以先后不同,只需要滿足操作S104中根據(jù)所述隨機 字符串從所記錄的所述映射關(guān)系中提取對應(yīng)的終端標識的步驟之前,操作S102已完成即 可,優(yōu)選為第一驗證消息和第二驗證消息同時發(fā)送,或第一驗證消息比第二驗證消息先發(fā) 送。
[0071] 本發(fā)明實施例提出的技術(shù)方案通過平臺服務(wù)端接收應(yīng)用客戶端從第一路徑發(fā)送 的包括隨機字符串的第一驗證消息,并接收應(yīng)用客戶端通過應(yīng)用服務(wù)端轉(zhuǎn)發(fā)的包括所述隨 機字符串和身份認證信息的第二驗證消息,驗證所述第一驗證消息和第二驗證消息中的隨 機字符串一致,則根據(jù)所述隨機字符串獲取對應(yīng)的用戶賬號信息,并根據(jù)所述用戶賬號信 息和所述身份認證信息生成授權(quán)訪問令牌,發(fā)送給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端,無 需通過網(wǎng)頁進行登錄,能使得用戶對授權(quán)過程無感知,并能進一步提高授權(quán)的安全性。
[0072] 實施例二
[0073] 圖2是本發(fā)明實施例二提供的平臺服務(wù)端的平臺授權(quán)方法流程圖,本實施例可適 用于應(yīng)用客戶端請求調(diào)用開放平臺中需要終端用戶授權(quán)的OpenAPI時獲取授權(quán)訪問令牌 情況,其中,所述應(yīng)用客戶端可以為安裝于終端上的應(yīng)用軟件、即時通訊客戶端、游戲娛樂 客戶端或終端上的系統(tǒng)工具,即第三方應(yīng)用。該方法可以由平臺服務(wù)端來執(zhí)行,平臺服務(wù)端 是能夠向第三方應(yīng)用提供平臺服務(wù)的服務(wù)器,如圖2所示,本實施例所述的平臺服務(wù)端的 平臺授權(quán)方法包括:
[0074] S201、平臺服務(wù)端接收應(yīng)用客戶端通過第一路徑發(fā)送的第一驗證消息并獲取所述 應(yīng)用客戶端的客戶端標識。
[0075] 本操作包括但不限于實施例一的S101所述的操作。其中,客戶端標識是能夠代表 應(yīng)用客戶端的標識,用于最終獲取用戶的賬戶信息,以生成訪問令牌。客戶端標識可以為客 戶端所服務(wù)的用戶的用戶標識或客戶端所在終端的終端標識,只要能對應(yīng)于用戶的賬戶信 息即可。所以,獲取所述應(yīng)用客戶端的客戶端標識包括但不限于獲取所述應(yīng)用客戶端所在 終端的終端標識,優(yōu)選為獲取所述應(yīng)用客戶端所在終端的終端標識,更進一步地,所述應(yīng)用 客戶端所在終端優(yōu)選為手機,所述應(yīng)用客戶端所在終端的終端標識優(yōu)選為手機號。
[0076] 所述第一驗證消息包括但不限于:所述應(yīng)用客戶端生成的隨機字符串,簽名值,以 及加密字符串等由該應(yīng)用客戶端生成的標示性信息,且優(yōu)選是實時生成的信息,以減少該 信息被盜用的可能。優(yōu)選的,對于簽名值可以由應(yīng)用客戶端根據(jù)其身份認證信息生成,加密 字符串則可以由應(yīng)用客戶端的預(yù)設(shè)加密算法加密獲得,以增加其可靠性。隨機字符串、簽名 值、加密字符串等技術(shù)也可以結(jié)合采用。
[0077] S202、所述平臺服務(wù)端對所接收的第一驗證消息與所述客戶端標識之間的映射關(guān) 系進行記錄。
[0078] 該操作實際上是記錄第一驗證消息中攜帶的應(yīng)用客戶端生成的信息與客戶端標 識之間的關(guān)聯(lián)。應(yīng)用客戶端生成的信息將用于后續(xù)驗證。
[0079] S203、所述平臺服務(wù)端接收所述應(yīng)用客戶端通過第二路徑發(fā)送的第二驗證消息。
[0080] 本操作中,第二驗證消息通過第二路徑發(fā)送,第二路徑和第一路徑為不同路徑,但 均為平臺服務(wù)端與應(yīng)用客戶端之間的交互路徑,例如可以為短信路徑、HTTP消息交互路徑、 通過其他網(wǎng)元的轉(zhuǎn)發(fā)路徑等。通過不同路徑發(fā)送驗證消息,可以降低驗證消息被盜取的可 能性,提高驗證安全性。
[0081] 其中,所述第二驗證消息可以是所述應(yīng)用客戶端直接向所述平臺服務(wù)端發(fā)送的消 息,也可以是所述應(yīng)用客戶端間接向所述平臺服務(wù)端發(fā)送的消息。例如:
[0082] 方式一、所述平臺服務(wù)端接收所述應(yīng)用客戶端直接發(fā)送的第二驗證消息;
[0083] 方式二、所述平臺服務(wù)端接收所述應(yīng)用客戶端通過應(yīng)用服務(wù)端轉(zhuǎn)發(fā)的第二驗證消 息。
[0084] S204、如果所述平臺服務(wù)端驗證所述第一驗證消息和第二驗證消息匹配,則根據(jù) 所述第一驗證消息從所記錄的所述映射關(guān)系中提取所述客戶端標識,并根據(jù)所述客戶端標 識生成授權(quán)訪問令牌,發(fā)送給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端。
[0085] 兩個驗證消息的匹配可通過其中攜帶的信息進行匹配來驗證。
[0086] 例如,所述第一驗證消息包括隨機字符串,所述第二驗證消息也包括所述隨機字 符串,如果所述平臺服務(wù)端驗證所述第一驗證消息和第二驗證消息中的隨機字符串一致, 則確定兩驗證消息匹配。
[0087] 當驗證消息匹配時,可以根據(jù)所述隨機字符串從所記錄的所述映射關(guān)系中提取所 述客戶端標識,例如終端標識,并根據(jù)所述終端標識獲取對應(yīng)的用戶賬號信息。進而,所述 平臺服務(wù)端可以根據(jù)所述用戶賬號信息和所述身份認證信息生成授權(quán)訪問令牌,發(fā)送給所 述應(yīng)用客戶端和/或應(yīng)用服務(wù)端。身份認證信息為生成授權(quán)訪問令牌過程中所需的信息, 其優(yōu)選可通過驗證消息攜帶發(fā)送,即,所述第二驗證消息優(yōu)選是包括所述隨機字符串和身 份認證信息。
[0088] 本發(fā)明實施例提出的技術(shù)方案,應(yīng)用客戶端通過第一路徑向平臺服務(wù)端發(fā)送第一 驗證消息,并通過第二路徑發(fā)送的第二驗證消息,如果所述平臺服務(wù)端驗證所述第一驗證 消息和第二驗證消息匹配,則從所記錄的映射關(guān)系中提取所述客戶端標識,并根據(jù)所述客 戶端標識生成授權(quán)訪問令牌,發(fā)送給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端,無需通過網(wǎng)頁進 行登錄,能使得用戶對授權(quán)過程無感知,并能進一步提高授權(quán)的安全性。
[0089] 實施例三
[0090] 圖3是本發(fā)明實施例三提供的應(yīng)用客戶端的平臺授權(quán)方法流程圖,本實施例可適 用于應(yīng)用客戶端請求調(diào)用開放平臺中需要終端用戶授權(quán)的OpenAPI時獲取授權(quán)訪問令牌 情況,其中,所述應(yīng)用客戶端可以為安裝于終端上的應(yīng)用軟件、即時通訊客戶端、游戲娛樂 客戶端或終端上的系統(tǒng)工具,即第三方應(yīng)用。該方法可以由應(yīng)用客戶端來執(zhí)行,如圖3所 示,本實施例所述的應(yīng)用客戶端的平臺授權(quán)方法包括:
[0091] S301、應(yīng)用客戶端通過第一路徑向平臺服務(wù)端發(fā)送第一驗證消息,所述第一驗證 消息包括隨機字符串。
[0092] 為了防止應(yīng)用客戶端惡意獲取平臺方的用戶數(shù)據(jù),通過第一路徑發(fā)送的第一驗證 消息優(yōu)選為通過調(diào)用系統(tǒng)提供的系統(tǒng)接口向平臺服務(wù)端發(fā)送的第一驗證消息,例如可通過 短信網(wǎng)關(guān)轉(zhuǎn)發(fā)所述第一驗證消息。
[0093] 作為優(yōu)選,所述應(yīng)用客戶端生成隨機字符串,并創(chuàng)建包含所述隨機字符串且目的 地址為所述平臺服務(wù)端的驗證短信。所述應(yīng)用客戶端發(fā)送所述驗證短信至短信網(wǎng)關(guān),指示 所述短信網(wǎng)關(guān)將所述驗證短信進行協(xié)議轉(zhuǎn)換,生成包含所述隨機字符串的第一驗證消息, 發(fā)送給所述平臺服務(wù)端,所述平臺服務(wù)端接收后提取所述隨機字符串和終端標識。短信網(wǎng) 關(guān)可以從驗證短信中提取短信發(fā)送方的終端標識,攜帶在第一驗證消息中進行發(fā)送,則所 述平臺服務(wù)端接收后提取所述隨機字符串和終端標識。
[0094] S302、應(yīng)用客戶端通過應(yīng)用服務(wù)端向所述平臺服務(wù)端轉(zhuǎn)發(fā)第二驗證消息,所述第 二驗證消息包括所述隨機字符串和身份認證信息。
[0095] 需要說明的是,應(yīng)用客戶端可以向應(yīng)用服務(wù)端僅發(fā)送所述隨機字符串,或可以向 應(yīng)用服務(wù)端同時發(fā)送所述隨機字符串和該應(yīng)用客戶端在平臺方注冊時的身份認證信息。 [0096] 若為第一種情況,則應(yīng)用服務(wù)端接收到應(yīng)用客戶端發(fā)送的隨機字符串以后,還需 要查找該應(yīng)用客戶端在平臺方注冊時的身份認證信息,以將包括所述隨機字符串和身份認 證信息的第二驗證消息發(fā)送給所述平臺服務(wù)端。
[0097] 進一步地,所述第二驗證消息還可包括所述應(yīng)用客戶端期望獲取的數(shù)據(jù)訪問權(quán)限 列表,用于應(yīng)用客戶端向平臺服務(wù)端明確提出需要申請的數(shù)據(jù)的訪問權(quán)限的數(shù)據(jù)范圍。
[0098] 為了保證安全,所述第二路徑可基于SSL協(xié)議,進一步地,所述第二路徑可基于 HTTPS協(xié)議。
[0099] 例如,基于所述第二路徑發(fā)送的第二驗證消息可為基于HTTPS協(xié)議發(fā)送的HTTPS 請求。為了防止應(yīng)用客戶端利用所述第二路徑惡意獲取平臺方的用戶數(shù)據(jù),應(yīng)用服務(wù)端需 要作必要的安全防護以提升其他客戶端惡意獲取平臺方的用戶數(shù)據(jù)的難度和成本,例如提 供SOCKET接口代替HTTP接口,對所述第二驗證消息作相應(yīng)的對稱加密或非對稱加密,增加 防跨站請求偽造攻擊處理策略等。
[0100] S303、應(yīng)用客戶端接收所述平臺服務(wù)端或所述應(yīng)用服務(wù)端發(fā)送的授權(quán)訪問令牌。
[0101] 需要說明的是,應(yīng)用客戶端通過第一路徑發(fā)送第一驗證消息和通過應(yīng)用服務(wù)端轉(zhuǎn) 發(fā)第二驗證消息的時機可以相同,也可以先后不同,只需要滿足平臺服務(wù)端根據(jù)所述隨機 字符串從所記錄的所述映射關(guān)系中提取對應(yīng)的終端標識的操作之前,通過第一路徑向平臺 服務(wù)端發(fā)送第一驗證消息成功即可,優(yōu)選為第一驗證消息和第二驗證消息同時發(fā)送,或第 一驗證消息比第二驗證消息先發(fā)送。
[0102] 本發(fā)明實施例提出的技術(shù)方案通過應(yīng)用客戶端通過第一路徑向平臺服務(wù)端發(fā)送 包括隨機字符串的第一驗證消息,并通過應(yīng)用服務(wù)端轉(zhuǎn)發(fā)包括所述隨機字符串和身份認證 信息的第二驗證消息,如果所述平臺服務(wù)端驗證所述第一驗證消息和第二驗證消息中的隨 機字符串一致,則根據(jù)所述隨機字符串獲取對應(yīng)的用戶賬號信息,并根據(jù)所述用戶賬號信 息和所述身份認證信息生成授權(quán)訪問令牌,發(fā)送給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端,無 需通過網(wǎng)頁進行登錄,能使得用戶對授權(quán)過程無感知,并能進一步提高授權(quán)的安全性。
[0103] 實施例四
[0104] 圖4是本發(fā)明實施例四提供的應(yīng)用客戶端的平臺授權(quán)方法流程圖,本實施例可適 用于應(yīng)用客戶端請求調(diào)用開放平臺中需要終端用戶授權(quán)的OpenAPI時獲取授權(quán)訪問令牌 情況,其中,所述應(yīng)用客戶端可以為安裝于終端上的應(yīng)用軟件、即時通訊客戶端、游戲娛樂 客戶端或終端上的系統(tǒng)工具,即第三方應(yīng)用。該方法可以由應(yīng)用客戶端來執(zhí)行,如圖4所 示,本實施例所述的應(yīng)用客戶端的平臺授權(quán)方法包括:
[0105] S401、應(yīng)用客戶端通過第一路徑向平臺服務(wù)端發(fā)送第一驗證消息。
[0106] 本操作用于供所述平臺服務(wù)端對所述第一驗證消息與所述應(yīng)用客戶端的客戶端 標識之間的映射關(guān)系進行記錄。
[0107] S401、應(yīng)用客戶端通過第二路徑向所述平臺服務(wù)端轉(zhuǎn)發(fā)第二驗證消息。
[0108] 本操作用于供如果所述平臺服務(wù)端驗證所述第一驗證消息和第二驗證消息匹配, 則根據(jù)所述第一驗證消息從所記錄的所述映射關(guān)系中提取所述客戶端標識,并根據(jù)所述客 戶端標識生成授權(quán)訪問令牌,發(fā)送給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端;
[0109] S401、應(yīng)用客戶端接收所述平臺服務(wù)端發(fā)送的授權(quán)訪問令牌。
[0110] 與前述實施例二相應(yīng)的是,應(yīng)用客戶端通過兩條不同的路徑向平臺服務(wù)端發(fā)送驗 證消息。路徑可以從短信、HTTP消息或通過應(yīng)用服務(wù)端轉(zhuǎn)發(fā)等路徑中進行選擇和組合,優(yōu) 選是,應(yīng)用客戶端通過短信網(wǎng)關(guān)向所述平臺服務(wù)端轉(zhuǎn)發(fā)第一驗證消息,作為第一路徑。應(yīng)用 客戶端通過應(yīng)用服務(wù)端向所述平臺服務(wù)端轉(zhuǎn)發(fā)第二驗證消息,作為第二路徑。
[0111] 第一驗證消息和第二驗證消息中均攜帶用于進行匹配驗證的信息,該信息如前所 述,由應(yīng)用客戶端生成,例如為隨機字符串、簽名值、或加密字符串等信息。一個優(yōu)選實例 為,所述第一驗證消息包括隨機字符串,所述第二驗證消息包括所述隨機字符串和身份認 證信息。
[0112] 所述客戶端標識為代表應(yīng)用客戶端,并能夠用于查找對應(yīng)的用戶賬戶信息的標 識,優(yōu)選地,所述客戶端標識為所述應(yīng)用客戶端所在終端的終端標識。
[0113] 本發(fā)明實施例提出的技術(shù)方案通過應(yīng)用客戶端通過第一路徑向平臺服務(wù)端發(fā)送 第一驗證消息,并通過第二路徑向所述平臺服務(wù)端轉(zhuǎn)發(fā)第二驗證消息,以供如果所述平臺 服務(wù)端驗證所述第一驗證消息和第二驗證消息匹配,則根據(jù)所述第一驗證消息從所記錄的 所述映射關(guān)系中提取所述客戶端標識,并根據(jù)所述客戶端標識生成授權(quán)訪問令牌,發(fā)送給 所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端,無需通過網(wǎng)頁進行登錄,能使得用戶對授權(quán)過程無感 知,并能進一步提高授權(quán)的安全性。
[0114] 實施例五
[0115] 圖5是本發(fā)明實施例六提供的平臺授權(quán)方法流程圖,本實施例可適用于應(yīng)用客戶 端請求調(diào)用開放平臺中需要終端用戶授權(quán)的OpenAPI時獲取授權(quán)訪問令牌情況,其中,所 述應(yīng)用客戶端可以為安裝于終端上的應(yīng)用軟件、即時通訊客戶端、游戲娛樂客戶端或終端 上的系統(tǒng)工具,即第三方應(yīng)用。該方法由平臺服務(wù)端和應(yīng)用客戶端配合來執(zhí)行,如圖5所 示,本實施例所述的平臺授權(quán)方法包括:
[0116] S501、應(yīng)用客戶端通過第一路徑向平臺服務(wù)端發(fā)送第一驗證消息。
[0117] S502、平臺服務(wù)端接收應(yīng)用客戶端通過第一路徑發(fā)送的第一驗證消息并獲取所述 應(yīng)用客戶端的客戶端標識。
[0118] S503、所述平臺服務(wù)端對所接收的第一驗證消息與所述客戶端標識之間的映射關(guān) 系進行記錄。
[0119] S504、應(yīng)用客戶端通過第二路徑向所述平臺服務(wù)端轉(zhuǎn)發(fā)第二驗證消息;
[0120] S505、所述平臺服務(wù)端接收所述應(yīng)用客戶端通過第二路徑發(fā)送的第二驗證消息。
[0121] S506、如果所述平臺服務(wù)端驗證所述第一驗證消息和第二驗證消息匹配,則根據(jù) 所述第一驗證消息從所記錄的所述映射關(guān)系中提取所述客戶端標識,并根據(jù)所述客戶端標 識生成授權(quán)訪問令牌,發(fā)送給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端。
[0122] S507、應(yīng)用客戶端接收所述平臺服務(wù)端和/或應(yīng)用服務(wù)端發(fā)送的授權(quán)訪問令牌。
[0123] 作為優(yōu)選,所述第二路徑為通過應(yīng)用服務(wù)端轉(zhuǎn)發(fā)。
[0124] 作為優(yōu)選,所述第一驗證消息包括隨機字符串,所述第二驗證消息包括所述隨機 字符串和身份認證信息;
[0125] 作為優(yōu)選,所述客戶端標識為所述客戶端所在終端的終端標識。
[0126] 本實施例提出的技術(shù)方案中各操作的說明詳見實施例一、實施例二、實施例三和 實施例四的對應(yīng)操作,具有實施例一、實施例二、實施例三和實施例四的有益效果。
[0127] 實施例六
[0128] 圖6是本發(fā)明實施例三所述的平臺服務(wù)端的結(jié)構(gòu)框圖,如圖6所示,本實施例所述 的平臺服務(wù)端包括:
[0129] 第一驗證消息接收單元601,用于接收應(yīng)用客戶端通過第一路徑發(fā)送的第一驗證 消息并獲取所述應(yīng)用客戶端的客戶端標識;
[0130] 映射關(guān)系記錄單元602,用于對所接收的第一驗證消息與所述客戶端標識之間的 映射關(guān)系進行記錄;
[0131] 第二驗證消息接收單元603,用于接收所述應(yīng)用客戶端通過第二路徑發(fā)送的第二 驗證消息;
[0132] 驗證與授權(quán)單元604,用于如果驗證所述第一驗證消息和第二驗證消息匹配,則根 據(jù)所述第一驗證消息從所記錄的所述映射關(guān)系中提取所述客戶端標識,并根據(jù)所述客戶端 標識生成授權(quán)訪問令牌,發(fā)送給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端。
[0133] 進一步地,所述第二驗證消息接收單元603具體用于:
[0134] 接收所述應(yīng)用客戶端通過應(yīng)用服務(wù)端轉(zhuǎn)發(fā)的第二驗證消息。
[0135] 進一步地:
[0136] 所述第一驗證消息包括隨機字符串,所述第二驗證消息包括所述隨機字符串和身 份認證信息;
[0137] 所述驗證與授權(quán)單元604具體用于:驗證所述第一驗證消息和第二驗證消息中的 隨機字符串一致。
[0138] 進一步地,所述客戶端標識為所述客戶端所在終端的終端標識,則所述驗證與授 權(quán)單元604具體用于:
[0139] 根據(jù)所述終端標識獲取對應(yīng)的用戶賬號信息;
[0140] 根據(jù)所述用戶賬號信息和所述身份認證信息生成授權(quán)訪問令牌,發(fā)送給所述應(yīng)用 客戶端和/或應(yīng)用服務(wù)端。
[0141] 進一步地,所述第一驗證消息接收單元601具體用于:
[0142] 接收所述應(yīng)用客戶端通過短信網(wǎng)關(guān)轉(zhuǎn)發(fā)的第一驗證消息,其中,所述第一驗證消 息為所述短信網(wǎng)關(guān)根據(jù)所述應(yīng)用客戶端發(fā)送的驗證短信進行協(xié)議格式轉(zhuǎn)換后的消息,所述 驗證短信中攜帶有所述隨機字符串;
[0143] 從所述第一驗證消息中獲取所述應(yīng)用客戶端所在終端的終端標識,所述終端標識 為所述短信網(wǎng)關(guān)從所述驗證短信中提取的短信發(fā)起方終端標識。
[0144] 進一步地:所述第二驗證消息通過第二路徑轉(zhuǎn)發(fā),所述第二路徑為基于安全超文 本傳輸協(xié)議HTTPS發(fā)送的HTTPS請求;和/或
[0145] 所述第二驗證消息還包括所述應(yīng)用客戶端提供的期望數(shù)據(jù)訪問權(quán)限列表;和/或
[0146] 所述身份認證信息包括包名和包簽名;和/或
[0147] 所述終端的標識為手機號。
[0148] 本實施例提供的平臺服務(wù)端可執(zhí)行本發(fā)明實施例一和實施例二所提供的平臺服 務(wù)端的平臺授權(quán)方法,具備執(zhí)行方法相應(yīng)的功能模塊和有益效果。
[0149] 實施例七
[0150] 圖7是本發(fā)明實施例四所述的應(yīng)用客戶端的結(jié)構(gòu)框圖,如圖7所示,本實施例所述 的應(yīng)用客戶端包括:
[0151] 第一驗證消息發(fā)送單元701,用于通過第一路徑向平臺服務(wù)端發(fā)送第一驗證消息, 以供所述平臺服務(wù)端對所述第一驗證消息與所述應(yīng)用客戶端的客戶端標識之間的映射關(guān) 系進行記錄;
[0152] 第二驗證消息發(fā)送單元702,用于通過第二路徑向所述平臺服務(wù)端轉(zhuǎn)發(fā)第二驗證 消息,以供如果所述平臺服務(wù)端驗證所述第一驗證消息和第二驗證消息匹配,則根據(jù)所述 第一驗證消息從所記錄的所述映射關(guān)系中提取所述客戶端標識,并根據(jù)所述客戶端標識生 成授權(quán)訪問令牌,發(fā)送給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端;
[0153] 授權(quán)訪問令牌接收單元703,用于接收所述平臺服務(wù)端發(fā)送的授權(quán)訪問令牌。
[0154] 進一步地,所述第二驗證消息發(fā)送單元702具體用于:
[0155] 通過應(yīng)用服務(wù)端向所述平臺服務(wù)端轉(zhuǎn)發(fā)第二驗證消息。
[0156] 進一步地:
[0157] 所述第一驗證消息包括隨機字符串,所述第二驗證消息包括所述隨機字符串和身 份認證信息。
[0158] 進一步地,所述客戶端標識為所述應(yīng)用客戶端所在終端的終端標識。
[0159] 進一步地,所述第一驗證消息發(fā)送單元701具體用于:
[0160] 生成隨機字符串,并創(chuàng)建包含所述隨機字符串且目的地址為所述平臺服務(wù)端的驗 證短/[目;
[0161] 發(fā)送所述驗證短信至短信網(wǎng)關(guān),以指示所述短信網(wǎng)關(guān)將所述驗證短信進行協(xié)議轉(zhuǎn) 換并提取所述驗證短信的短信發(fā)起方終端標識,生成包含所述隨機字符串的第一驗證消 息,向所述平臺服務(wù)端發(fā)送。
[0162] 進一步地,所述第二驗證消息發(fā)送單元702具體用于:
[0163] 將所述隨機字符串發(fā)送給所述應(yīng)用服務(wù)端,以指示所述應(yīng)用服務(wù)端將所述隨機字 符串和身份認證信息攜帶在第二驗證消息中向平臺服務(wù)端發(fā)送,所述第二驗證消息為基于 安全超文本傳輸協(xié)議HTTPS發(fā)送的HTTPS請求。
[0164] 進一步地,所述第二驗證消息發(fā)送單元702具體用于:
[0165] 在發(fā)送所述第一驗證消息的同時或發(fā)送所述第一驗證消息成功之后,通過應(yīng)用服 務(wù)端向所述平臺服務(wù)端轉(zhuǎn)發(fā)第二驗證消息。
[0166] 本實施例提供的應(yīng)用客戶端可執(zhí)行本發(fā)明實施例三和實施例四所提供的應(yīng)用客 戶端的平臺授權(quán)方法,具備執(zhí)行方法相應(yīng)的功能模塊和有益效果。
[0167] 實施例八
[0168] 圖8是本發(fā)明實施例八所述的平臺授權(quán)方法中,平臺服務(wù)端與應(yīng)用客戶端以及應(yīng) 用服務(wù)端的交互示意圖,本實施例主要應(yīng)用在安卓系統(tǒng)的手機應(yīng)用程序(下稱應(yīng)用客戶 端)中,基于由平臺服務(wù)端、應(yīng)用客戶端、應(yīng)用服務(wù)端和短信網(wǎng)關(guān)組成的系統(tǒng)。如圖8所示, 本實施例所述的方法包括:
[0169] 801、應(yīng)用客戶端向平臺服務(wù)端發(fā)送內(nèi)含隨機字符串的第一驗證消息。
[0170] 即應(yīng)用客戶端向平臺服務(wù)端發(fā)送短信,應(yīng)用客戶端按照平臺方要求的格式生成一 個包含隨機的的字符串的短信內(nèi)容串,并發(fā)送到通過調(diào)用系統(tǒng)提供的直接發(fā)送短信的接 口,將所述短信內(nèi)容串發(fā)送到平臺方提供的短信網(wǎng)關(guān),以指示所述接口將所述驗證短信進 行協(xié)議轉(zhuǎn)換并提取所述驗證短信的短信發(fā)起方終端標識,生成包含所述隨機字符串的第一 驗證消息,向所述平臺服務(wù)端發(fā)送。
[0171] 具體地,應(yīng)用客戶端可調(diào)用平臺方提供的軟件開發(fā)工具包SDK(Software Development Kit,軟件開發(fā)工具包)包提供的接口來獲取一個特定格式的短信內(nèi)容串。
[0172] 802、短信網(wǎng)關(guān)向平臺服務(wù)端發(fā)送客戶端所在終端標識和第一驗證消息。
[0173] 例如,短信網(wǎng)關(guān)將短信內(nèi)容串及發(fā)送短信的手機號基于HTTP通過發(fā)送HTTP請求 轉(zhuǎn)發(fā)給平臺方的平臺服務(wù)端。
[0174] 平臺服務(wù)端接收到短信內(nèi)容串和手機號后,往緩存系統(tǒng)存儲一條所述短信內(nèi)容串 到手機號的映射關(guān)系數(shù)據(jù),并設(shè)一定的過期時間(一般時間較短,例如1分鐘)。
[0175] 803、應(yīng)用客戶端向應(yīng)用服務(wù)端發(fā)送隨機字符串。
[0176] 應(yīng)用客戶端在短信發(fā)送成功后,可以調(diào)用系統(tǒng)接口向應(yīng)用服務(wù)端發(fā)送隨機字符串 等數(shù)據(jù)。
[0177] 需要說明的是,應(yīng)用客戶端可以向應(yīng)用服務(wù)端僅發(fā)送隨機字符串,或可向應(yīng)用服 務(wù)端同時發(fā)送隨機字符串和所述應(yīng)用客戶端在平臺方注冊時的身份認證信息。
[0178] 若為第一種情況,則應(yīng)用服務(wù)端接收到應(yīng)用客戶端發(fā)送的隨機字符串以后,還需 要查找該應(yīng)用客戶端在平臺方注冊時的身份認證信息,以將隨機字符串和第二驗證消息一 起發(fā)送給平臺服務(wù)端。
[0179] 為了防止惡意應(yīng)用客戶端利用該接口來獲取平臺方頒發(fā)給該應(yīng)用客戶端的授權(quán) 訪問令牌,應(yīng)用服務(wù)端需要對該接口作必要的安全防護以提升其他人利用該接口的難度與 成本,如提供套接字接口而不是HTTP接口,數(shù)據(jù)作相應(yīng)的對稱加密或非對稱加密處理,增 加防攻擊處理策略等。
[0180] 804、應(yīng)用服務(wù)端向平臺服務(wù)端發(fā)送第二驗證消息,內(nèi)含隨機字符串、應(yīng)用客戶端 的身份認證信息和期望數(shù)據(jù)訪問權(quán)限列表。
[0181] 需要說明的是,所述第二驗證消息至少包括隨機字符串、應(yīng)用客戶端的身份認證 信息,還可包括期望獲取的數(shù)據(jù)訪問權(quán)限列表。
[0182] 應(yīng)用服務(wù)端將第二驗證消息,其中攜帶隨機字符串、應(yīng)用客戶端在平臺注冊時的 身份認證信息(如身份標識,應(yīng)用密鑰等)、以及期望獲取的數(shù)據(jù)訪問權(quán)限列表發(fā)送給平臺 服務(wù)器以獲取訪問令牌,為了保證安全,本次網(wǎng)絡(luò)請求一般需要基于SSUSecure Sockets Layer,安全套接層),如通過HTTPS請求來發(fā)送。
[0183] 805、平臺服務(wù)端向應(yīng)用服務(wù)端返回所生成的授權(quán)訪問令牌。
[0184] 平臺服務(wù)端接收到所述第二驗證消息,應(yīng)用客戶端在平臺注冊時的身份認證信息 (如身份標識,應(yīng)用密鑰等),以及期望獲取的數(shù)據(jù)訪問權(quán)限后,先判斷應(yīng)用客戶端的身份 認證信息的有效性,若無效,則返回對應(yīng)的錯誤信息,否則根據(jù)所述身份認證信息從數(shù)據(jù)庫 中讀取出平臺方給所述應(yīng)用客戶端開通相關(guān)權(quán)限信息,并繼續(xù)下一步。
[0185] 平臺服務(wù)端根據(jù)所述第一驗證消息從相應(yīng)緩存系統(tǒng)中讀取出對應(yīng)的手機號,并根 據(jù)所述手機號獲取對應(yīng)的用戶賬號信息(如果不存在所述賬號信息,則根據(jù)手機號自動注 冊一個用戶賬號),并根據(jù)所述用戶賬號信息、所述應(yīng)用身份認證信息、平臺服務(wù)端為所述 應(yīng)用客戶端開通的權(quán)限信息以及所述數(shù)據(jù)訪問權(quán)限生成一個授權(quán)訪問令牌,并將訪問令牌 返回給應(yīng)用服務(wù)端。
[0186] 806、應(yīng)用服務(wù)端向應(yīng)用客戶端發(fā)送授權(quán)訪問令牌。
[0187] 應(yīng)用服務(wù)端接收到授權(quán)訪問令牌后,可以根據(jù)需要決定是否需要將訪問令牌在應(yīng) 用服務(wù)端本地或?qū)?yīng)數(shù)據(jù)庫中存儲,以及是否將所述令牌返回給所述應(yīng)用客戶端。
[0188] 應(yīng)用客戶端獲取到授權(quán)訪問令牌后,即可通過訪問令牌調(diào)用平臺方提供的 OpenAPI接口來獲取相應(yīng)的云能力和用戶數(shù)據(jù)。
[0189] OpenAPI是服務(wù)型網(wǎng)站常見的一種應(yīng)用,網(wǎng)站的服務(wù)商將自己的網(wǎng)站服務(wù)封裝成 一系列API (Application Programming Interface,應(yīng)用編程接口)開放出去,供應(yīng)用客戶 端的開發(fā)者使用,所開放的API就被稱作OpenAPI。應(yīng)用客戶端獲取到授權(quán)訪問令牌后,即 可通過訪問令牌調(diào)用平臺方提供的OpenAPI接口來獲取相應(yīng)的云能力和用戶數(shù)據(jù)。
[0190] 由于在用戶觸發(fā)手機號一鍵授權(quán)請求后,整個過程都不會出現(xiàn)任何其他的用戶界 面,因此,如果有多個平臺都支持該技術(shù),則應(yīng)用客戶端就可以通過多次接口調(diào)用的方式來 完成每個平臺的授權(quán)訪問令牌的獲取,從而解決前面提到的第四方面的問題。
[0191] 本發(fā)明實施例還提供了一種平臺授權(quán)系統(tǒng),包括:本發(fā)明任意實施例所提供的平 臺服務(wù)端和本發(fā)明任意實施例所提供的應(yīng)用客戶端。
[0192] 以上實施例提供的技術(shù)方案中的全部或部分內(nèi)容可以通過軟件編程實現(xiàn),其軟件 程序存儲在可讀取的存儲介質(zhì)中,存儲介質(zhì)例如:計算機中的硬盤、光盤或軟盤。
[0193] 注意,上述僅為本發(fā)明的較佳實施例及所運用技術(shù)原理。本領(lǐng)域技術(shù)人員會理解, 本發(fā)明不限于這里所述的特定實施例,對本領(lǐng)域技術(shù)人員來說能夠進行各種明顯的變化、 重新調(diào)整和替代而不會脫離本發(fā)明的保護范圍。因此,雖然通過以上實施例對本發(fā)明進行 了較為詳細的說明,但是本發(fā)明不僅僅限于以上實施例,在不脫離本發(fā)明構(gòu)思的情況下,還 可以包括更多其他等效實施例,而本發(fā)明的范圍由所附的權(quán)利要求范圍決定。
【權(quán)利要求】
1. 一種平臺服務(wù)端的平臺授權(quán)方法,其特征在于,包括: 平臺服務(wù)端接收應(yīng)用客戶端通過第一路徑發(fā)送的第一驗證消息并獲取所述應(yīng)用客戶 端的客戶端標識; 所述平臺服務(wù)端對所接收的第一驗證消息與所述客戶端標識之間的映射關(guān)系進行記 錄; 所述平臺服務(wù)端接收所述應(yīng)用客戶端通過第二路徑發(fā)送的第二驗證消息; 如果所述平臺服務(wù)端驗證所述第一驗證消息和第二驗證消息匹配,則根據(jù)所述第一驗 證消息從所記錄的所述映射關(guān)系中提取所述客戶端標識,并根據(jù)所述客戶端標識生成授權(quán) 訪問令牌,發(fā)送給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端。
2. 根據(jù)權(quán)利要求1所述的方法,其特征在于,所述平臺服務(wù)端接收所述應(yīng)用客戶端通 過第二路徑發(fā)送的第二驗證消息包括: 所述平臺服務(wù)端接收所述應(yīng)用客戶端通過應(yīng)用服務(wù)端轉(zhuǎn)發(fā)的第二驗證消息。
3. 根據(jù)權(quán)利要求2所述的方法,其特征在于: 所述第一驗證消息包括隨機字符串,所述第二驗證消息包括所述隨機字符串和身份認 證信息; 則所述平臺服務(wù)端驗證所述第一驗證消息和第二驗證消息匹配包括:所述平臺服務(wù)端 驗證所述第一驗證消息和第二驗證消息中的隨機字符串一致。
4. 根據(jù)權(quán)利要求3所述的方法,其特征在于,所述客戶端標識為所述客戶端所在終端 的終端標識,則根據(jù)所述客戶端標識生成授權(quán)訪問令牌,發(fā)送給所述應(yīng)用客戶端和/或應(yīng) 用服務(wù)端包括: 所述平臺服務(wù)端根據(jù)所述終端標識獲取對應(yīng)的用戶賬號信息; 所述平臺服務(wù)端根據(jù)所述用戶賬號信息和所述身份認證信息生成授權(quán)訪問令牌,發(fā)送 給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端。
5. 根據(jù)權(quán)利要求4所述的方法,其特征在于,平臺服務(wù)端接收應(yīng)用客戶端通過第一路 徑發(fā)送的第一驗證消息并獲取所述應(yīng)用客戶端所在終端的終端標識包括: 所述平臺服務(wù)端接收所述應(yīng)用客戶端通過短信網(wǎng)關(guān)轉(zhuǎn)發(fā)的第一驗證消息,其中,所述 第一驗證消息為所述短信網(wǎng)關(guān)根據(jù)所述應(yīng)用客戶端發(fā)送的驗證短信進行協(xié)議格式轉(zhuǎn)換后 的消息,所述驗證短信中攜帶有所述隨機字符串; 所述平臺服務(wù)端從所述第一驗證消息中獲取所述應(yīng)用客戶端所在終端的終端標識,所 述終端標識為所述短信網(wǎng)關(guān)從所述驗證短信中提取的短信發(fā)起方終端標識。
6. 根據(jù)權(quán)利要求4所述的方法,其特征在于:所述第二驗證消息通過第二路徑轉(zhuǎn)發(fā),所 述第二路徑為基于安全超文本傳輸協(xié)議HTTPS發(fā)送的HTTPS請求。
7. 根據(jù)權(quán)利要求4所述的方法,其特征在于,在所述平臺服務(wù)端根據(jù)所述隨機字符串 從所記錄的所述映射關(guān)系中提取所述終端標識之前,還包括: 如果所述平臺服務(wù)器驗證所述身份認證信息為有效,則觸發(fā)后續(xù)操作。
8. 根據(jù)權(quán)利要求4所述的方法,其特征在于,所述第二驗證消息還包括所述應(yīng)用客戶 端提供的期望數(shù)據(jù)訪問權(quán)限列表; 所述平臺服務(wù)端根據(jù)所述用戶賬號信息和所述身份認證信息生成授權(quán)訪問令牌包 括: 所述平臺服務(wù)端根據(jù)所述用戶賬號信息、所述身份認證信息和所述期望數(shù)據(jù)訪問權(quán)限 列表生成授權(quán)訪問令牌。
9. 根據(jù)權(quán)利要求4-8任一所述的方法,其特征在于,所述身份認證信息包括包名和包 簽名。
10. -種應(yīng)用客戶端的平臺授權(quán)方法,其特征在于,包括: 應(yīng)用客戶端通過第一路徑向平臺服務(wù)端發(fā)送第一驗證消息,以供所述平臺服務(wù)端對所 述第一驗證消息與所述應(yīng)用客戶端的客戶端標識之間的映射關(guān)系進行記錄; 應(yīng)用客戶端通過第二路徑向所述平臺服務(wù)端轉(zhuǎn)發(fā)第二驗證消息,以供如果所述平臺服 務(wù)端驗證所述第一驗證消息和第二驗證消息匹配,則根據(jù)所述第一驗證消息從所記錄的所 述映射關(guān)系中提取所述客戶端標識,并根據(jù)所述客戶端標識生成授權(quán)訪問令牌,發(fā)送給所 述應(yīng)用客戶端和/或應(yīng)用服務(wù)端; 應(yīng)用客戶端接收所述平臺服務(wù)端發(fā)送的授權(quán)訪問令牌。
11. 根據(jù)權(quán)利要求10所述的方法,其特征在于,應(yīng)用客戶端通過第二路徑向所述平臺 服務(wù)端轉(zhuǎn)發(fā)第二驗證消息包括: 應(yīng)用客戶端通過應(yīng)用服務(wù)端向所述平臺服務(wù)端轉(zhuǎn)發(fā)第二驗證消息。
12. 根據(jù)權(quán)利要求11所述的方法,其特征在于: 所述第一驗證消息包括隨機字符串,所述第二驗證消息包括所述隨機字符串和身份認 證信息。
13. 根據(jù)權(quán)利要求12所述的方法,其特征在于,所述客戶端標識為所述應(yīng)用客戶端所 在終端的終端標識。
14. 根據(jù)權(quán)利要求13所述的方法,其特征在于,應(yīng)用客戶端通過第一路徑向平臺服務(wù) 端發(fā)送第一驗證消息包括: 所述應(yīng)用客戶端生成隨機字符串,并創(chuàng)建包含所述隨機字符串且目的地址為所述平臺 服務(wù)端的驗證短信; 所述應(yīng)用客戶端發(fā)送所述驗證短信至短信網(wǎng)關(guān),以指示所述短信網(wǎng)關(guān)將所述驗證短信 進行協(xié)議轉(zhuǎn)換并提取所述驗證短信的短信發(fā)起方終端標識,生成包含所述隨機字符串的第 一驗證消息,向所述平臺服務(wù)端發(fā)送。
15. 根據(jù)權(quán)利要求13所述的方法,其特征在于,應(yīng)用客戶端通過應(yīng)用服務(wù)端向所述平 臺服務(wù)端轉(zhuǎn)發(fā)第二驗證消息包括: 所述應(yīng)用客戶端將所述隨機字符串發(fā)送給所述應(yīng)用服務(wù)端,以指示所述應(yīng)用服務(wù)端將 所述隨機字符串和身份認證信息攜帶在第二驗證消息中向平臺服務(wù)端發(fā)送,所述第二驗證 消息為基于安全超文本傳輸協(xié)議HTTPS發(fā)送的HTTPS請求。
16. 根據(jù)權(quán)利要求13所述的方法,其特征在于,應(yīng)用客戶端通過應(yīng)用服務(wù)端向所述平 臺服務(wù)端轉(zhuǎn)發(fā)第二驗證消息包括: 應(yīng)用客戶端在發(fā)送所述第一驗證消息的同時或發(fā)送所述第一驗證消息成功之后,通過 應(yīng)用服務(wù)端向所述平臺服務(wù)端轉(zhuǎn)發(fā)第二驗證消息。
17. -種平臺授權(quán)方法,其特征在于,包括: 應(yīng)用客戶端通過第一路徑向平臺服務(wù)端發(fā)送第一驗證消息; 平臺服務(wù)端接收應(yīng)用客戶端通過第一路徑發(fā)送的第一驗證消息并獲取所述應(yīng)用客戶 端的客戶端標識; 所述平臺服務(wù)端對所接收的第一驗證消息與所述客戶端標識之間的映射關(guān)系進行記 錄; 應(yīng)用客戶端通過第二路徑向所述平臺服務(wù)端轉(zhuǎn)發(fā)第二驗證消息; 所述平臺服務(wù)端接收所述應(yīng)用客戶端通過第二路徑發(fā)送的第二驗證消息; 如果所述平臺服務(wù)端驗證所述第一驗證消息和第二驗證消息匹配,則根據(jù)所述第一驗 證消息從所記錄的所述映射關(guān)系中提取所述客戶端標識,并根據(jù)所述客戶端標識生成授權(quán) 訪問令牌,發(fā)送給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端; 應(yīng)用客戶端接收所述平臺服務(wù)端和/或應(yīng)用服務(wù)端發(fā)送的授權(quán)訪問令牌。
18. 根據(jù)權(quán)利要求17所述的方法,其特征在于: 所述第二路徑為通過應(yīng)用服務(wù)端轉(zhuǎn)發(fā); 所述第一驗證消息包括隨機字符串,所述第二驗證消息包括所述隨機字符串和身份認 證信息; 所述客戶端標識為所述客戶端所在終端的終端標識。
19. 一種平臺服務(wù)端,其特征在于,包括: 第一驗證消息接收單元,用于接收應(yīng)用客戶端通過第一路徑發(fā)送的第一驗證消息并獲 取所述應(yīng)用客戶端的客戶端標識; 映射關(guān)系記錄單元,用于對所接收的第一驗證消息與所述客戶端標識之間的映射關(guān)系 進行記錄; 第二驗證消息接收單元,用于接收所述應(yīng)用客戶端通過第二路徑發(fā)送的第二驗證消 息; 驗證與授權(quán)單元,用于如果驗證所述第一驗證消息和第二驗證消息匹配,則根據(jù)所述 第一驗證消息從所記錄的所述映射關(guān)系中提取所述客戶端標識,并根據(jù)所述客戶端標識生 成授權(quán)訪問令牌,發(fā)送給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端。
20. 根據(jù)權(quán)利要求19所述的平臺服務(wù)端,其特征在于,所述第二驗證消息接收單元具 體用于: 接收所述應(yīng)用客戶端通過應(yīng)用服務(wù)端轉(zhuǎn)發(fā)的第二驗證消息。
21. 根據(jù)權(quán)利要求20所述的平臺服務(wù)端,其特征在于: 所述第一驗證消息包括隨機字符串,所述第二驗證消息包括所述隨機字符串和身份認 證信息; 所述驗證與授權(quán)單元具體用于:驗證所述第一驗證消息和第二驗證消息中的隨機字符 串一致。
22. 根據(jù)權(quán)利要求21所述的平臺服務(wù)端,其特征在于,所述客戶端標識為所述客戶端 所在終端的終端標識,則所述驗證與授權(quán)單元具體用于: 根據(jù)所述終端標識獲取對應(yīng)的用戶賬號信息; 根據(jù)所述用戶賬號信息和所述身份認證信息生成授權(quán)訪問令牌,發(fā)送給所述應(yīng)用客戶 端和/或應(yīng)用服務(wù)端。
23. 根據(jù)權(quán)利要求22所述的平臺服務(wù)端,其特征在于,所述第一驗證消息接收單元具 體用于: 接收所述應(yīng)用客戶端通過短信網(wǎng)關(guān)轉(zhuǎn)發(fā)的第一驗證消息,其中,所述第一驗證消息為 所述短信網(wǎng)關(guān)根據(jù)所述應(yīng)用客戶端發(fā)送的驗證短信進行協(xié)議格式轉(zhuǎn)換后的消息,所述驗證 短信中攜帶有所述隨機字符串; 從所述第一驗證消息中獲取所述應(yīng)用客戶端所在終端的終端標識,所述終端標識為所 述短信網(wǎng)關(guān)從所述驗證短信中提取的短信發(fā)起方終端標識。
24. 根據(jù)權(quán)利要求22所述的平臺服務(wù)端,其特征在于:所述第二驗證消息通過第二路 徑轉(zhuǎn)發(fā),所述第二路徑為基于安全超文本傳輸協(xié)議HTTPS發(fā)送的HTTPS請求;和/或 所述第二驗證消息還包括所述應(yīng)用客戶端提供的期望數(shù)據(jù)訪問權(quán)限列表;和/或 所述身份認證信息包括包名和包簽名;和/或 所述終端的標識為手機號。
25. -種應(yīng)用客戶端,其特征在于,包括: 第一驗證消息發(fā)送單元,用于通過第一路徑向平臺服務(wù)端發(fā)送第一驗證消息,以供所 述平臺服務(wù)端對所述第一驗證消息與所述應(yīng)用客戶端的客戶端標識之間的映射關(guān)系進行 記錄; 第二驗證消息發(fā)送單元,用于通過第二路徑向所述平臺服務(wù)端轉(zhuǎn)發(fā)第二驗證消息,以 供如果所述平臺服務(wù)端驗證所述第一驗證消息和第二驗證消息匹配,則根據(jù)所述第一驗證 消息從所記錄的所述映射關(guān)系中提取所述客戶端標識,并根據(jù)所述客戶端標識生成授權(quán)訪 問令牌,發(fā)送給所述應(yīng)用客戶端和/或應(yīng)用服務(wù)端; 授權(quán)訪問令牌接收單元,用于接收所述平臺服務(wù)端發(fā)送的授權(quán)訪問令牌。
26. 根據(jù)權(quán)利要求25所述的應(yīng)用客戶端,其特征在于,所述第二驗證消息發(fā)送單元具 體用于: 通過應(yīng)用服務(wù)端向所述平臺服務(wù)端轉(zhuǎn)發(fā)第二驗證消息。
27. 根據(jù)權(quán)利要求26所述的應(yīng)用客戶端,其特征在于: 所述第一驗證消息包括隨機字符串,所述第二驗證消息包括所述隨機字符串和身份認 證信息。
28. 根據(jù)權(quán)利要求27所述的應(yīng)用客戶端,其特征在于,所述客戶端標識為所述應(yīng)用客 戶端所在終端的終端標識。
29. 根據(jù)權(quán)利要求28所述的應(yīng)用客戶端,其特征在于,所述第一驗證消息發(fā)送單元具 體用于: 生成隨機字符串,并創(chuàng)建包含所述隨機字符串且目的地址為所述平臺服務(wù)端的驗證短 信; 發(fā)送所述驗證短信至短信網(wǎng)關(guān),以指示所述短信網(wǎng)關(guān)將所述驗證短信進行協(xié)議轉(zhuǎn)換并 提取所述驗證短信的短信發(fā)起方終端標識,生成包含所述隨機字符串的第一驗證消息,向 所述平臺服務(wù)端發(fā)送。
30. 根據(jù)權(quán)利要求28所述的應(yīng)用客戶端,其特征在于,所述第二驗證消息發(fā)送單元具 體用于: 將所述隨機字符串發(fā)送給所述應(yīng)用服務(wù)端,以指示所述應(yīng)用服務(wù)端將所述隨機字符串 和身份認證信息攜帶在第二驗證消息中向平臺服務(wù)端發(fā)送,所述第二驗證消息為基于安全 超文本傳輸協(xié)議HTTPS發(fā)送的HTTPS請求。
31. 根據(jù)權(quán)利要求28所述的應(yīng)用客戶端,其特征在于,所述第二驗證消息發(fā)送單元具 體用于: 在發(fā)送所述第一驗證消息的同時或發(fā)送所述第一驗證消息成功之后,通過應(yīng)用服務(wù)端 向所述平臺服務(wù)端轉(zhuǎn)發(fā)第二驗證消息。
32. -種平臺授權(quán)系統(tǒng),其特征在于,包括: 權(quán)利要求19-24任一所述的平臺服務(wù)端和權(quán)利要求25-31任一所述的應(yīng)用客戶端。
【文檔編號】H04L29/06GK104113549SQ201410363395
【公開日】2014年10月22日 申請日期:2014年7月28日 優(yōu)先權(quán)日:2014年7月28日
【發(fā)明者】朱建庭, 鄭偉德, 張弛 申請人:百度在線網(wǎng)絡(luò)技術(shù)(北京)有限公司
網(wǎng)友詢問留言 已有0條留言
  • 還沒有人留言評論。精彩留言會獲得點贊!
1
主站蜘蛛池模板: 普兰店市| 东山县| 宁国市| 会泽县| 民乐县| 乌鲁木齐县| 奉新县| 深州市| 永胜县| 上杭县| 常宁市| 深水埗区| 浙江省| 定结县| 东兴市| 高安市| 科技| 太和县| 边坝县| 武乡县| 金溪县| 县级市| 五原县| 林州市| 都江堰市| 剑河县| 玉龙| 依安县| 宿州市| 玉环县| 瑞金市| 廉江市| 六枝特区| 瑞丽市| 喀什市| 西青区| 高淳县| 四会市| 宁阳县| 永定县| 霸州市|