近日，“滴滴出行” App 被国家网信办要求下架整改，“运满满“、“货车帮“、“Boss 直聘“等也加入了网络安全审查的名单。可以看到，国家在防范数据安全风险和保护用户数据隐私安全上，态度和政策正在转变得更加严格，这让很多企业不得不重新审视数据管理的合规性，使用更加严谨的用户数据处理方式。

“快速行动并增长”不再是一种可行的数据管理理念，随着万物互联时代的到来，未来一定会有更严格的立法，来保护用户的隐私和数据安全。企业若从一开始，就没有搭建好现代化的用户身份管理体系，将会处于越来越充满挑战的境地。

一方面，用户数据仍然是企业开展业务的重要资产，另一方面，让数据隐私管理更符合立法要求，重构身份管理的任务昂贵又耗时。

绝大多数公司目前甚至没有评估过他们当前的数据隐私状况，用户数据经常分散在各个应用程序中，缺乏明确的权限管理协议。除非企业对数据的访问方式和访问者，有一个整体的构建和管理方式，否则无法解决数据安全问题。

一、在合规与增长之间取得平衡

一夜之间改变数据隐私的管理方式是很困难的，使用 Authing 这样的 IDaaS 身份管理平台，提供便利、隐私和安全性，是最具成本效益的方式。企业可以在身份认证和集成中获益，而不必担心如何不断更新以符合法律法规，可以专注于自身的核心业务增长。

将政策风险降至最低的最佳方法就是将数据泄露的风险降至最低，并透明地向其用户说明数据的收集、授权等政策，以及保证已采取措施保护其数据的安全性。

多因素认证 （ MFA ）可以极大提高公司安全性，可视化的生命周期管理和安全审计可以帮助企业实现所有用户，员工，以及第三方伙伴的访问，删除更改等权限管理，实时监控风险。

合规并不意味者阻止增长，企业可以不必为复杂且不断变化的数据隐私需求编写代码，从而减慢业务的发展速度，将身份管理交给专业机构是最明智的选择。

Authing 已在多个信息安全框架中获得认证，遵从不同国家和行业的合规性要求。包括公安部信息安全等级保护三级认证 《GB/T 22239-2008 信息安全技术信息系统安全等级保护基本要求》，Authing 采用的是 3 级信息系统的保护策略，达到行业内较高水平。包括欧盟 GDPR（ General Data Protection Regulation ） 《通用数据保护条例》，与国际标准对标，具有充分的信息安全风险识别和控制能力，可以为全球客户提供安全可靠的服务。

二、你的应用实现单点登录了吗 ｜欢迎加入 Authing 应用合作网络

越来越多的企业都在云世界中发展业务，以身份为中心的单点登录策略，不仅可以帮助企业实现统一的安全访问控制，而且将大量减少应用间的鸿沟和数据壁垒，为客户创造更加智能、无缝的安全登录体验。

Authing 是以开发者为中心，基于云原生架构的 IDaaS 产品，是一个独立的、中立的、可伸缩、安全的云身份管理基础设施，支持所有企业和开发者便捷灵活的接入，而且随时处理自定义需求。

目前，全球有数千家优秀组织信赖 Authing 来实施他们员工和客户的身份管理战略，每月保障数亿次的安全登录体验。

加入 Authing 应用合作网络，你可以拥有一个现代的身份管理架构，该架构将为你的应用程序赋能，实现多种身份认证、单点登录、多租户管理等功能需求。

加入 Authing 应用合作网络，你可以接触到数千家企业，他们可以非常轻松的集成你的应用，将你的应用程序部署到他们的千万用户中。

Authing 应用合作网络，覆盖云计算、项目管理、 ERP、办公软件等领域，主流应用已扩展至数百个，如 Google Workspace、 Github、GitLab、腾讯云、阿里云、华为云、AWS、飞书、 ZOOM、Jenkins、JFrog、Salesforce、Zabbix 等。

三步即可加入 Authing 应用合作网络

（你可以点击阅读原文获取详细上架指南，也可以联系工程师一对一咨询 [email protected]）

第一步：将你的应用集成 OIDC 能力（如果你的应用已经具备 OIDC 能力，则可以直接进入第二步 ）

基于 OIDC 实现的 SSO 主要是利用 OIDC 服务作为用户认证中心的统一入口，使所有需要认证的部分都交给 OIDC 认证中心来做。你可以到 OpenID Connect 官网了解 https://openid.net/connect/。

第二步：基于 Authing 测试 OIDC 能力

当你的应用完成 OIDC 集成后，Authing 可以帮助你快速验证是否已经具备完整的 OIDC 能力，Authing 提供了 OIDC 的五种授权模式测试样例。

1. 授权码模式

2.授权码 + PKCE 模式

3. 隐式模式

4. 密码模式

