CIAM （用户身份管理）选型指南

你是否正在构思下一个面向消费者的爆款应用？

为了使这个应用获得成功，你必须服务好你的用户，让用户旅程在你的应用中更加便捷，而「用户旅程」的第一步即是「用户的认证及管理」（CIAM）。那么我们该如何设计用户认证体系 ？

你听到一个声音：“看看微信”。你说服自己这不是抄袭，这叫“看业界”。
“飞机都是两个翅膀，汽车都是四个轮子，E 总是等于 mc^2。我哪有抄袭”

来到微信的登录界面才发现，仅仅一个登录，就已经非常复杂了。那再看看抖音吧，相对于微信来说，抖音不仅多了一个“电话号码一键登录”，还多了一个“微信登录”，而微信却没有“抖音登录”

作为创业者，你已经刷了很多励志视频，你笃定一个信念：办法总是比困难多。于是你暂时将自研的解决方案作为 Plan B 放到一边，开始寻找供应商来解决这个问题。

如果你是技术出身，或者当你咨询你的 CTO 时，不可避免的会出现一个思路，那就是基于开源来构建。同时，你还需要提前决策，你的应用是打算用小程序还是原生 App 来服务用户。

本文通过分析原生与小程序的利弊以及市面上主流用户身份管理（CIAM）的开源和商业系统，帮助你做出最优的 CIAM 选型决策。

在进入技术讨论之前，我们先回顾一下移动开发的历史。

0x01 移动开发的兴起和转折

2005 年毕业后我就一直工作在移动领域，先后服务于 Gameloft、Nokia、Samsung 和华为，我见证了诺基亚的倒下、三星的崛起、苹果的辉煌、华为的曲折。从 3G 兴起以来，我们都听闻过很多商业模式上的创新，每隔一段时间就会听说谁谁谁开发了一个 App，拿到了 xx 投资，移动开发人员在市场上炙手可热。

但 2017 年的春节，移动开发领域迎来了一个重大转折：微信推出了小程序。这彻底改变了移动开发格局。之前任何的功能都需要一个 App 来承载，而现在很多功能只需要一个小程序。

但小程序并不能改变这样一个事实：每隔一段时间，就会出现一个现象级的 App。如抖音、头条、小红书、Keep、国家反诈中心 App，以及很多不大可能以小程序形式出现的 App，如以特斯拉为代表的车主 App、银行金融类 App、社交 App。

0x02 原生 vs 小程序

小程序是基于 Web 技术实现的，优缺点也非常明显，对比如下：

优点	缺点
简单，开发效率高，跨平台，不需要安装，用完即走	性能差，体验一般，能力不全，包大小限制、不支持海外市场

基于以上对比，小程序更适合简单业务场景，如点餐、单车解锁、地铁扫码、出示健康码等。小程序缺点中的 “能力不全” 需要重点注意，建议开发者提前做好预研，避免开发到一半突然发现某个功能实现不了，例如推送功能非常有限。

0x03 用户管理系统概览

此时，你已经在小程序和原生 App 之间做出了选择。接下来分析一下用户管理系统，主要对比参照目前国内主流身份认证管理服务商。

“随着时间的推移，以下分析可能会发生动态变化，请以发展的眼光审视。”

分类	代表企业	特点
大厂	阿里云、腾讯云、华为云	云厂商中的小部门。能力有限，场景覆盖率低，文档质量低，SDK 易用性差，价格贵
专精	Authing、其它国内身份管理厂商	专业程度高，价格适中
开源	Casdoor	能力不足，但可以 DIY，价格低或者免费

• 云厂商：

如果时间允许，可以尝试接入系统体验一下，相信很快就会发现各种问题。但由于用户管理系统在云厂商中属于细分部门，投入有限，响应速度也很慢。若涉及产品改动，那更是漫长的版本排期。事实上，即使强如 AWS，其用户管理系统 Cognito 也广受批评。

• 身份认证与管理服务商

专业的事应该交给专业的人来做。

考虑到本文聚焦的是 CIAM，我们首先排除掉国内其它身份管理厂商，因为目前国内其它身份管理厂商主要聚焦的是 EIAM（企业内部用户管理系统），绝大多数面向 C 端场景的功能不足，体验有待优化。
于是，我们把目标锁定在 Authing、casdoor 这个两家服务商身上。不要被名字迷惑，如果你去 github 看他们的代码贡献者，会惊喜的发现程序员的头像都是二次元。

0x04 需求清单

我梳理了一个典型的面向消费者的用户管理系统需求清单，我们可以拿着这份清单去匹配。以下表单中都是非常基础的功能。其他的诸如：多因素认证、人脸指纹识别、用户信息补全、扫码登录等请按需考虑。

0x05 Authing、casdoor 概览

0x06 Authing、casdoor 核心服务对比概览

Authing

Authing 提供整体基于 K8s 技术标准的私有化部署，并根据客户环境采用适合客户环境的高可用方案。但作为 POC，可直接使用 SaaS 版本，无需部署，开箱即用。

casdoor

写此文时，我采用了最新的 casdoor 1.48.0 版本。请参考官方文档启动本地服务：Server Installation

• 问题一：启动核心服务时，由于是 go 语言写的，建议“科学上网”，否则在拉取依赖时可能会报错，如：

