云调用，小程序鉴权正确姿势
目錄：
一、無處不在的鑒權(quán)
? ?1. 現(xiàn)實(shí)生活中的身份鑒權(quán)方法
? ?2. 簡單的密碼鑒權(quán)體系
二、鑒權(quán)優(yōu)化
? ?1. 頻繁的鑒權(quán)場景下的優(yōu)化方案
? ?2. 第三方鑒權(quán)體現(xiàn)下的設(shè)計(jì)——oAuth 2.0鑒權(quán)體系
三、說了這么多廣而全的鑒權(quán)方式，我們看看小程序開發(fā)中的鑒權(quán)是如何實(shí)現(xiàn)的
? ?1. 小程序服務(wù)端接口的鑒權(quán)方式
? ?2. 簡化版的 OAuth 2.0
? ?3. 鑒權(quán)是否可以優(yōu)化
四、云調(diào)用免鑒權(quán)體系
五、未來鑒權(quán)暢想
互聯(lián)網(wǎng)的應(yīng)用，大大小小，不同場景，都離不開鑒權(quán)，從簡單的可被用戶感知的登陸鑒權(quán)，到技術(shù)側(cè)不被感知的各種技術(shù)參數(shù)鑒權(quán)，都有著形形色色的鑒權(quán)方式和表現(xiàn)形式。
那么，什么是鑒權(quán)？
其實(shí)，從本質(zhì)上來講，鑒權(quán)就是要證明你就是你，你可以做哪些事情。
鑒權(quán)分為兩部分，一部分是鑒別身份，一部分是確定權(quán)力。
而現(xiàn)代網(wǎng)絡(luò)設(shè)計(jì)中，權(quán)力的分配一般都是預(yù)先分配好的，在鑒別身份之后，拿著身份信息，去權(quán)限中心確定權(quán)力范圍。這樣就完成了用戶的鑒權(quán)過程。
1.現(xiàn)實(shí)生活中的身份鑒權(quán)方法
身份證?是現(xiàn)代社會(huì)用于鑒別身份的一種方式。
說起身份證，?據(jù)相關(guān)史實(shí)考證，我國的身份證最早出現(xiàn)在戰(zhàn)國時(shí)期，商鞅在秦國變法，發(fā)明了「照身帖」。照身帖由官府發(fā)放，是一塊打磨光滑細(xì)密的竹板，上面刻著持有人的頭像和籍貫信息。國人必須持有，?如若沒有，就被認(rèn)為是黑戶或者間諜之類。這可能是身份證的雛形。
在隋唐時(shí)期，我國出現(xiàn)了最早的“身份證”，當(dāng)時(shí)的朝廷發(fā)給官員一種類似身份證的“魚符”，是用木頭或者金屬所作，形狀像魚，分左右兩片，上有小孔，并可有官員姓名、任職衙門、官員品級等。那時(shí)，凡親王、三品以上官員“魚符”用黃金制作；五品以上用白銀；六品以下為銅制。五品以上官員，還備有存放魚符的專用袋子，稱為“魚袋”。
從秦朝到清朝的這個(gè)階段，出現(xiàn)的這些身份標(biāo)識(shí)，盡管形式多樣，但總體來說，都是屬于「身份證明」這一范疇。然而，這樣的「身份證」在核驗(yàn)其身份的真實(shí)性方面，只能憑眼看，造假很容易蒙混過關(guān)，沒有人能真正證明其真實(shí)性。這種核驗(yàn)身份方法是最初級最原始的方法，是現(xiàn)代身份證雛形的階段。
而身份證這種鑒權(quán)方式猶如密碼鑒權(quán)一樣，屬于一種?令牌鑒權(quán)方式。
令牌要么被私有不公開，要么很難偽造。
同樣，在武俠小說中的令牌，也是如此。最近熱播的「倚天屠龍記」中，明教的「圣火令」——?見之如見教主。「圣火令」就是令牌的一種方式，是一種固定的密鑰鑒權(quán)方式。
2.簡單的密碼鑒權(quán)體系
『我這有一把鎖，我把鑰匙發(fā)給你，你使用資源的時(shí)候過來開鎖使用就好了。』可以形象的比喻現(xiàn)代互聯(lián)網(wǎng)中使用的密碼鑒權(quán)體系。資源管理者只信任密碼憑證，無論誰持有了密碼，都可以使用對應(yīng)的權(quán)利資源。比如，不管誰持有圣火令，都可以使用明教教主的權(quán)利資源。
密鑰鑒權(quán)體系的特點(diǎn)：
1.簡單 2.密碼成本，不公開或偽造有門檻
1.頻繁的鑒權(quán)場景下的優(yōu)化方案
想象一種場景，持有圣火令的教主，每次施號發(fā)令，都要將圣火令從自己藏的密道中取出來才能發(fā)令。那么，如果自己心愛的人正在被屠殺，取個(gè)圣火令回來可能人就沒了，所以，這里應(yīng)該是有一個(gè)簡單的方式來優(yōu)化這一過程。
互聯(lián)網(wǎng)密碼鑒權(quán)體系中，常常在通過身份驗(yàn)證后，將通過認(rèn)證的信息保持一段時(shí)間，同樣，實(shí)際武俠江湖中，大家都是有記憶的，圣火令持有者亮出圣火令的一段時(shí)間后，看到的人就能記下他已經(jīng)是圣火令的持有者了，下次發(fā)號施令，就不必取來圣火令了。
在web認(rèn)證體系下，http協(xié)議是一種無狀態(tài)的協(xié)議，用戶通過輸入密碼后獲得身份認(rèn)證，這種狀態(tài)是無法保持下來的，為了保持這種狀態(tài)，客戶端和服務(wù)端可以一起想辦法把鑒權(quán)狀態(tài)保留一段時(shí)間。比如，客戶端可以記下用戶的密碼，下次只需要把密碼自動(dòng)帶入到服務(wù)端即可。但這種方式是極為不安全的，客戶端和傳輸端的可能泄漏密碼。為了避免這種風(fēng)險(xiǎn)的發(fā)生，客戶端和服務(wù)端通過其他的約定來保持這種狀態(tài)，比如，通過一種臨時(shí)密碼來降低這種風(fēng)險(xiǎn)發(fā)生的危害，這種臨時(shí)規(guī)則可以是session?+?cookie，也可以是token等等。
2.第三方鑒權(quán)體現(xiàn)下的設(shè)計(jì)——oAuth 2.0鑒權(quán)體系
密碼鑒權(quán)體系一般都是發(fā)生在兩方之間的鑒權(quán)方案。但是回歸到武俠世界中，如果一個(gè)人拿了偽造的圣火令來發(fā)號施令，那豈不是對明教的危害很大？怎么解決這個(gè)問題？這就需要一個(gè)可以被信任的人，能夠先甄別圣火令的真假，然后其他的人信任這個(gè)人，最終完成身份的驗(yàn)證。
所以這就引入了一個(gè)可信任的第三方代為鑒別令牌的，然后告知鑒別結(jié)果。比如，第三方登錄場景下，?平臺(tái)需要第三方平臺(tái)代為身份驗(yàn)證后告知平臺(tái)此人的身份是什么。這就是我們常見到的oAuth鑒權(quán)，現(xiàn)在被廣泛應(yīng)用再第三方登陸平臺(tái)中，比如微信登陸、QQ登陸等等。
oAuth?2.0分為客戶端鑒權(quán)和服務(wù)器端鑒權(quán)兩種方式。拿比較常見的qq登陸來舉例，第三方平臺(tái)需要在QQ互聯(lián)平臺(tái)申請一個(gè)appid，互聯(lián)平臺(tái)同時(shí)會(huì)分配一個(gè)私密的appkey（密鑰，始終不公開）。
1.以web版?服務(wù)端oAuth鑒權(quán)方式舉例:1.用戶:?點(diǎn)擊使用QQ登陸按鈕（平臺(tái)方頁面） 2.瀏覽器：?跳轉(zhuǎn)到QQ互聯(lián)登陸頁面（第三方平臺(tái)頁面)?????
url參數(shù)：平臺(tái)方appid和平臺(tái)方回調(diào)地址（用于接收第三方的校驗(yàn)信息）
第三方平臺(tái)會(huì)校驗(yàn)appid和回調(diào)地址對應(yīng)情況
3.瀏覽器：?用戶和第三方平臺(tái)鑒權(quán)（第三方平臺(tái)） 4.瀏覽器：?第三方平臺(tái)跳回回調(diào)頁面（平臺(tái)方）
url參數(shù)：?第三方平臺(tái)頒發(fā)的臨時(shí)token
5.服務(wù)器：第三方通過token加appkey來獲取用戶信息（服務(wù)端發(fā)起，避免appkey暴露）
通過上述過程完成了第三方平臺(tái)的鑒權(quán)，獲取到了第三方平臺(tái)提供的臨時(shí)密鑰token，平臺(tái)之后就可以通過這些信息向第三方索取更多的數(shù)據(jù)和權(quán)力，比如獲取用戶的openid和基本信息等等。
1.小程序服務(wù)端接口的鑒權(quán)方式
有過小程序開發(fā)經(jīng)驗(yàn)的開發(fā)者，都會(huì)或多或少地用上小程序的開放能力，其中為數(shù)不少的能力是通過服務(wù)端?API?接口的方式提供給廣大的開發(fā)者。比如，我們常用來發(fā)送通知用戶給用戶的模板消息能力：
然后如果你查閱這些開放的服務(wù)端?API?，會(huì)發(fā)現(xiàn)幾乎每個(gè)?API?都需要填一個(gè)參數(shù)，那就是?access_token。這個(gè)參數(shù)主要是用于微信側(cè)的服務(wù)器鑒權(quán)。微信側(cè)的服務(wù)器拿到?access_token?后，就會(huì)知道該小程序有沒有權(quán)限可以替用戶進(jìn)行開放能力的操作。
那么，這個(gè)參數(shù)是怎么獲取的呢？
它是通過一個(gè)?auth.getAccessToken?的接口來獲取的，它具體的入?yún)⒊鰠⑷缦?#xff1a;
2.簡化版的 OAuth 2.0
這種調(diào)用方式，基本上的思路跟?OAuth?2.0?的客戶端模式很類似。OAuth?2.0?比較完整的模型如下圖：
上圖有一些主體概念，我們以微信小程序這個(gè)場景來解釋一下：
Client?表示當(dāng)前正在開發(fā)的這個(gè)小程序。
Resource Owner 表示微信官方服務(wù)端開放能力的數(shù)據(jù)及資源的擁有者，
Authorization Server 表示調(diào)微信官方的鑒權(quán)服務(wù)
Resource Server 表示微信官方存放開放能力數(shù)據(jù)及資源的服務(wù)器
實(shí)際上，微信將這個(gè)流程簡化成下圖，具體的步驟是：
(A) 小程序帶上 appid 和 secret 向 Authorization Server 申請鑒權(quán)及獲取令牌
(B) Authorization Server 確認(rèn) appid 和 secret 密鑰對無誤后，會(huì)返回一個(gè)臨時(shí)密鑰 Access Token （一般是2小時(shí)）
(C) 帶上 Access Token，就可以向 Resource Server 發(fā)請求，申請操作開放數(shù)據(jù)及資源
(D) Resource Server 返回?cái)?shù)據(jù)或操作結(jié)果
其中步驟?A?里，?granttype?表示授權(quán)類型，小程序這里的固定值是clientcredentials。外面有的服務(wù)還需要填一個(gè)?scope?字段，表示?AccessToken?的適用獲圍，這里則省略了，表示適用所有的服務(wù)端?API。
基于這種?OAuth?2.0?的開發(fā)模式，很多公司都會(huì)多搭建一個(gè)中間服務(wù)層，或者直接用中間件，去獲取類似?AccessToken?這種跟小程序相關(guān)的信息，因?yàn)檫@個(gè)令牌是有一定時(shí)效性，而且每天都有接口調(diào)用的限制，因此不可能每個(gè)用戶操作的時(shí)候，都調(diào)用接口獲取新的?AccessToken。
這種開發(fā)模式有一定的局限性，那就是在開發(fā)微信相關(guān)業(yè)務(wù)的時(shí)候，需要額外部署緩存或數(shù)據(jù)服務(wù)，而存儲(chǔ)的數(shù)據(jù)量其實(shí)很少，造成了資源的浪費(fèi)和抬高了維護(hù)成本。
3.鑒權(quán)是否可以優(yōu)化
安全性與便利性就像一對互有恩怨情仇的俠侶，總是無法很好地調(diào)和。如果希望系統(tǒng)更安全，多設(shè)幾道防御屏障，用加密級數(shù)更高的算法，那便利性、性能等方面就會(huì)承受一定的折損。而如果想用戶更方便，少設(shè)幾道安全關(guān)卡，那安全方面自然就會(huì)大打折扣。
因此，如果需要自己搭建一套微信小程序的服務(wù)，首先微信開放平臺(tái)的鑒權(quán)服務(wù)是自然跑不掉的，需要按照文檔規(guī)范逐一落實(shí)。而這套服務(wù)跟小程序前端的鑒權(quán)，也自然是個(gè)棘手的問題。簡單一點(diǎn)的，用?JWT?(JSON?Web?Token)?實(shí)現(xiàn)去中心化的鑒權(quán)，缺點(diǎn)是無法保證用戶端的泄漏風(fēng)險(xiǎn)以及過期時(shí)間。而高級一點(diǎn)的是自己維護(hù)一套有過期時(shí)間的中心化?Cookie/Session?體系，看起來是安全些，但對服務(wù)的平行擴(kuò)容卻又并不太友好。
這樣看來，真的沒有既安全，又便利的小程序鑒權(quán)服務(wù)體系了嗎？
小程序最近推出的云調(diào)用能力，則是對原有的這種鑒權(quán)模式的巨大優(yōu)化。
官方對云調(diào)用的描述是這樣的：
云調(diào)用是云開發(fā)提供的基于云函數(shù)使用小程序開放接口的能力。云調(diào)用需要在云函數(shù)中通過?wx-server-sdk?使用。在云函數(shù)中使用云調(diào)用調(diào)用服務(wù)端接口無需換取?access_token，只要是在從小程序端觸發(fā)的云函數(shù)中發(fā)起的云調(diào)用都經(jīng)過微信自動(dòng)鑒權(quán)，可以在登記權(quán)限后直接調(diào)用如發(fā)送模板消息等開放接口。
主要是有幾個(gè)關(guān)鍵點(diǎn)：
基于?小程序·云開發(fā)?開發(fā)的云函數(shù)能力
通過?wx-server-sdk?才能調(diào)用
只有在小程序前端側(cè)調(diào)用云函數(shù)，才能這樣的能力
我們來看一下云調(diào)用如何在云函數(shù)中發(fā)送模板消息。
從這個(gè)例子看出，其實(shí)入?yún)⒉o差異，只是不需要再去獲取?access_token。那意味著整個(gè)開發(fā)的架構(gòu)，可以簡化成這樣，架構(gòu)的復(fù)雜度大大降低：
那目前有哪些的小程序使用場景可以用上云調(diào)用呢？統(tǒng)計(jì)了一下，主要用戶信息獲取、訪問留存、消息(模板、統(tǒng)一服務(wù)、動(dòng)態(tài))、小程序碼、內(nèi)容安全等十幾個(gè)大類幾十個(gè)開放接口已經(jīng)支持云調(diào)用。具體可以參考小程序服務(wù)端接口列表，如果接口旁邊有一個(gè)"云調(diào)用"的標(biāo)簽，表明該接口支持云調(diào)用。
但總得來說，這種使用方式已經(jīng)給小程序開發(fā)效率的提高，帶來了質(zhì)的飛躍。
總之，鑒權(quán)場景從古至今都是一個(gè)高頻場景，從古代的魚符號，現(xiàn)代的身份證，都是一種令牌憑證的鑒權(quán)方式，到了線上的系統(tǒng)中，大部分場景也是基于密碼鑒權(quán)體系，除此之外，基于生物特征的鑒權(quán)，比如基于指紋、基于面容ID等等也都在廣泛使用起來。
第三方鑒權(quán)體系也隨著各大平臺(tái)的開放而逐漸發(fā)展起來，單看小程序體系下鑒權(quán)也是無處不在，小程序云開發(fā)推出了免鑒權(quán)體系，為小程序的開發(fā)帶來了極大的方便。
更進(jìn)一步，未來是否可以有一種不基于密碼的授權(quán)方式？比如基于機(jī)器學(xué)習(xí)和區(qū)塊鏈模式下的鑒權(quán)，區(qū)塊鏈的信任是去中心化的一種實(shí)現(xiàn)方式，未來的鑒權(quán)能否也可以做到去中心化的鑒權(quán)？
那么，在你心中，未來的鑒權(quán)方式應(yīng)該是什么樣的呢？
活動(dòng)推薦：騰訊TEG與CCF（中國計(jì)算機(jī)協(xié)會(huì)）合辦的騰訊技術(shù)工程沙龍“走進(jìn)工業(yè)互聯(lián)網(wǎng)”將在4月14日（周日）舉辦啦！掃碼即可報(bào)名~
總結(jié)
以上是生活随笔為你收集整理的云调用，小程序鉴权正确姿势的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： MemSQL可以为时间序列应用做些什么
- 下一篇： 邀您参加 | K8S云原生技术开放日-北