5. Client Credentials 模式

如果你不知道该选择何种模式，请使用最普遍的授权码模式 – 授权码模式测试。

测试 OIDC 能力的参考文档 https://docs.authing.cn/v2/apn/test-oidc/get-oidc-parameter/step1.html。

最后一步：提交应用信息

当你完成了OIDC 的集成与测试，就可以提交你的应用信息 https://wenjuan.feishu.cn/m?t=sb7J1rXIrIti-4yvp，Authing 工程师会尽快把你的应用加到应用网络中。

将你的应用添加到 Authing 应用合作网络是完全免费的，你也可以直接联系我们的工程师，获取一对一的咨询帮助，邮箱 [email protected]。

三、你可能不知道你用户的流失，竟是因为一个登录框

如今企业都在走向数字化，数据信息成为了重要资产，建立以人为核心的用户身份和访问管理 (CIAM) ，正在变得愈加复杂且重要。

企业都希望为用户创造更好的访问体验，而登录框作为用户访问的第一窗口，其重要性往往被忽略。

以下五种方式，也许正在让你的用户默默离开。

1、繁琐的密码重置

我们一般都有多个账户，会经常忘记密码，如果你设计了繁琐的密码找回过程，一定会激发起客户的反感，把客户拒之于千里之外。虽然安全和体验都很重要，但多数企业往往很难做到平衡。

2、不能查看密码

我们容易输错密码，但总是不方便查看哪里出错，所以，有一个简单的切换开关，让用户可以选择文本输入可见，一定会帮助你给用户留下良好的印象。

3、不提供社交登录

很多用户只是想浏览，并不想写注册信息，通过常用的社交账户进行登录越来越流行，这项功能会让用户更愿意登录你的应用。

4、不能进行生物特征认证

生物特征认证是一项正在快速发展的技术，相比记住密码，越来越多的用户更青睐于使用生物特征认证。最常见的包括：指纹识别、人脸识别、视网膜/虹膜识别、语音生物识别；还有新兴的步态识别、静脉识别等身份验证方法。

5、割裂的登录体验

用户都希望通过一次登录，就可以访问生态里的所有应用，但是现实生活中，应用系统之间极其割裂。企业为客户、合作伙伴和员工提供单点登录解决方案，是目前比较流行的方法之一。 

据相关数据显示，30% 的用户在遇到登录问题时会选择离开，超出 10% 的交易被放弃是由于缺乏安全信任。

在万物互联下，如何建立成熟的身份管理机制，创造现代的接入体验和安全防护，这正是客户身份和访问管理 (CIAM) 发挥作用的地方。有了适当的策略，不仅可以在安全和体验之间达到平衡，还可以有效的推动业务增长。

新商业时代需要运用新的方法来加速业务增长，利用不断进化的创新技术和工具可谓是最佳的方法。

Authing 登录组件（Guard）是一种可嵌入的登录表单，帮助开发者屏蔽大量底层认证的实现细节，精美的设计避免了繁琐的 UI 开发；突破性的单点登录技术，实现员工、客户一处登录就可访问所有相互信任的应用系统，统一管控身份权限；微信、微博、QQ、Github、Google、Twitter、Facebook、钉钉、飞书等多种社会化登录方式轻松添加，让用户体验无缝登录；提供多种认证方式和安全防护，有效保障业务安全。

您可以在 https://authing.cn 找到有关 MFA、SSO 等功能的更多信息，以及其他可以让您的登录更出色的方法。

四、Authing 客户案例丨投光

投光致力于用创作工具+共创社区的模式，为科研提供 GitHub 式群创与版本控制的知识开源平台。

投光为科研提供 GitHub for Paper 的知识开源平台，实现学术研究的数字化、填补中国预印本平台的空缺。投光用持续群创与版本控制，实现文章生产与专业交流。此外，该平台将支持文章与算法在社区开源。用户可以为开源文章和算法提交 Pull Request 和 Issue，从而，让持续更新的 1 篇好文章，代替 20 篇复读。最终，实现对研究成果的知识图谱与现实价值精准评价。

投光社区配合专业生产工具（投光编辑器Editoe），使用户写一篇 Paper 无须下载 7+ 插件，加速知识创作。投光编辑器支持代码沙盒、参考文献管理、文档分享与共创，数据可视化、插图绘制以及多媒体元素，让用 MarkDown 语法写论文成为可能。

现在，投光编辑器已完成首次内测，数百名用户积极参与其中。在测试过程中，投光收到了来自国内外诸多用户好评。

需求挑战

在选择使用 Authing 之前，投光一直使用国内某云厂商作为自己的身份服务基础设施，后经常有海外用户反馈各类用户登录和验证遇到麻烦。不同国家手机号格式和登录验证方式的不同 ，也带来了一系列问题。此外，从零构建用户系统为投光团队带来了安全系统与架构设计上的研发压力。投光如果通过自己研发去优化用户登录验证、电话匹配等，耗时、耗力又会面临诸多潜在风险。

