Authing 2.0 發佈：聊聊 IDaaS 的將來

歷經兩個多月的高強度研發， Authing 今日正式發佈 2.0 版本，裏裏外外都有了質的提高。不知不覺中 Authing 已爲多家世界五百強企業和數以千計的開發者提供了身份管理服務，咱們想在此認真的回顧一下過去，展望一下將來。

一年多之前創業的出發點其實很樸素：從雲計算的角度爲開發者解決惱人的登陸問題。看起來，這件事很簡單，IAM 已經發展不少年了，IDaaS 無非是把 IAM 搬到雲上，沒什麼太大的亮點，但真正令我激動的是：咱們要造的是一個真正能做爲企業基礎設施的雲計算身份層。這句話怎麼理解呢？我在後邊會好好聊聊。

通俗易懂 IDaaS

爲防止有讀者不瞭解 IDaaS，我先解釋下什麼是 IDaaS。

當組織開發或維護應用時，他們會選擇本身實現哪些功能以及將哪些功能託管給第三方。例如，若是你正在編寫一個用於付款的應用程序，那麼使用 Ping++ 之類的平臺而不是從頭開始開發本身的支付系統，一般會更節省時間和成本。

若是你的應用程序要求用戶登陸，狀況也是如此。鑑於登陸的複雜性以及身份管理涉及到的分析和合規成本，一般最簡單的方法是購買 IDaaS 並集成到你的應用中。

IDaaS 提供商基於 IAM 提供雲的解決方案。

購買 IDaaS 服務時，其實是在購買 API（應用程序編程接口）。用最簡單的話來講，API 是一組關於軟件或應用程序如何交互的規則，例如翻譯器或中介器。

在有 IDaaS 的狀況下，API 在終端用戶、Authing 和服務商服務器中間流轉。

在談論管理身份時，咱們指的是三種基本用戶類別的身份：

• 客戶身份和訪問管理（CIAM），適用於最終用戶。

• Workforce IAM，它管理你的員工及其對內部應用程序的訪問。

• B2B IAM，使企業能夠將身份與其業務合做夥伴和企業客戶進行集成。

這三個類別的場景區別很大，組織會依據不一樣的場景選擇不一樣的 IDaaS 廠商。

幾乎全部IDaaS提供程序都有一些共同的核心功能，這些包括：

• 多因素身份驗證（MFA）

• 生物識別

• 單點登陸（SSO）

• 用戶管理和訪問控制

更多內容請訪問：https://authing.cn/blog/。

身份本該就是基礎設施

做爲一個寫了十年代碼的架構師，職業生涯中寫過不下數十款互聯網軟件，每一款軟件最開始要作的事情就是設計「用戶系統」和「權限系統」，這麼多年的經驗，不一樣行業不一樣系統，教會了我不少抽象化的思想，從技術層面來講，全部這些架構，總結成一句話就是：身份本該就是基礎設施。咱們作的一切工做，都是圍繞着身份。

當和一位資深的投資人朋友談到這個想法時，他提示我：「OpenID 已經嘗試過可是失敗了」。

OpenID 是一個身份協議，它想在全網構建開放的身份聯盟，用戶不須要記住像用戶名和密碼這樣的傳統驗證標記。取而代之的是，用戶只須要預先在一個做爲 OpenID 身份提供商（Identity Provider, IdP）的網站上註冊，而後用這個帳號就能夠登陸全部支持 OpenID 的網站。

若是你不是很理解這句話，那麼這個例子你必定能理解。你們都知道騰訊和阿里巴巴是兩強相爭，互不相容，而 OpenID 的做用相似於用企業微信登陸阿里雲。

P.S. 企業微信登陸阿里雲使用的並不是 OpenID 協議，而是更加企業級的 SAML 協議，此處僅爲舉例解釋 OpenID 能夠達到的直觀效果。

除了一處註冊，處處通行之外，OpenID 給全部支持 OpenID 的網站帶來了更高價值 —— 共享用戶資源。用戶能夠方便的控制哪些信息能夠被共享以及能夠共享給誰，例如姓名、地址、電話號碼等。

OpenID 在全盛的時候，被 50000+ 網站支持，而且產生了超過數十億次鏈接，它本能夠構建成一個相似 Facebook 的社交網絡，可是它失敗了，失敗的緣由很簡單，外網的評論爲：

The main reason no one uses OpenID is because Facebook Connect does the same thing and does it better. 

每一個人都知道 Facebook 是什麼，相比理解什麼是 OpenID，理解 Facebook 上的身份顯得容易的多。這也解釋了爲何即便有 50000+ 網站支持、數十億次鏈接的 OpenID 最終依然是失敗的。「使用 Facebook 登陸」在 OpenID 全盛的時候，被 250000+ 網站支持，被 Facebook 數百萬的用戶所使用，而且有很強的品牌效應。

