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

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

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

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

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

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

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

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

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

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

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

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

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

       0x 原生 vs 小程序

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

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

       0x 用户管理系统概览

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

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

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

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

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

       0x 需求清单

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

       0x Authing、casdoor 概览

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

       Authing

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

       casdoor

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

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

       手动创建 schema 即可。

       然后在浏览器里面输入 ponent），其丰富的开源组件对主流移动端开发语言的支持，帮助多端应用的开发者极大节省开发成本。

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

       官方文档地址： casdoor android 接入

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

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

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

       0x Authing、casdoor iOS 接入对比

       官方文档地址： Authing iOS 接入

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

       官方文档地址： casdoor iOS 接入

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

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

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

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

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

       GitHub - casdoor/casdoor-wechat-miniprogram-example

       0 结论

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

开源隐私计算框架Fate源码学习

       开源隐私计算框架Fate源码学习

       深入探究Fate框架的源码结构与实现逻辑，本文将围绕源码结构、组件执行、任务调度、系统初始化、以及关键组件的实现等方面展开，旨在为开发者提供一个全面理解Fate框架的视角。

       源码结构清晰地组织在github.com/FederatedAI/目录下，其中组件的实现与流程管理紧密相关。Fate框架的核心在于Flow调度系统，其主要功能是将机器学习项目中的组件与算法，通过加密协议在适配的后端计算、存储、通信环境中运行。

       作业初始化基础设施层后，算法通过基础设施执行计算、通信与存储操作。Fate框架通过多个包之间的紧密协作，实现高效的数据处理与模型训练。

       文档导航参考帮助开发者快速定位关键信息，理解框架的各个组件与功能。多个包之间的关系图示提供了整体架构的概览，便于开发者深入了解框架内部结构。

       客户端pipeline视角提供了一次模型训练的全面视图，包括作业、任务、DSL编排与执行单元的抽象概念。party角色定义了发起作业的参与者，其中guest通常作为发起者，而host同时承担仲裁者的角色。

       组件、模块与模型的命名规则清晰，有助于开发者理解并应用框架的API。PipelineModel包负责存储模型训练产出，确保数据与模型的完整性和安全性。

       训练模型的启动依赖特定配置文件，如examples/intersect/test_rsa_job_conf.json与test_rsa_job_dsl.json，定义组件、模块与模型名称等关键参数。定义元数据的yaml文件进一步描述组件列表与管道组件的特殊性。

       系统初始化流程清晰，Fate服务器初始化一系列管理器，包括资源申请与任务资源的分配。调度流程则通过DAGScheduler管理等待与运行中的任务，确保资源的有效利用。

       任务执行通过Worker在调度过程中的门面控制，处理job、task、资源、依赖与tracker的管理。组件执行涉及三个核心任务，实现高效的数据处理与模型训练。

       FederatedML算法工程开发目录提供详细的实现细节，为开发者提供了丰富的资源与解决方案。调度代码的可复用性高，架构中适配部分需要根据具体需求进行扩展。ML包中的功能丰富，涵盖多种隐私求交算法。

       Tracker组件完成模型注册中心的联合功能，PipelineModel维护模型目录与存储元数据与模型文件，同时提供checkpoint能力的集成。认证方案基于casbin访问控制库与双向非对称加密、JWT加密方式实现，提供安全的访问控制机制。