经过多方选型，投光最终选择使用 Authing 来解决用户身份登录验证和授权管理等难题。

想法变现实

经过短短一个下午的集成，投光正式开始 Authing 之旅。通过使用 Authing 对用户进行精细化管理，权限分配和用户统一管理等能力，大大提升了业务场景的多样性。用户画像的沉淀使得投光更了解用户，从而更准确地制定用户获取策略与用户服务计划。

用一句话说，投光通过 Authing 实现业务强稳定性的同时，更收获了 Authing 对业务的持久赋能。

• 创建基于Authing 身份源的用户管理体系，快速集成国内外多应用系统，加速投光研发团队核心系统的研发，降低研发成本，减少研发周期；

• 为国内数千用户和国外数百用户提供简便、安全的登录体验，灵活且易维护，大大降低运维人员的管理成本；

• 打通 PC 端和移动端用户数据，一个账号密码登录多端应用，为用户提供极致的登录体验；

• 解决投光一直以来关注的用户管理的难题。

在产品层面的深度融合，一起为企业 C 端用户提供身份的基础设施，实现便捷、安全、零信任的基础架构。未来双方将继续深入合作，为客户提供更多安全、灵活、易用、高效的数字化登录体验。

客户评价

Authing 协助投光实现了用户双端安全登录和权限管理的构建工作，大大解放了研发资源，节约研发成本超 40%。在 Authing 协助下，投光得以专注于提供更好的终端用户体验。

五、Authing 客户故事丨意大利裕信银行

客户介绍

裕信银行是一家总部设在意大利米兰的欧洲银行，是欧洲最大的银行集团之一，拥有 4000 万以上的用户，业务遍及 22 个国家。意大利裕信银行的核心业务在意大利、奥地利和德国南部等地区。

裕信银行在中欧和东欧也有大量的业务。按照资产总额算，拥有 910 亿欧元资产的意大利联合信贷银行是欧元区第一大、欧洲第三大和世界第六大的银行集团。

需求挑战

1、企业内部有数千员工身份登录管理的需求，但基础设施平台的员工身份管理能力薄弱，自研技术实现周期长、成本高，给运维人员带来了极大的管理难度；

2、银行业对于数据安全要求高，如何保障员工安全合规的登录裕信银行部署的应用，成为他们现阶段的难题；

3、金融行业的特殊性不支持公有云部署，给裕信银行在身份管理选型上带来一定难度。

想法变现实

1、Authing 提供了多因素认证方式，帮助裕信银行在身份认证上有多种选择登录方式，来确保银行应用和数据的安全；

2、Authing 灵活的部署方式，让裕信银行快速决策、选型；

3、Authing 基于身份云基础设施，满足裕信银行现阶段的应用需求，以及未来身份扩展的可能。

六、牛透社专访：Authing 是唯一能够全面替代 Okta 的身份服务提供商

最近，数据安全再度成为风口浪尖的话题。

而从「中国企业服务云图」来看，安全领域的细分赛道涵盖了身份认证、数据安全、网络安全等。在身份认证赛道上， Gartner 有这么一组统计数据：2019 年全球 IAM（Identity and Access Management ，身份识别与访问管理）市场规模为 98.4 亿美元，预计到 2024 年将增长至 137.7 亿美元，2019-2024 年的复合增速为 7%。

2009 年，云身份管理厂商 Okta 诞生于美国。作为行业独角兽，Okta 市值接近 400 亿美金，在整个美国的科技型企业中，包括在世界 500 强的公司中市占率非常高。

据说微软还专门成立了一个「干掉 Okta 会议室」，专门针对 Okta 来研发竞争产品。

今年三月，Okta 斥资 65 亿美元以全股票方式收购另一家美国身份管理平台 Auth0。而 Okta 和 Auth0，正被中国的身份认证创业企业 Authing 瞄准。

这家创始团队都是 95 后的企业，曾公开宣称“目前 Authing 是唯一能够全面替代 Okta 的身份服务提供商。”

日前，Authing 创始人 & CEO 谢扬接受牛透社采访，分享了关于身份云数字化的思考。

在谢扬看来，软件的模块化开发和微服务化是大势所趋。计算已经变成以人为核心，以身份为中心，Authing 致力于做软件背后的软件。谢扬基于此，提出了「计算哲学」，这代表了一种对待计算的世界观和方法论，同时在指导着 Authing 的产品开发和技术架构。

经牛透社整理，以下为正文：

牛透社：2019 年成立，为什么这个时间点做这事？想改变什么？

谢扬：主要是看到几个问题。第一，中国的云计算产业缺少身份云基础设施，我们想通过创业来填补这个缺口。