在中國，與之對應的就是「使用微信登陸」。

正由於看到了 OpenID 在全球互聯網的失敗以及 100% 會在國內重複發生的失敗，咱們將 Authing 定位爲「雲計算的身份基礎設施」，SaaS 在中國這片農耕文明的土地上還不夠成熟，也正由於 SaaS 不成熟，纔有重構雲計算身份基礎設施的機會。上世紀 90 年代的年輕人押注我的互聯網將在 21 世紀蓬勃爆發同樣，Authing 押注 SaaS 會真正成爲水和電，就像咱們所使用的全部生活服務同樣，SaaS 會注入到每個人的工做中。

Authing 相比 OpenID 有以下優點：

1. 不只面向增量應用，更加註重存量應用

OpenID 面向增量應用，面向互聯網應用的締造者們，擬定了一套標準協議讓開發者接入，讓全網用戶使用一個帳戶通行全部系統。這有點像如今不少區塊鏈系統的去中心化身份，只關注區塊鏈互聯網，拋棄了古典互聯網的用戶。

Authing 在面向增量應用的基礎上，面向企業，關注企業現有應用的現代化改造，並提供完善的接口、工具和方案幫助客戶平滑遷移、融合新舊用戶身份。

2. 不只是一個協議，Authing 是一整套開發套件

OpenID 是一套協議，該協議旨在成爲標準而不是產品。

Authing 擁有超過 500+ 開放接口、十幾種編程語言的 SDK和成熟的開發者生態，使任意開發者能夠在半小時內，免去學習任何協議的成本接入 Authing，達到鏈接任何應用的目的。使用 Authing 最短只要 5 行代碼，包含用戶中心、權限控制、身份來源識別、社交登陸、生物識別、跨平臺、短信驗證、郵箱驗證、登陸/註冊風險控制在內的諸多設計和實施成本將被省去。

3. 基於多租戶雲原生架構，Authing 是面向數億用戶，兼具高性能、高安全的全場景身份雲

OpenID 誕生於在互聯網的早期，有其歷史侷限性，它沒有將身份的彈性伸縮歸入到總體設計中。

Authing 採用雲原生架構，支持 k8s+Docker 的部署方式，已在 AWS，華爲，阿里雲，騰訊雲，七牛雲等多個公有云上實現基於雲原生部署及彈性伸縮能力，是多廠商中惟一支持雲原生架構的產品。

Authing 基於用戶池實現多租，同時可實現三種方式的多租隔離：公有云邏輯多組，私有云物理多租，私有化 k8s 容器多租。此外因爲基於雲原生，理論上無租戶數上限，平滑擴展。

Authing 可對接多種雲原生 KMS 服務；實現端到端加密、數據傳輸加密完備；同時擁有完整的 DevOps 能力：基於雲原生的研發全套 CICD 流水線。

以 API 爲中心的身份中臺

上面這張圖是 IAM 的發展趨勢，Authing 誕生之初就位於第四階段，並將於 2020 年完成第五階段的躍遷，而第五階段中最重要的關鍵詞是「API」。

通俗易懂 API

API 表明「應用程序編程接口」。它是一段代碼，充當兩個不一樣團隊所開發軟件之間的過渡。API 充當雙方之間的中介者或翻譯者，來回傳遞請求和響應。

拿就餐舉例，你向服務員說：「我要一塊雞排」，服務員會向廚房傳遞這個信息，你不用操心「雞排是怎麼作的」，十分鐘後你就能夠吃到雞排。

在這個例子中，你是某個軟件的用戶，服務員是 API，廚房是軟件的服務器。

社交登陸是 API 的常見例子。當軟件實施了社交登陸後，用戶只需單擊一下按鈕便可經過身份提供商進行身份驗證，例如「使用微信登陸」、「使用 QQ 登陸」。在微信登陸中，是騰訊向開發者提供了 API 以幫助用戶使用微信身份登陸到開發者的應用。

咱們很開心的看到，開發者經過咱們的開放 API，以超乎咱們想象的方式拓展了 Authing 自己的不少場景。當我看到客戶的開發者在會議室內討論 Authing 的功能、設計和架構如數家珍時，讓咱們感到很是激動和興奮 —— 咱們的產品幫助了數千開發者解決了數百萬用戶的登陸和身份融合問題，這讓咱們的社會責任感大幅加強。

                                              Authing（紅線）和其餘 IDaaS 廠商的對比

將來在哪裏？

不少人不相信將來，可是我始終清楚，將來由如今創造而成。中學時期學的一首詩「相信將來」，始終鞭策着咱們前行 —— 相信將來，相信將來人們的眼睛：

身份的彈性調度是其餘資源彈性調度的開始

