本文所說的電商小程式為一個B2B2C線上蛋糕DIY平臺，其主打“蛋糕線上定製”，並支援成品蛋糕的線上銷售，以下簡稱該專案為BC。
作為一家初創公司，BC團隊需要快速開發出產品原型以用來驗證市場需求。而任何一個產品，為了跟蹤資料，必須要有一套使用者系統，這裡面既包括了使用者的登入、註冊、第三方登入、忘記密碼等瑣碎功能，還包括了管理員對使用者資訊的管理和安全認證。如果先完成這些外圍業務，必然會耽誤核心業務實現。為了加快系統開發速度，減少一些不必要的開發時間，BC的創始人Steven選擇了Authing雲端身份認證（authing.cn）來解決這一部分需求。
以下是他的分享：
一、選擇
兩個月前，我在V2EX上發現了Authing這個平臺。那時，我正在構思BC專案，BC這個專案有兩個核心業務，一個是B2B2C的電商平臺，另外一個是線上DIY蛋糕。為了能夠讓我們的開發人員快速進入核心業務開發，我們計劃使用Authing處理身份認證。
決定使用後我就聯絡上了Authing的創始人，他和我們進行了深入合作。比如BC客戶端是在小程式上的，那時Authing還不支援小程式，因此我們繞道小程式，使用小程式新開放的web-view完成了Authing的接入。此外，Authing還協助我們完成了資料庫的設計，我們本地資料庫只儲存了使用者的authingId和小程式傳過來的使用者資訊。
二、挑戰
這一節我想多說一些技術接入上的細節，看不懂的可以直接跳到最後。
首先從業務說起，BC是一個B2B2C的平臺，意味著我們至少需要三種使用者身份：
1. 買家（定製蛋糕、對蛋糕下單）
2. 賣家（管理商品資料、接單、實行配送）
3. 管理員（管理平臺所有資料）
而Authing正好可以通過建立應用隔離使用者資料，因此我們在Authing平臺上建立了三個應用，並在程式中通過判斷應用ID實現了BC系統中的許可權隔離（應用的ID會附加在登入成功後的token中，可直接讀取）。
自此我們解決了使用者身份的問題，但是現在還不能立即接入業務，我們還需要設計資料庫結構。在Authing的協助下，我們完成了三張使用者表的資料庫設計：
可見，我們的表結構都非常簡單，完成這三張表，只花了10分鐘。
在我們的開發團隊寫好了這三張表的增刪查改和配置CORS後，我們開始正式接入Authing。
首先接入小程式。
前端使用了Authing提供的vue-demo中的程式碼，快速完成了一個基於web-view的認證網頁。使用者在第一次訪問BC小程式時會先跳到這個網頁進行認證（使用者的微信資訊通過postmessage的方式傳送到認證網頁上），認證網頁再將使用者資訊傳送給Authing進行認證，認證通過後即跳回小程式上，然後小程式儲存Authing Token等資訊完成認證（日後的每一次請求都需要傳送Authing Token，然後後端驗證該Token是否合法）。
整個過程花費了前端小哥2個小時的時間，當我們從測試小程式登入後發現Authing同步增加了使用者資料並能看到統計後感到非常開心。
然後接入商家和管理員，我們要求商家只需使用微信掃碼登入。
因為管理後臺基於Web，所以直接使用Authing的JavaScript SDK即很快完成了開發。值得一說的是，在做微信掃碼登入時，我們只寫了客戶端的登入儲存程式碼，整個微信OAuth的開發過程極其簡單。
我們僅僅在Authing的後臺對微信的Client ID和Client Secrect和Redirect URL進行了配置，然後在客戶端讀取了“已開啟”的OAuth服務，使用者從掃碼到登入成功後的任何操作，我們都不用操心！
三、投入生產環境
很難想象，我們在一天時間內就打通了使用者流程，還擁有了一整套管理使用者的GUI。第二天，我們的團隊就投入到核心業務，整個過程非常順利，兩個月後我們完成了所有功能的開發、測試和運維，並將產品和Authing投入到了生產環境。
雖然Authing幫我們分擔了很多工作，但Authing仍有很多功能待完善。比如應該增加使用者管理的Hook功能，假如我在Authing的後臺刪除了一個使用者，那麼可以觸發我的一個遠端API，讓我在本地資料庫中也刪除該使用者的其它關聯資訊。同理，增加、修改都需要。但對於一個初創產品，Authing確實已經很好的滿足了我們的需求。
我也看好Authing這種將一些基礎功能基礎設施化的雲平臺，如果追求效率，上雲是個不錯的選擇。
中國並沒經歷工業化過程，從洋務運動到蘇聯的工業體系引進到加入WTO，所有這些技術變革都是上層引入帶動，而不是像西方社會那樣由資本家、發明家來推動社會生產關係變革。但是，在可預見的未來，隨著金融、醫療和收入的提高，我看好中國社會未來的效率為主。
瞭解更多：authing.cn
Github：github.com/authing