第二，截至 2019 年的时候，我已写了十年代码，开发过不下一百款应用，深受身份模块的折磨，每做一个应用都需要重复开发登录注册、社交登录、权限控制等和核心业务无关的东西，我意识到身份会拖慢业务的迭代速度，自那时起我就在思考，有什么方式能把身份模块抽出来作为独立的云服务向外提供，一旦做成，也意味着全球几十亿互联网用户都有机会通过我们的登录界面进入到他们的应用中，我们就会成为一个入口，这让我觉得非常兴奋。

第三，中国信息化环境的异构化，让我们有极大的使命感驱动这种情况发生变化，我们认为信息同构的必要条件是身份的同构，而身份云是这场征途的必经之路。

我们目前的行业叫 IDaaS（Identity as a Service，身份即服务），但刚创业时，我们想做的其实是 AaaS（Authentication as a Service），二者稍有不同。

IDaaS 更多的是单点登录，面向企业员工，员工在云上可以通过一个账号登录所有 SaaS 应用。

而 AaaS 更多表示的是「认证基础设施」，它是面向开发者提供 API 能力和云的弹性伸缩能力，面向构建任何应用（不分内部和外部）的身份基础设施。

举个简单的例子，IDaaS 的功能可以基于 AaaS 开发出来。AaaS 相当于水，IDaaS 相当于热水，水能做很多事情，但是热水只能面向想洗澡的人或者想喝热水的人。水是基础设施，热水是某一类应用。

我们创业的初衷是为了提高行业的生产力，软件的模块化开发、组件化开发和微服务化是大势所趋。开发者友好的身份基础设施能加速中国云计算的繁荣，计算已经变成以人为核心，以身份为中心，Authing 致力于做软件背后的软件。

牛透社：从成立到现在，外在的变化有哪些？

谢扬：我们在中国开辟了一块全新的身份云市场。我们采取了和竞争对手完全不同的竞争策略和产品方向，无论是从早期以「生产力」、「云」、「API-First」为核心的产品层面的「身份基础设施」上的创新，还是营销上的「知识型内容营销」战略，这都使得我们在中国这片土地上重塑了这个市场的竞争格局。

创业之初，不少投资人质疑我们的模式，但是经过我们两年的努力，还是把路走通了。我们发现，随着产品的完善和品牌的建立，越来越多的企业开始信任我们，两年前的身份云愿景在今日已经实现。

在 2019 年，我们刚发布产品的时候，就有来自七个国家和地区的开发者注册了 Authing。当时有少量付费的客户，我告诉团队，这是一个好的迹象。而到了今天，我们在全球已经有数百家付费客户，从教育、零售到金融、科技等行业，我们已经成为了不可或缺的基础设施。

尤其令我惊讶的是，国内科技从业者相比两年前，对于我们的接受度已经大幅提高，我们和很多客户的合作开始都是源于客户在公司内部提议：“我们用这款新兴产品解决问题吧”，这已经激励我们把用户体验做到极致，也给了我们更多信心。

牛透社：回归初心，现在的您有哪些变化？比如您对个人、对公司、对行业和客户等方面的认知和思考，有哪些改变？

谢扬：创业两年来，我几乎每个月都在变化我的思维模式。这种思维模式转变的源头，来自我的团队、客户以及其他公司的 CEO。最大的变化就是学会了利用杠杆来达成目标。比如以前自己是工程师的时候会大包大揽，而现在我学会借力最专业的人才来达成最终目标，这推动了公司和团队更好的发展。从前我认为技术最重要，现在认为人最重要。

认知的转变源于思维底层对人的态度的转变。我曾一直认为事比人更重要，只要设定严格的目标，不论对什么人都施加压力，目标都终会达成。而现在，我认为育人、留人，让团队达成自己的目标才是最重要的。当然，我也会根据不同的情况选择最合适的管理手段。

就我个人而言，我以前是个不懂休息的人。我在大学时，每天都是 6 点起床到图书馆看书到晚上 11 点，基于这样的勤奋，我用一年的时间学完了四年的计算机课程。那时，每天晚上不论多晚我都会去操场跑十圈，下大雨也会举着伞坚持跑完，有很多下雨的夜晚整个操场上只有我一个人。我始终都是那个不合群和特别执着的人，我决定要做的事即使有再多人否定或不认可，从实际经验来看，基本都能做成。我所有努力做的事情，都没失败过。

那段时间，我的生命是孤独和紧张的。而现在，我逐渐学会了放松和接纳自己，更学会了在日常的生活中奖励自己，我相信这才能带来持续的成功。

在行业上来说，从前我逢人就讲生产力。但是生产力这个东西太大，究竟从哪落地，是我经常思考的问题。今年 4 月，我脑子里突然冒出来四个字：「计算哲学」。

