Authing 2.0 发布：聊聊 IDaaS 的未来

关注

原创 2020-09-17 16:05:40 1.9k 阅读 AI 写同款· GEO 优化 ›

历经两个多月的高强度研发， 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 的功能、设计和架构如数家珍时，让我们感到非常激动和兴奋 —— 我们的产品帮助了数千开发者解决了数百万用户的登录和身份融合问题，这让我们的社会责任感大幅增强。