../../go/pkg/mod/github.com/casdoor/go-sms-sender@v0.2.0/aliyun.go:22:2: 
github.com/aliyun/alibaba-cloud-sdk-go@v1.61.1075: Get "https://proxy.golang.org/
github.com/aliyun/alibaba-cloud-sdk-go/@v/v1.61.1075.zip": dial tcp 142.251.42.241:443: i/o timeout

• 问题二：按照官方文档启动会报错：

go: downloading github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd
panic: Error 1045: Access denied for user 'root'@'localhost' (using password: YES)

goroutine 1 [running]:
github.com/casdoor/casdoor/object.(*Adapter).createTable(0xc000160cc0)
        /Users/lance/OpenSource/casdoor-1.48.0/object/adapter.go:123 +0x737
github.com/casdoor/casdoor/object.InitAdapter(0x0)
        /Users/lance/OpenSource/casdoor-1.48.0/object/adapter.go:48 +0xb1
main.main()
        /Users/lance/OpenSource/casdoor-1.48.0/main.go:37 +0xa6
exit status 2
Lances-MacBook-Pro:casdoor-1.48.0 lance$ go run main.go
panic: Error 1049: Unknown database 'casdoor'

这是因为本地数据库未创建 ‘casdoor’ schema。遗憾的是，官网说会自动创建：

手动创建 schema 即可。

• 问题三：启动前端项目时，记得关闭“科学上网”，否则会报：
  info There appears to be trouble with your network connection. Retrying...

然后在浏览器里面输入 http://localhost:7001/

注意第一次启动时会比较慢，请耐心等待

启动成功后，控制台信息如下：

有一些 warning，但问题不大。启动后登录界面如下：

0x07 Authing、casdoor 安卓接入对比

• Authing

官方文档地址：Authing Android 接入

根据以上文档提示能顺利接入。值得一提的是，Authing Android SDK，即 Guard 低代码登录组建，只需 5 行代码，即可嵌入登录组件，拥有完整的用户管理系统，同时支持 安卓、iOS 和 Web 端。Guard 可根据需求配置，轻松添加各种社会化登录方式，使用户无缝登录，并且在不同平台拥有一致的登录体验，同时屏蔽了很多底层认证的实现细节，还提供原生 UI 控件（ Hyper component），其丰富的开源组件对主流移动端开发语言的支持，帮助多端应用的开发者极大节省开发成本。

其中比较有意思的是语义化编程模型，感兴趣的同学可以参考下🔗：基于语义化思想的全新编程模型

• casdoor

官方文档地址：casdoor android 接入

接入遇到第一个大的问题是 casdoor 不提供 aar 包，也没有 maven 依赖地址，所以要么下载他们的源码，自行打包成 aar，要么将源码拷贝到工程里面（需要同时拷贝 build.gradle、Manifest 以及 res）。

这样的方式对开发者非常不友好，想象一下每次升级 SDK，都得再做一遍打包或者拷贝的动作。

Android SDK 按照 github 上的文档可以顺利跑起来，但运行后页面无法正常显示，无论是使用本地服务，还是 casdoor 的示例服务（https://door.casbin.com）。

0x08 Authing、casdoor iOS 接入对比

• Authing

官方文档地址：Authing iOS 接入

根据以上文档提示能顺利接入。和 Android SDK 一样，Authing iOS SDK，提供 Web、原生的接入方式，同时也提供原生 UI 控件。

• casdoor
  iOS SDK 和 Authing 一样，也是通过 SPM 集成的，目标仓库都在 github 上，所以小伙伴们“科学上网”开起来。casdoor iOS SDK 和 Authing 相比，问题非常多。

官方文档地址：casdoor iOS 接入

• 问题一：依赖了很多的其他第三方库，所以添加依赖的等待时间非常长（10多分钟），其中依赖了一个大型项目 SwiftNio，我们知道 SPM 的工作机制是要 git clone 仓库的，所以这会非常耗时（具有讽刺意义的是，SwiftNio 完全不依赖任何第三方库）。SwiftNio 对标 Java 生态里面的 Netty ，主要的功能还是开发高性能后台的，个人认为 iOS SDK 去依赖 SiwftNio 是完全没有必要的。
• 问题二：过多依赖会导致最终 App 的大小增加。
• 问题三：由于依赖了 SwiftNio 的源码，会导致编译速度变慢，因为 SPM 的机制是要编译依赖库源码的。
• 问题四：写此文时，SDK 版本为 0.0.1，这让人感到不安。
• 问题五：按照文档写代码是不能跑起来的，问题非常多这里就不一一列举了，需要一个资深的 iOS 开发才能自己解决。
• 问题六：跑起来后，Webview 显示 404。目前未找到解决方案。

所以对于 casdoor iOS 来说，目前基本处于不可用状态。

0x09 Authing、casdoor 小程序接入对比

• Authing

官方文档地址：Authing 小程序接入

按照文档可以顺利接入。有一个讨论点是，“用户不存在”这样的返回应该当作异常处理吗？

• casdoor

目前还没有 SDK，只有一个 example，其内容也为空，正处于初步开发阶段。

GitHub - casdoor/casdoor-wechat-miniprogram-example

0x0a 结论

以上对比之后发现，从产品能力和接入体验来说， Authing 在国内身份认证管理市场上是遥遥领先的。
开源的好处是，在成本允许的条件下，开发者总是可以基于开源自行扩展。而当前国内的开源项目在现阶段是非常粗糙的，离生产环境使用还有很大距离。端侧 SDK 只支持 Webview，这几乎无法在 2C 业务场景里面使用，只能通过其 REST API 自己写代码。