这源于在我们团队扩张中，不断践行的理念和新的工具，讲的和做的多了之后，我发现，这些理念和工具底层逻辑是相通的，这些逻辑不仅可以造福我们，还能造福更多的企业和更多的人。

哲学里，我最喜欢的一句话是：“哲学是人们认识世界和改造世界的根本方法“，这句话指导着我，让我始终有「人定胜天」的自信。优秀的公司顺应需求，解决问题；伟大的公司发现问题，带来变革。

我注意到很多人不理解什么是计算、身份、信息化，所以我认为有必要从「计算哲学」的角度去帮助更多人理解计算的世界观和方法论。我发现了这个重要的事情，我觉得我有义务去普及它，让更多人受益，这也是我们这家公司的使命。我们的目标就是提供人们创新的平台，而「思想」是创新的基石。

牛透社：在您看来，Authing 改变了谁？改变了什么？

谢扬：与其说 Authing 改变了谁，不如说 Authing 带来了什么。

1. 带来了新的开发理念、IT 架构基础设施、微服务模块化开发方法和新的生产力平台；

2. 让敢于接受新鲜事物的科技工作者享受到了下一代身份基础设施的便利性和友好性；

3. 定义了下一代身份基础设施的标准和规范；

4. 让云变得更加繁荣，中国 SaaS 从业者和客户已经接受了基于 Authing 连接人与应用。

谁先集成了 Authing，谁就会比竞争对手更有竞争力。因为，客户优先采购具有单点登录能力的软件；在流量激增比如预抢手机的时候，Authing 也能保障用户稳定的登录进任何应用。

牛透社：想对同行者说点什么？

谢扬：创业者要敢于慢下来，要长成大山，而不是成为沙丘。

七、Bentley 使用 Authing 快速实现应用系统与身份的集成 ｜ Authing 案例

客户介绍

奔特利（Bentley）工程软件有限公司成立于 1984 年，员工 4000 多人，在全球 172 个国家设有分支机构，年收入超过 8  亿美元，被评为全球第二大地理信息软件解决方案提供商。

奔特利（Bentley）通过为企业和专业人员提供基于设计、建造和运营公路、桥梁、轨道交通、给排水、公共工程和公用事业、园区以及工业设施的解决方案。

需求挑战

1. 作为一家全球性的企业，奔特利（Bentley）已经在全球范围内已经完成了身份体系的搭建，但现阶段使用的身份管理产品无法满足奔特利（Bentley）中国团队业务的快速发展的需求，中国团队希望寻求一家国内的优秀身份认证提供商，来快速完成现有应用系统与身份的集成。

2. 单一的认证访问方式，业务安全无法保障。现在奔特利（Bentley）中国的业务采用用户名+密码的单一认证方式，安全性得不到保证，部分系统密码设置也不符合密码的要求，存在安全隐患。

3. 缺乏清晰实时操作和安全访问审计，无法满足企业安全合规上的需求。随着业务的快速发展，针对用户访问、权限使用和数据管理，缺乏实时有效的事前预警、事中审计和事后追溯的路径。

想法变现实

Authing 提供了完善的单点登录平台，为旗下 Web 和员工系统均快速实现了高效的认证和访问管理功能。

Authing 提供了多种认证方式供奔特利（Bentley）选择：组合、密码策略、登录频繁检测、自定义认证流程等，并且都可以通过管理控制台轻松配置完成。

Authing 基于用户行为审计、管理员审计和应用访问情况为奔特利（Bentley）实现了可视化安全审计的策略，支持不同人员（组）设定不同的密码策略。多因素认证让用户访问无缝、敏捷和安全。

八、Authing 客户案例｜高等教育出版社

客户介绍

高等教育出版社（以下简称高教社）成立于 1954 年 5 月，是新中国最早设立的专业教育出版机构之一。高教社现有在职员工 1700 余人，年出书万余种，发行近 1.3 亿册。出版社规模、员工数量居国内出版社前列。

在教育部的领导下，高教社承担了全国高校思想政治工作网、中国大学生在线两个网站的建设和运营工作，目前思政网已覆盖各省级党委教育工作部门、 75 所教育部直属高校和其他部委高校、2500 所地方高校。中国大学生在线网站会员总数已达到 1120 万人，再创历史新高。

高教社与包括众多知名出版商在内的全球 200 多家机构开展广泛的合作，24 个语种版本的国际型产品在世界 60 多个国家发行，版权输出数量在全国单体出版社中连年名列前茅。连续多次被评为国家文化出口重点企业。

需求挑战

• 高教社的数千万用户分布在几十个软件平台，IT 管理复杂；

• 高教社需要出色的用户登录体验，提高与国内教育市场、国际出版商的合作；

