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