雲調用，小程序鑑權正確姿式

目錄： 1、無處不在的鑑權    1. 現實生活中的身份鑑權方法    2. 簡單的密碼鑑權體系 2、鑑權優化    1. 頻繁的鑑權場景下的優化方案    2. 第三方鑑權體現下的設計——oAuth 2.0鑑權體系 3、說了這麼多廣而全的鑑權方式，咱們看看小程序開發中的鑑權是如何實現的    1. 小程序服務端接口的鑑權方式    2. 簡化版的 OAuth 2.0    3. 鑑權是否能夠優化 4、雲調用免鑑權體系 5、將來鑑權暢想

互聯網的應用，大大小小，不一樣場景，都離不開鑑權，從簡單的可被用戶感知的登錄鑑權，到技術側不被感知的各類技術參數鑑權，都有着形形色色的鑑權方式和表現形式。

那麼，什麼是鑑權？

其實，從本質上來說，鑑權就是要證實你就是你，你能夠作哪些事情。

鑑權分爲兩部分，一部分是鑑別身份，一部分是肯定權力。 而現代網絡設計中，權力的分配通常都是預先分配好的，在鑑別身份以後，拿着身份信息，去權限中心肯定權力範圍。這樣就完成了用戶的鑑權過程。

1、無處不在的鑑權

1.現實生活中的身份鑑權方法

身份證 是現代社會用於鑑別身份的一種方式。

提及身份證， 據相關史實考證，我國的身份證最先出如今戰國時期，商鞅在秦國變法，發明了「照身帖」。照身帖由官府發放，是一塊打磨光滑細密的竹板，上面刻着持有人的頭像和籍貫信息。國人必須持有， 如若沒有，就被認爲是黑戶或者間諜之類。這多是身份證的雛形。

在隋唐時期，我國出現了最先的「身份證」，當時的朝廷發給官員一種相似身份證的「魚符」，是用木頭或者金屬所做，形狀像魚，分左右兩片，上有小孔，並可有官員姓名、任職衙門、官員品級等。那時，凡親王、三品以上官員「魚符」用黃金製做；五品以上用白銀；六品如下爲銅製。五品以上官員，還備有存放魚符的專用袋子，稱爲「魚袋」。

從秦朝到清朝的這個階段，出現的這些身份標識，儘管形式多樣，但整體來講，都是屬於「身份證實」這一範疇。然而，這樣的「身份證」在覈驗其身份的真實性方面，只能憑眼看，造假很容易矇混過關，沒有人能真正證實其真實性。這種覈驗身份方法是最初級最原始的方法，是現代身份證雛形的階段。

而身份證這種鑑權方式猶如密碼鑑權同樣，屬於一種 令牌鑑權方式。

令牌要麼被私有不公開，要麼很難僞造。

一樣，在武俠小說中的令牌，也是如此。最近熱播的「倚天屠龍記」中，明教的「聖火令」—— 見之如見教主。「聖火令」就是令牌的一種方式，是一種固定的密鑰鑑權方式。

2.簡單的密碼鑑權體系

『我這有一把鎖，我把鑰匙發給你，你使用資源的時候過來開鎖使用就行了。』能夠形象的比喻現代互聯網中使用的密碼鑑權體系。資源管理者只信任密碼憑證，不管誰持有了密碼，均可以使用對應的權利資源。好比，無論誰持有聖火令，均可以使用明教教主的權利資源。

密鑰鑑權體系的特色： 1.簡單 2.密碼成本，不公開或僞造有門檻

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和基本信息等等。

3、說了這麼多廣而全的鑑權方式，咱們看看小程序開發中的鑑權是如何實現的

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 體系，看起來是安全些，但對服務的平行擴容卻又並不太友好。

這樣看來，真的沒有既安全，又便利的小程序鑑權服務體系了嗎？

4、雲調用免鑑權體系

小程序最近推出的雲調用能力，則是對原有的這種鑑權模式的巨大優化。

官方對雲調用的描述是這樣的：

雲調用是雲開發提供的基於雲函數使用小程序開放接口的能力。雲調用須要在雲函數中經過 wx-server-sdk 使用。在雲函數中使用雲調用調用服務端接口無需換取 access_token，只要是在從小程序端觸發的雲函數中發起的雲調用都通過微信自動鑑權，能夠在登記權限後直接調用如發送模板消息等開放接口。

主要是有幾個關鍵點：

1. 基於 小程序·雲開發 開發的雲函數能力
2. 經過 wx-server-sdk 才能調用
3. 只有在小程序前端側調用雲函數，才能這樣的能力

咱們來看一下雲調用如何在雲函數中發送模板消息。

從這個例子看出，其實入參並沒有差別，只是不須要再去獲取 access_token。那意味着整個開發的架構，能夠簡化成這樣，架構的複雜度大大下降：

那目前有哪些的小程序使用場景能夠用上雲調用呢？統計了一下，主要用戶信息獲取、訪問留存、消息(模板、統一服務、動態)、小程序碼、內容安全等十幾個大類幾十個開放接口已經支持雲調用。具體能夠參考小程序服務端接口列表，若是接口旁邊有一個"雲調用"的標籤，代表該接口支持雲調用。

但總得來講，這種使用方式已經給小程序開發效率的提升，帶來了質的飛躍。

5、將來鑑權暢想

總之，鑑權場景從古至今都是一個高頻場景，從古代的魚符號，現代的身份證，都是一種令牌憑證的鑑權方式，到了線上的系統中，大部分場景也是基於密碼鑑權體系，除此以外，基於生物特徵的鑑權，好比基於指紋、基於面容ID等等也都在普遍使用起來。

第三方鑑權體系也隨着各大平臺的開放而逐漸發展起來，單看小程序體系下鑑權也是無處不在，小程序雲開發推出了免鑑權體系，爲小程序的開發帶來了極大的方便。

更進一步，將來是否能夠有一種不基於密碼的受權方式？好比基於機器學習和區塊鏈模式下的鑑權，區塊鏈的信任是去中心化的一種實現方式，將來的鑑權可否也能夠作到去中心化的鑑權？

那麼，在你心中，將來的鑑權方式應該是什麼樣的呢？

歡迎你給咱們留言，期待與你一塊兒討論鑑權的將來！