• 承担思政网的建设工作，意味着防欺诈、安全保障格外重要；

• 运营思政网、大学生在线网等多个网站，高教社对跨品牌单一登录的需求强烈。

想法变现实

在与高教社的合作中，Authing 团队提供全程一对一的咨询与技术服务，加速网站上线，支持客户成功。

凭借 Authing 完善的身份认证和访问管理服务，两位工程师用了一个下午就完成了部署测试，轻松集成了高教社的千万用户。实现了在一处、用一个账号跨品牌登录的体验。

通过提供多因素认证、登录环境监测等安全技术，Authing 为高教社打造了专业的安全防护。

Authing 平台弹性灵活，文档、软件包丰富，在高教社的迅速发展中，为其提供了拓展、集成能力，减少日常的维护工作，降低未来的开发成本，打造高效愉悦的开发方式，让 IT 管理化繁为简，加速业务成长。

客户评价

——「Authing 是一个经过思考做出来的产品。」

九、Authing 云原生的技术探索与落地实践

Authing 是国内首款以开发者为中心的全场景身份云产品，集成了所有主流身份认证协议，为企业和开发者提供完善安全的用户认证和访问管理服务。Authing 作为云原生架构的 IDaaS 产品，从创立之初就是面向云的技术来进行架构设计，我们将 Authing 打造为云上身份管理的标准组件和云计算的身份基础设施。所有企业和开发者都能便捷灵活地接入。一路走来，我们的团队在技术体系建设中有了非常多云原生方向的积累，今天给大家分享一些实践经验。

公有云基础设施

Authing 的基础设施全部在云上，腾讯云、AWS、阿里云都有使用，目前核心业务我们是架构在 AWS 上，少部分基础设施使用腾讯云和阿里云。我们选择 AWS 承载我们核心业务的原因是：

1. 功能强大，AWS 作为云计算的鼻祖，提供全行业最强大的云计算基础设施；

2. 生态好，周边设施丰富，有众多开源解决方案。

3. 对我们不仅仅提供技术上的支持，还关注我们业务上的成长。AWS 市场团队会有专人负责 Start Up 生态，提供技术、资源、商务上的支持。在我们组织的线下活动中，经常有 AWS 的伙伴来参加。

目前我们在用的 AWS 核心组件有：

1. EC2：是 AWS 提供云计算服务的基本组件，提供高可靠，高弹性的虚拟主机服务。AWS EC2 提供了多种实例类型，Authing 的核心服务都跑在 EC2 的 m5 实例；

2. EKS：AWS 提供 Kubernetes 托管集群服务；

3. RDS for Postgres：提供基础的业务数据存储；

4. Elasticsearch Service：提供日志服务存储和检索，并提供基础的分析能力；

5. Loadbalancer：提供跨可用区的负载均衡，实现多地多中心的高可用架构。

这些组件组合起来给我们提供了一套高效稳定的基础设施平台。

Kubernetes

云中立

我们不能改变用户已有的云基础设施，我们只能最大程度去兼容用户的云环境。因此，我们提出了「云中立」和「Authing Inside」的概念。在多云环境下 Authing 应该保持其中立的特性，可以部署不论是AWS、腾讯云、阿里云还是私有云环境。在混合云或者私有云环境下，Authing 应该像 Intel 一样被集成在客户的 IT 系统中。

为此我们对项目中使用的中间件进行了一层抽象，同时兼容多种组件。在公有云场景尽可能使用公共云稳定的基础设施，比如云对象存储、消息队列等。在私有云环境中可以使用开源组件进行替换，保证在不同场景下的功能完备。

云中立方案：基础设施即代码

业务上云对 IT 基础设施的管理提出了更苛刻的要求，我们需要：

1. 更好的系统效能：及时了解相关领域而规避了风险，确保了合规和 IT 基础设施的安全。

2. 更快的速度：在今天，软件交付/更新的速度被认为是成功背后最重要的因素之一，需要保证基础设施的高效迭代。

3. 高效的变更管理：在部署到生产环境之前，代码常常被修改和测试。基础设施即代码确保了在不同设备、平台和系统中实现更安全和高效的变更管理。

4. 可扩展的基础设施：硬件的虚拟化使得在需要时增加、替换和扩展资源。

因此，我们在团队中实施「基础设施即代码」的概念，避免手动的配置，通过使用代码表示环境的期望状态来强制实现了一致性。使用基础设施即代码来部署基础设施是可重复的，也避免由于配置漂移或者缺失依赖导致的运行时问题。DevOps 团队可以通过一套统一的实践和工具来协作以快速、可靠和大规模的交付应用以及其支撑的基础设施。

持续交付

在云原生系统中，我们还应该关注交付能力。在我们进行面向云原声的持续集成实践中，我们关注以下两点：

