历经两个多月的高强度研发， 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 会做但不局限于以下这些事情：
-
预测峰值即将来临，自动采购机构，提前扩容，在高峰过去后回收服务器并进行缩容；
-
感知业务特定，根据业务特点分配计算资源；
-
如：中国和美国的用户各自对就近节点进行访问
-
预测查询类型和访问频率，自动决定存储类型；
-
如：热数据用 Redis，冷数据用 OSS 或数据库
-
预测用户行为，进行风险控制；
-
如：某用户使用了不同的手机登录了某应用，要求开启 MFA 二次验证
我们很高兴的看到，市场上除了 Authing 在强调弹性伸缩外，TiDB、LeanCloud、声网这类公司已在各自的领域实现了如数据库、计算和 RTC 的资源弹性调度。我们相信在未来 ，会有更多此类公司出现。
身份的背后是数据
做身份一定离不开数据，我们发现有些客户的诉求本不在身份，而是在数据上，只是他们发现，若想打通数据，先要打通身份。
我们始终在设想一种新的软件架构可能性（并且已在 Authing 的软件架构中实践） —— 身份和数据分离，这种架构有如下几种特性：
- 数据所有权归用户，用户决定数据存在哪以及哪些应用和人可以读写用户的数据
- 每个用户都有一个个人网盘（简称 Pod，Personal Online Data），这个网盘中存储着用户资料、社交信息以及其他应用的数据
- 每个用户的 Pod 就相当于这个用户在互联网上的身份，「使用微信登录」、「使用微博登录」会变成 「使用 Pod 登录」
- 所有的数据都被一种名为「关联数据」的 数据格式互联，从而达成语义计算和语义推理，从根本上避免数据打通的问题和数据孤岛
下一个阶段是智能
现阶段的智能比较强调「统计」，较少关注「推理」。
如果身份背后的数据能够被语义互联 ，那么产生推理智能的关键取决于语义技术。
语义标记的数据称为「智能数据」，因为它们以统一的方式为每个数据提供了唯一的描述。简单来说，语义数据界定了一个人的头像只能叫「avatar」而不是「photo」。当定义了这些词汇后，这些语义模型将可以自动判断上下文的联系，并形成语义图。人工智能将利用这些关系，使其能够更好的从经验中学习。
如要连接数据，必要连接身份。这个场景还比较远，但仍是一个值得畅想的未来。我们不知道，当每个人的数据可以互联时会产生什么，就像我们不知道 21 世纪的移动互联网如此方便了我们的生活。
尾声
创业在遇到困难的时候我们往往会回头看一下初心：从云计算的角度为开发者解决恼人的登录问题。团队浮躁的时候，我经常和团队说一个词「耐心」，而我对耐心的理解是：有目标是耐心的基础。
构建一个完美的 IDaaS 并不是一朝一夕的工作，清晰的目标和愿景让我们有耐心让不可能变为可能。
Authing 就是身份云。