最近十年，最大的變革是雲帶來的，而這場變革，始終都在進行。雲的核心能力，除了方便部署以外，最大的優點是彈性。計算資源的分配粒度從一個機房到一個函數，從買車到滴滴，從買房到租房，訂閱經濟已在吞噬軟件行業。彈性的優點在於咱們不須要爲「沒有產生的計算進行付費」，從而在必定閾值內大幅下降成本。

雲的出現將彈性變成了一個基礎設施能力，任何雲廠商必然會講「彈性伸縮」，這也是客戶關注的事情，你沒有無法想象，在沒有云的時代，廠商是如何痛苦的配備機房的。

由於計算資源的分配粒度愈來愈細，也致使了計算資源開始往業務層靠攏（如：TiDB 能感知業務特色，其會根據地理特徵、高頻訪問等因素進行進行調度伸縮）。

身份做爲一種計算資源是全部資源中最靠近用戶的一層，在彈性伸縮和業務調度上，Authing 會作但不侷限於如下這些事情：

1. 預測峯值即未來臨，自動採購機構，提早擴容，在高峯過去後回收服務器並進行縮容；

2. 感知業務特定，根據業務特色分配計算資源；

   1. 如：中國和美國的用戶各自對就近節點進行訪問

3. 預測查詢類型和訪問頻率，自動決定存儲類型；

   1. 如：熱數據用 Redis，冷數據用 OSS 或數據庫

4. 預測用戶行爲，進行風險控制；

   1. 如：某用戶使用了不一樣的手機登陸了某應用，要求開啓 MFA 二次驗證

咱們很高興的看到，市場上除了 Authing 在強調彈性伸縮外，TiDB、LeanCloud、聲網這類公司已在各自的領域實現瞭如數據庫、計算和 RTC 的資源彈性調度。咱們相信在將來 ，會有更多此類公司出現。

身份的背後是數據

作身份必定離不開數據，咱們發現有些客戶的訴求本不在身份，而是在數據上，只是他們發現，若想打通數據，先要打通身份。

咱們始終在設想一種新的軟件架構可能性（而且已在 Authing 的軟件架構中實踐） —— 身份和數據分離，這種架構有以下幾種特性：

1. 數據全部權歸用戶，用戶決定數據存在哪以及哪些應用和人能夠讀寫用戶的數據

2. 每一個用戶都有一個我的網盤（簡稱 Pod，Personal Online Data），這個網盤中存儲着用戶資料、社交信息以及其餘應用的數據

3. 每一個用戶的 Pod 就至關於這個用戶在互聯網上的身份，「使用微信登陸」、「使用微博登陸」會變成 「使用 Pod 登陸」

4. 全部的數據都被一種名爲「關聯數據」的 數據格式互聯，從而達成語義計算和語義推理，從根本上避免數據打通的問題和數據孤島

下一個階段是智能

現階段的智能比較強調「統計」，較少關注「推理」。

若是身份背後的數據可以被語義互聯 ，那麼產生推理智能的關鍵取決於語義技術。

語義標記的數據稱爲「智能數據」，由於它們以統一的方式爲每一個數據提供了惟一的描述。簡單來講，語義數據界定了一我的的頭像只能叫「avatar」而不是「photo」。當定義了這些詞彙後，這些語義模型將能夠自動判斷上下文的聯繫，並造成語義圖。人工智能將利用這些關係，使其可以更好的從經驗中學習。

如要鏈接數據，必要鏈接身份。這個場景還比較遠，但還是一個值得暢想的將來。咱們不知道，當每一個人的數據能夠互聯時會產生什麼，就像咱們不知道 21 世紀的移動互聯網如此方便了咱們的生活。

尾聲

創業在遇到困難的時候咱們每每會回頭看一下初心：從雲計算的角度爲開發者解決惱人的登陸問題。團隊浮躁的時候，我常常和團隊說一個詞「耐心」，而我對耐心的理解是：有目標是耐心的基礎。

構建一個完美的 IDaaS 並非一朝一夕的工做，清晰的目標和願景讓咱們有耐心讓不可能變爲可能。

Authing 就是身份雲。

附：《相信將來》節選

我之因此堅決地 相信將來

是我 相信將來人們的眼睛

她有撥開歷史風塵的睫毛

她有看透歲月篇章的瞳孔

無論人們對於咱們腐爛的皮肉

那些迷途的惆悵、失敗的苦痛

是寄予感動的熱淚、深切的同情

仍是給以輕蔑的微笑、辛辣的嘲諷

我堅信人們對於咱們的脊骨

那無數次的探索、迷途、失敗和成功

必定會給予熱情、客觀、公正的評定

是的，我焦急地等待着他們的評定

朋友，堅決地 相信將來吧

相信不屈不撓的努力

相信打敗死亡的年輕

相信將來、熱愛生命

1968年 食指 北京