1. 简单，概念和操作都应该简单。团队里的每一个成员，不论技术水平高低，都可以快速的理解 CICD 流程并将自己代码发布到不同环境。

2. 最小适用，如无必要勿增实体。用尽可能简单的组件完成代码集成和上线交付。

基于以上两个点我们选择 Gitlab CI + Argo CD 进行持续集成。

在 CI 流程中，研发同学提交代码后会自动进行单元测试、E2E 测试，测试成功后进行 Docker 镜像构建，将产物上传到中心镜像仓库。

在 CD 流程中，我们以 Git 为中心深入实践 GitOps 模式，通过更新 infra 仓库中 Kubernetes 编排文件中的镜像版本号，实现自动或者手动上线。

Serverless

Authing 是 Serverless 技术的先行者，我们在多个业务场景使用了 Serverless 技术，其中比较有代表性的是 Pipeline 功能，用户池管理员可以在账号生命周期的不同阶段（注册前、注册后、认证前… ）进行函数扩展。开发者在 Authing 控制台中定义 Serverless 函数逻辑，我们会将函数进行打包上传到云端。当终端用户进行登录注册等行为的时候会出发函数钩子，执行之前定义的逻辑。

Authing Pipeline

除此之外，我们和腾讯云、阿里云等头部云计算厂商的 Serverless 团队都有紧密的合作，探索 Serverless 场景下的认证授权的创新模式。

总结

十、Authing 登录组件优化实践解析

Authing Guard 是一种可嵌入的登录表单，可根据你的需求进行配置，它使你可以轻松添加各种社会化登录方式，以便你的用户可以无缝登录，并且在不同平台拥有一致的登录体验。

Authing 2.0 版本上线之后，我们对官方托管的登录页面进行了 UI 和功能升级，升级后的登录界面操作方便快捷。在新版本升级的同时，我们对原有 Guard 组件进行了兼容处理保证了原有 Guard 组件的兼容性。同时，我们发现原有 Guard 也存在以下一些问题：

• 登录流程 UI 和行为与新版官方登录页面不一致；

• 只提供命令式调用方法，没有提供对应前端主流框架的组件，开发者使用体验不好；

• 打包体积较大，原版 Guard 打包出来有 1.3M；

• 原版 Guard 还带有路由跳转逻辑，嵌入在单页面应用中使用时比较麻烦；

• 公有云应用不支持 SSO

基于上面碰到的一些问题，我们决定对 Guard 进行重构，并确定了以下目标：

1.新版 Guard 组件需要和线上登录流程的组件 UI 和行为保持一致；

2.新版 Guard 组件应该实现对 React、Vue 和 Angular 更好的适配，并同时支持命令式调用；

3.降低打包产物体积，目标产物低于 300KB；

4.去除路由跳转逻辑，完全由数据驱动进行 UI 切换；

5.公有云应用也要支持 SSO；

6.方案选择。在确定了目标后，我们提出了以下几个方案：

方案一：使用 Stencil.js 打包出能在主流框架中直接使用的 web component：

       a.优点：Augular、Vue、React 组件复用最大化。为了兼容前端框架的代码几乎为零。

       b.缺点：Stencil.js 学习成本高，有一定的不确定性，如在 Vue 框架下是否兼容复杂配置和多种回调事件。

方案二：Augular、Vue、React 三个平台相对符合各个平台最佳实践开发，在样式上做复用：

       a.优点：开发者体验最佳，和各个前端框架贴近程度高。

       b.缺点：基本无法复用逻辑。

方案三：先写一版 React 的组件，针对其他框架进行包装：

       a.优点：Augular、Vue、React 三个平台兼容，支持原生 JavaScript 命令式调用，UI 和绝大部分业务逻辑可直接用现有线上方案。

       b.缺点：对于非 React 版的组件，还是需要将 React 打包进组件内，包的体积会增大。

为了确保能够快速稳定上线且做到最大程度的逻辑复用，最后选定了方案三，先完成 React 版的组件，然后使用原生 JavaScript 进行包装，完成原生 JavaScript 版的组件，最后 Vue 和 Angular 分别将原生 js 版本包装成组件即可。

具体实现

实现过程中碰到的问题主要是项目如何组织、打包流程和产物体积等问题，业务逻辑因为之前都有就没有太大问题。

工程化

要为不同的框架生成对应组件，就需要打包出不同的 npm 包，且 native-js 版的组件依赖 React 版组件，其他版本组件依赖 native-js 版本的组件，所以决定把所有包都放在一个仓库中进行管理，采用 lerna + yarn workspace 来管理工作流。通过 lerna add pack1 –scope=pack2 就能实现本地包之间的相互依赖，通过 lerna run xx –stream，lerna 会按依赖拓扑顺序依次执行各个包中的命令，这个在打包时是必须的。同时 lerna version 能够统一管理包的版本，若某一个包的版本通过此命令改变了，依赖此包的其他包中的 package.json 中的版本号也会对应修改。最后的项目结构如下：

打包配置

React 和 native-js 版的组件是使用 React 官方提供的工具 create-react-app 初始化的，但是不支持将某一组件打包成组件库的形式，需要进行一些改造。Vue 和 Angular 官方提供的脚手架工具都提供了打包成组件库的功能，但是中间也碰到了一些问题。

React

create-react-app 修改配置，需要运行 yarn run eject， CRA 会将所有的打包配置都暴露到项目根目录的 config 文件夹中，然后就能进行修改了。以下是我修改的一些 webpack 配置：

• entry: 设置为组件库入口文件；

• output.library：设置成组件库名；

• output.libraryTarget：为了兼容所有调用方式(cdn 引入，cmd，amd，esmodule)，需要设置为 umd；

• externals：作为 React 组件，使用方是肯定会依赖 react 和 react-dom 的，将这两个包加入到 externals 中，webpack 就不会将其打包到最后产物中，同时在 package.json 中把它们加入到 peerDependencies 和 devDependencies 中；

• optimization.splitChunks：组件库是希望每一个入口文件只输出一个打包文件的，将 optimization.splitChunks设置为：          

1. cacheGroups: {

2.     default: false,

3. },

webpack 就不会进行分包优化了。

• optimization.runtimeChunk: runtimeChunk 是 webpack 为了充分利用浏览器缓存，将一些包的映射关系单独提取出来的记录文件，作为组件库也不需要，将其设置为 false。

native-js

native-js 版的配置与 React 版的差不多，只是需要将 externals 配置去掉，因为 native-js 版的使用方一般是不会依赖 react 和 react-dom 的。

Vue

Vue 官方提供的构建工具 vue-cli 提供了构建组件库的功能，但是打包出来后发现文件莫名大了300kb 左右，查看配置也没有发现什么问题，最后决定使用 rollup 进行打包，rollup 的配置确实比较简单，配置好相关的 vue、css、babel 插件就差不多了。不过 rollup 对于 commonjs 的包识别可能会有问题，使用了 rollup-plugin-commonjs插件也可能无法识别包内导出的内容，需要手动配置一下插件的 namedExports 配置。

Angular 

Angular 提供的 cli 已经比较完善了，打包出来的库也没有出现莫名体积增大的情况，只是需要将 native-js 加入库根目录下的  ng-package.json 的 whitelistedNonPeerDependencies 中，不然打包时不会将其打包到最后产物中。

经过上面的一些配置，四个版本的项目都能运行起来且能够相互依赖了，只需要将所有的业务逻辑都放到 React 包中，其他版本的包做一些事件监听和配置传入即可。

体积优化

为了 UI 一致及快速开发，我们使用了 ant 来开发 React 版的组件，最后打包出来发现有 1.1M，显然没有达到最初定的目标，通过 webpack-bundle-analyzer 对打包产物进行分析，做了一些优化。

tree-shaking

Guard 组件中的登录逻辑都使用了我们的 authing-js-sdk，有些代码在 Guard 中并没有使用到也被打包进来了，而 authing-js-sdk 是有打包出 esmodule 模式的包的，所以应该支持 tree-shaking 的，看了代码发现是没有在 package.json 中配置 sideEffects，加上之后就支持 tree-shaking 了，不需要的代码也没有被打包进来。

node-polyfill

Webpack 在打包时，如果发现有些包依赖了一些 node 环境下的包，会自动加上 pollyfill，而这些在前端是用不到的，而 authing-js-sdk 是同时兼容 web 和 node 环境的，也会依赖一些 node 相关的包，所以在 webpack 的 node 配置选项中将这些包设置为 false 也能减小一些体积。

antd

antd 中的组件功能都是非常全的，所以体积也会稍微大一些，最好的办法是完全不依赖 antd，但是为了快速上线，我们先替换了一些比较容易替换的组件，就减少了一些用不到的功能的代码。

通过以上的一些优化，最后包大小分布图如下：

发现 antd 的依赖还是占了很大部分，React 版大小在 512KB 左右，其他版本的也都在 700KB 左右，所以如果将 antd 完全去除，还是能减小不少体积的。本次虽然没有一步到位，但也能使用了。

未来规划

Guard 是一个能够让开发者非常快速地接入登录界面的组件，后续我们会持续不断的进行迭代优化，也会在组件库中加入更多的组件，目前有以下一些规划：

可视化配置

后面我们会提供可视化配置功能，通过一些简单的可视化操作就能改变表单的外观、登录方式等配置。

继续体积优化

通过移除 antd 依赖，持续优化体积。

个人中心组件

增加个人中心组件，使开发者可以简单快速地展示用户个人信息。