近日，Authing 发布国内首个「持续自适应多因素认证」产品，也是国内首个持续自适应信任体系解决方案，为国产化零信任落地实施提供了一套行之有效地最佳实践。持续自适应多因素认证通过多种身份验证因素（如令牌、生物特征识别、验证码等），在用户访问全生命周期中，通过行为风险评估技术对用户的关键行为进行持续动态地实时评估。「持续自适应多因素认证」旨在帮助企业更高效、更精准、更全面的保护业务系统内的数据和资源的安全，延展企业信息安全管控纵深，同时解决用户体验与安全管理间的摩擦问题。 Authing 持续自适应多因素认证业务架构图 基础概念 如果你希望更详细了解三者区别，请看下文图中介绍。 根据 Verzion 数据泄露报告显示，约 81% 的数据泄露事故由凭证被盗而引起。而据微软数据显示，多因素认证（MFA）可以阻止超过 99.9% 的账号密码泄漏及相关黑客攻击。虽然传统的多因素认证在用户登录访问场景中已经非常普及，然而随着网络安全环境和用户需求变得愈发多元，企业符合信息安全合规性也越发重要，仅依靠一次性的身份认证来控制对敏感系统的访问已经不再足够，用户的安全状况可能在系统会话期间动态变化。此时企业需要有持续评估安全风险技术来对用户进行持续的安全系数评估，并基于该风险评估结果来自动决定是否需要增加额外的认证因素保护企业数据安全。 使用 Authing 持续自适应多因素认证将帮助企业快速构建面向未来的持续自适应信任体系，保障企业数据安全，同时还具备以下优势：   持续自适应多因素认证，延展企业安全防控纵深 随着业务上云、移动办公、生态协作、多云混合等业务场景的涌现，以及大量设备接入让企业的安全防控边界持续外延。传统的点状安全布控方式和传统的安全门式（允许/阻止）管理办法已经无法应对复杂多变的安全环境。 Authing 提供行业领先的「持续自适应多因素认证」解决方案。它将企业传统的“应急响应”静态防御提升至“持续响应”的动态安全管控。从形态维度，「持续自适应多因素认证」将安全管控从点状布控延展至企业全身行程一整套自适应安全免疫系统；从时间维度，「持续自适应多因素认证」在全用户会话旅程中根据实体行为的变化持续不断的对其进行风险评估，通过风险评估信号决定是否需要对该用户增加额外的认证流程。 几行代码即可接入，快速部署行业前瞻技术 Authing 提供非常便捷的自适应多因素认证集成方式，企业可以选择几行代码接入 Authing Guard 认证组件（Authing Guard 使用行业最佳实践安全性设计，仅需要几行 JavaScript 代码就可以集成到你开发的项目中。它可以直接从 CDN 或 NPM 加载，也可以从源代码构建。Authing Guard 同时提供 Javascript 原生、React、Vue 和 Angular 的多种集成模式，在你的任何项目中都可以无缝集成并享有高度自定义灵活性。）即可快速接入 Authing 自适应多因素认证功能。通过在企业业务系统后端接入 Authing SDK，将相关用户行为数据上报到 Authing 系统。最后通过 Authing MFA 编排引擎配置「持续自适应多因素认证安全策略流」，并通过对 MFA 事件进行持续监听，当接受到相关安全事件，即拉起 MFA 认证流程。 Authing 同时提供完善的改造已有 IAM/IDaaS/系统升级 Authing 自适应 MFA 的解决方案，企业无需额外花费巨额费用重新改造 IAM 系统，即可在多种终端场景下独立接入 Authing 的「持续自适应 MFA」。如果您希望更详细了解升级方案，请识别下方二维码预约咨询。 MFA 编排引擎，覆盖全场景安全管理需求 Authing 提供灵活的自适应 MFA 策略编排引擎，企业不仅可以依据自身业务情况，灵活配置 MFA 安全策略。Authing 还提供数十种开箱即用的预置策略函数模版与 MFA 安全策略模版，同时还提供： 1.提供完整且灵活的策略函数编排能力 支持灵活配置入参，接收任意类型数据进行计算 支持基于配置参数的复合条件数据过滤 支持基于配置参数与多种统计类型的数据指标统计 支持基于配置参数与统计结果灵活设置策略判定条件 支持灵活配置策略返回值 2.支持基于用户行为的策略编排 时间、地理位置、设备特征、网络环境、行为特征 3.支持基于主体属性的策略编排 例如用户在职状态 例如用户的组织、部门关系 4.提供自适应 MFA 安全策略流配置能力 API 模式：通过 HTTP 请求触发安全编排工作流，根据配置策略计算用户风险，并根据计算结果返回触发 MFA 认证策略。   事件流模式：通过持续订阅 UEBA 事件，每当有新的 UEBA 事件产生时，根据配置策略计算用户风险，并根据计算结果发布特定 MFA 事件。 减少用户体验摩擦，平衡安全性与生产力 传统的多因素认证最被诟病的问题之一则是用户体验，在微软的一项调查中，虽然绝大多数企业了解多因素认证的重要性，并且有能力部署，然而只有 22% 的企业选择使用多因素认证。其主要原因是传统的多因素认证为客户和组织内部员工提供了糟糕的用户体验。在用户流失和生产力阻碍前，企业通常选择关闭多因素认证来承担额外的安全风险。 从企业安全的角度来看，身份认证是实体证明其可信的过程，只有持续获得信任的身份才被允许进行下一步操作。而从用户体验的角度来看，无体感/弱体感的身份认证过程能保障用户的留存率和员工的工作效率。Authing 持续自适应多因素认证基于 Authing UEBA 引擎持续动态地根据用户的行为和画像进行分析和判断，例如用户的登录历史、设备信息、IP 地址、地理位置、活动模式等，从而确定当前用户的身份和风险级别，并选择与之相匹配的 MFA 认证策略。这将最大程度提升用户体验，并平衡安全性与生产力。 构建持续自适应信任体系，满足企业安全合规要求 零信任理念已经从“不信任任何人”转变为“持续获得信任”，只有持续获得信任的身份才被允许进行下一步操作。某个实体身份需要持续获得信任的条件是系统对其进行持续的风险评估。 通过 Authing 持续自适应多因素认证，帮助企业构建持续自适应信任安全体系。持续自适应多因素认证在用户整个使用旅程中持续不断地对其进行信任评估，以决定是否需要增加额外的认证流程，企业的安全得到了实时监控和防御，同时还提供完善的用户和管理员行为审计日志。Authing 遵从不同国家和行业的合规性要求，积极参与行业安全标准的制定和推广，为企业提供安全合规的身份认证访问服务。   如果你希望更详细了解 Authing 「持续自适应多因素认证」产品功能，请识别下方二维码或点击阅读原文申请产品体验白名单，我们将在审核通过后第一时间与你联系。 Authing 是国内唯一以开发者为中心的全场景身份云产品，为企业和开发者提供高安全、高性能、高生产力的用户认证和访问管理服务。 Authing 目前已经服务包括招商银行、三星集团、复星集团、长鑫存储、可口可乐在内的 40000+ 企业和开发者。  

随着全球互联网和数字化浪潮的不断发展，信息安全已成为不可忽视的问题，并随着日益复杂的国内外市场格局，其重要性更加凸显。我国政府也相继印发和实施了《数字中国建设整体布局规划》、《全国一体化大数据体系建设指南》等一系列政策，将核心技术自主可控、安全可靠作为维护信息安全的发展目标。 这些文件及政策是对指导未来信息安全建设的纲领性文件，对我国信息安全建设具有重要意义，对国内的软硬件开发企业也将产生深远的影响。《数字中国建设整体布局规划》中指出，要构筑自立自强的数字技术创新体系和筑牢可信可控的数字安全屏障，强化企业科技创新主体地位，增强数据安全保障能力。《全国一体化大数据体系建设指南》中提出，要从管理制度到技术能力实现一体化，建立健全面向数据的信息安全技术保障体系。在政策的指引下，国内企业积极推进国产化替代进程，不断增强信息安全能力。 如今的数字化时代，用户身份信息已成为各类应用和服务的核心数据，需要企业严格地保护和管理。身份领域软件涉及身份认证、权限管理等重要业务，在保护用户身份信息方面起着至关重要的作用，是企业保障信息安全的第一道屏障。因此，实现身份领域软件国产化不仅具有基础软件自主可控的重要意义，更是保护企业用户数据，维护信息安全的重要措施。 不过，身份领域软件国产化替代是一个大工程，不是一蹴而就的事。软件的可靠性、旧应用的兼容性、用户的体验差异、未来架构的适配等都是企业进行国产化替代的挑战。对于企业需要兼顾现在和未来的国产化替代诉求，Authing 作为新一代场景身份云，提出了逐渐过渡、用户无感知的国产化替代解决方案。 01.轻松替代微软 AD 在身份领域软件国产化替代之前，企业多以 Microsoft Active Directory（微软 AD）提供的本地化用户目录管理服务，管理着身份、应用和终端三个方面的资源。据统计，全球约有 90% 的企业使用 AD 作为内部基于目录的身份服务平台。 在应用云化、SaaS 化、以及国产化替代趋势下，采用 LDAP（轻型目录访问协议）、DNS（域名系统）和 Kerberos 认证协议的微软 AD 只能做域内的权限控制，有限的“云服务”对接能力，也让其与各个应用打通集成更加困难。 而且，企业依赖微软 AD 为所有业务的登录核心服务器，微软 AD 服务器与业务系统这样高耦合的应用场景，也让其在保护企业用户数据，维护信息安全的防范上，埋下牵一发而动全身的安全隐患，进而影响企业业务。 根据以上的对比分析，企业无论是借力行业趋势持续发展，还是更新信息安全防范策略，替换微软 AD 都已迫在眉睫。针对企业这些诉求，Authing 提出了“升级”微软 AD 的解决方案。   企业现有微软 AD 用户导入 Authing IDaaS目录服务。在微软 AD 域成员服务器上安装 Authing AD Connector 组件，通过此组件连 Authing，转发身份认证请求给 AD、并返回授权，让企业仍能基于微软 AD 的组织数据作为身份源。 用Authing IDaaS扩展微软 AD。Authing 支持 LDAP 、RADIUS、OIDC、SMAL、OAuth2.0、CAS 等协议，以及预集成 2000+常用软件应用，使用微软 AD 的企业无需完全的迁移和重构，就能借助 Authing 扩展身份认证和身份管理能力，快速实现单点登录。 过渡期进行身份惰性迁移，实现微软 AD 解耦。企业用户认证成功的同时，用户的账号和密码将被保存到 Authing IDaaS 目录服务，对身份进行惰性迁移。在惰性迁移成功后，企业可选择更换身份源，即完成对微软 AD 的解耦。 简单来说，就是初期兼容旧应用，未来适配新架构；平滑过渡无感知，用户体验无差别。通过 Authing 解决方案，企业可以轻松解决所有与微软 AD 相关应用软件的账号同步和认证问题，实现身份领域软件国产化替代。 02.基于信任体系的零信任架构 国产化替代不仅仅是在应用层面的取代，也涵盖了芯片、操作系统层面的探索实践。面对企业基于国产芯片、国产操作系统而开发的众多 B/S 端国产化应用带来的诸多挑战，Authing 的能力和价值也不仅局限于替代微软 AD 进行账号管理。对于如何实现账号的统一管理、如何建立设备的信任关系、如何保证业务访问安全、以及如何保护用户数据安全等，Authing 也已经做出了响应。 Authing 以数字身份为信任基石，参照零信任体系架构的最佳实践，构建了用户可信、设备可信、流量可信、应用可信的端到端可信链。通过统一身份管理与访问控制、软件定义边界组件、风险管理系统三大核心技术做支撑，为企业应用带来以身份为核心、业务安全访问、持续信任评估、动态访问控制四大关键能力。 目前，Authing 已助力高教社、复星集团等客户，稳定运行在阿里云、华为云、腾讯云、金山云、金蝶管易云国产云平台上。同时，Authing 也已在国产芯片、国产操作系统、国产数据库、国产中间件上进行了广泛的验证和适配，此外，Authing 还具备国家密码管理局商用密码检测中心颁发的《商用密码产品认证证书》，支持使用国密 SM1、SM2、SM3、SM4 等加密方式，为国产化替代提供全面的身份管理 03.最佳实践案例：解耦微软 AD，强化身份管理 国内某龙头 IDM 芯片企业内部员工超过 20000 人，使用 500+ 款应用，内部基于微软 AD 进行统一身份管理。该企业致力于动态随机存取存储芯片 DRAM 的设计、研发、生产和销售，拥有生产制造车间和众多高精度制造设备。现阶段微软 AD 不仅要管理生产制造车间的设备，还要管理办公区的设备，以及员工身份信息。 需求挑战 企业生产和办公共用一个微软 AD，AD 域参杂机器、员工等多种信息目录，存在出现问题相互影响的安全隐患和维护风险。 AD 域不够灵活，且操作配置复杂，普通的人事调动会产生大量的运维工作。 企业仍处于高速发展阶段，随着接入应用数量的增加，身份管理将成为未来的发展瓶颈。 解决方案 为了帮助该企业解决上述问题，Authing 基于事件驱动的云原生身份自动化管理平台提供了针对性的解决方案： 解耦 AD，让 AD 管设备、Authing 管身份 通过 Authing 同步中心，实现微软 AD A、微软 AD B 双域克隆，使生产制造区、安全办公区平稳切换，达到账号、用户组等信息保持一致——让 AD 域专注于管理设备、与业务解耦。 同时，再以 HR 软件作为身份源，以 Authing 为统一身份认证管理平台，把身份供给至下游 AD，建立统一的账号管理体系，“无痛”剥离人员账号管理。 与传统 AD 域不同的是，以 Authing 作为管理平台，能够实现对员工账号的全生命周期管理，从创建、转移、权限、销毁等阶段，支持一键开/关权限，大大减少 IT 重复操作的工作量。 巧用API，让 IT 省时、企业省钱 Authing 支持多种 API/SDK 提供 IT 人员自由调用，只要基于标准化协议，即可迅速完成现有应用及未来新应用的配置，无惧 B/S，C/S 结构及多终端认证方式。比起以接入的应用计算价格、分别开发，搭配开发文档使用 API 不仅学习成本低，还能在集成所有系统时达到统一复用、一劳永逸。 如果你希望了解更多国内先锋企业的国产化替代实践案例，请识别下方二维码下载白皮书。 Authing 是国内唯一以开发者为中心的全场景身份云产品，为企业和开发者提供高安全、高性能、高生产力的用户认证和访问管理服务。 Authing 目前已经服务包括招商银行、三星集团、复星集团、长鑫存储、元气森林在内的 40000+ 企业和开发者。  

零信任安全治理理念不再是陌生的话题，随着社会面临更复杂的信息安全风险，不断变化的网络环境使得基于边界的安全架构不再具备抵御内外部安全威胁的能力。传统的以网络中心化的安全体系架构也逐步过渡到以身份为中心的网络访问控制理念。 基于零信任理念衍生的安全管理框架也在逐步贴合更多的安全管理需求，例如如何平衡用户、员工与安全管理间的摩擦问题。过渡代偿式的安全管控会造成糟糕的用户体验，增加用户的流失率，同时降低员工的敏捷性，增加运营成本，直接影响就是降低业务收入。 根据 Verizon 数据泄漏调查报告显示，81% 的黑客相关泄漏事故都是因为凭证盗取造成的。过去传统的安全治理办法是添加更多的身份认证流程，例如在帐号密码单因素认证下添加第二种认证因素，短信/邮箱等验证流程，这种办法被称为 2FA，即双因素认证。然而这种办法并不能有效解决此类问题，不法分子会通过钓鱼网站/邮件/短信等手段获取相应的 OTP 指令或者建设伪基站来劫取验证信息。​ 在此基础上，2FA 也迭代成 MFA，即多因素认证，在 OTP 指令的基础上增加了生物特征识别技术，例如指纹、人脸等。这种办法能有效解决上述问题，但也同样衍生出新的问题，受限于设备（例如设备需要支持指纹和人脸识别）、技术等客观因素，并不能有效覆盖认证的所有场景。同时增加不必要的因素认证流程会增加用户体验的负担。 「自适应多因素认证（AMFA）」在传统多因素认证（MFA）的基础上根据上下文判断当前的安全状况以确认是否需要增加多因素认证。通过判断用户属性、上下文行为、ip 地址、设备信息、地理位置等多种「要素」动态评估风险。例如当用户异地登录时或者异常 ip 登录时添加多因素认证，而当用户在常用的设备以及公司 ip 登录时则无需二次验证，这有效解决了用户体验与安全管理的摩擦问题。 然而，「自适应多因素认证 AMFA」 虽然有效解决了上述问题，但对于安全环境更复杂以及对于安全审计有特殊要求的组织来说，仅在安全敏感节点设置点状的一次性自适应 MFA 并不能全面覆盖企业内所有潜在的安全风险，此时，「持续自适应信任（CAT）」作为下一代安全管理模型被提出，而基于自适应信任框架的「持续自适应多因素认证（CAMFA）」则是解决上述问题的最佳实践。本文将介绍什么是持续自适应信任以及如何实现持续自适应多因素认证。 Gartner：将焦点从 MFA 转移到持续自适应信任（CAT） 一.什么是持续自适应信任（CAT）？ 持续自适应信任（Continuous Adaptive Trust, CAT）是一种基于动态信任评估的安全模型，旨在实现对数字化生态系统中的实体（如人员、设备、应用程序和服务）进行持续监测和自适应信任评估，从而有效地识别和响应威胁。CAT 模型的核心思想是基于实体行为和可观测数据的实时分析，借助机器学习、人工智能等技术，对实体的行为进行动态评估，并根据评估结果来调整对实体的信任级别。CAT 模型具有高度自适应性和灵活性，可以根据实体行为的变化实时调整信任评估策略，从而更好地适应不断变化的威胁环境。通过实现持续自适应信任评估，CAT 模型可以有效地提高数字化生态系统的安全性和可信度，保护企业和用户的数字资产和隐私。 1.从“应急响应”到“持续响应”，持续自适应信任构建企业安全免疫系统 举一个更易懂的例子。「持续自适应信任」在微观层面类似生物自身的免疫系统，在宏观层面类似一套完整的生态系统。生物的免疫系统可以对新的安全威胁自主地快速做出反应并进行调整，而生态系统则是孵化生物的基本条件，丰富多元的生态系统可以帮助生物适应更复杂的环境以及造就更强大的免疫系统能力。 换言之，依靠丰富多元的 IT 基础设施能帮助自适应信任构建更强大完善的自适应信任体系，所以持续自适应信任并非单一的产品或解决方案，它需要一套完善的全场景用户访问认证功能以及权限管理等能力，才能更全面的保护企业信息安全。 过去传统组织依赖预防和基于策略的安全控制，部署防病毒软件、防火墙、入侵防御系统（IDS/DPS）等产品，而这种办法已经不能适应如今和未来的安全环境。Gartner 提倡为了实现对更复杂威胁的防控，建议将安全思维方式从“应急响应”到“持续响应”转变。下一代的安全保护流程的核心是持续、普遍的监控和可见性，企业的安全监控应该无处不在，并尽可能多的包含 IT 堆栈层，包括网络活动、端点、系统交互、应用程序事务和用户活动监控。 2.从零信任延展至持续自适应信任（CAT） 零信任的三个主要原则“默认不信任任何实体（人、设备、软件等）”“始终持续验证”“执行最小特权”，在零信任架构中最主要的两个点： 认证：收集和分析信息来建立对实体的信任级别 访问控制：根据身份信息和信任级别控制实体对资源访问权限 从企业安全的角度来看，身份认证是实体证明其可信的过程，需要基于丰富、持续、准确的数据源为基础。而从用户体验的角度来看，无体感/弱体感的身份认证能保障用户的留存率和员工的工作效率。 由于开启零信任之旅需要首先解决零信任认证问题，所以在没有有效的零信任方案前，很多组织为认证过程添加弱因素认证，有技术能力的组织会在一些敏感节点添加多因素认证以及单点登录来试图保障安全和用户体验的平衡，但由于无法实现在用户会话过程中持续动态的评估和认证，通常会采取设置长会话计时器来减少多因素认证的频次。 无论是在各类敏感会话场景中增加多因素认证流程或者是添加会话计时器等方式，本质上都不能有效解决安全和用户体验的问题，反而会增加企业安全支出并且影响用户体验。 这些问题都是组织在实施零信任过程中将零信任三个原则简单的理解为增加更多的认证流程或者对每个认证环节增加因素认证。事实上，将“零信任”的理念换个角度思考就是“持续获得信任”，只有持续获得信任的身份才被允许进行下一步操作。某个身份需要持续获得信任的条件是需要系统持续对其进行风险评估，而为了要保障用户体验，这些评估需要用户无体感的执行，这时，就需要持续的自适应信任（CAT）。本质上，持续自适应信任是基于零信任理念的最佳范式。 二.持续自适应多因素认证（CAMFA）构建企业零信任环境 如文章开头所述，自适应多因素认证（AMFA）能有效解决用户体验和安全管理摩擦问题，但审计监管机构以及企业安全和业务部门对 MFA 的要求也越来越高，他们希望寻求安全性更高、更灵活、响应更快、用户体验更好以及成本更低的 MFA 解决方案。 1.什么是持续自适应多因素认证（CAMFA） 「持续自适应多因素认证（Continuous Adaptive Multi-Factor Authentication，CAMFA）」是一种安全身份验证方法，它在自适应多因素认证（基于上下文属性判断当前安全状况以增加因素认证）的基础上增加了实时风险评估技术对用户进行动态评估安全系数。在时间维度上，持续自适应多因素认证在用户整个使用旅程中持续不断的对其进行信任评估，以决定是否需要增加额外的认证流程。这样做的好处就是企业的安全得到实时监控，而用户只会在进行风险操作时被提示需要进行额外的认证。 2.持续自适应多因素认证（CAMFA）对企业的价值 身份认证是企业安全的基础，在安全监管要求下，从传统的账密登录转向多因素认证（MFA）是必然的趋势。然而根据微软的网络信号报告显示，只有 22% 的 AD 身份使用了 MFA，其最主要的原因是，传统 MFA 为客户和组织内部员工提供了糟糕的用户体验。在用户流失和生产力阻碍面前，企业通常选择关闭 MFA 来承担额外的安全风险。 而自适应多因素认证（AMFA）是平衡安全和用户体验有效方案，然而和传统多因素认证（MFA）一样，对于面临更复杂的安全环境和有特殊安全监管需求的企业来说，仅用一次性的身份认证来控制对敏感系统的访问已经不再足够，用户的安全状况可能在系统会话期间动态变化。此时企业需要有持续评估安全风险技术来对用户进行动态安全系数评估，并基于该评估来决定是否需要增加额外的因素认证。 3.通过持续自适应多因素认证（CAMFA）为企业实施零信任安全环境 持续自适应信任体系能确保企业实现真正意义上的零信任安全环境，而实现持续自适应信任体系的最佳实践则是实施「持续自适应多因素认证」。通过持续自适应多因素认证提供持续风险评估能力来判断外部风险信号和内部数据，同时基于「持续自适应多因素认证」的策略引擎来根据组织设定的安全策略对这些风险信号和访问请求进行评估。 零信任安全模型通常包含一个策略引擎，该策略引擎用以接受风险信号和相关数据，以及配置安全策略和执行安全策略。通过结果判断是否需要触发多因素认证。 4.如何快速为你的企业构建持续自适应多因素认证？ 值得注意的是，企业实现持续自适应认证，策略引擎必须能够连接上下文数据与用户和设备等实体关联起来，而保障其决策准确性的前提就是能够拓展到更细粒度的身份上获取更多数据作为依据。同时为了提高拓展性、灵活性以及持续性，该流程必须是自动化执行的。而需要实现上述能力的关键是企业的身份访问与管理系统具有可编排的自动化能力，同时也需要具备元数据能力来统一不同来源上报的行为数据的标准，通过自动化编排能力将整个身份验证流程串联，以实现持续响应的自适应多因素认证。 Authing 提供基于身份自动化编排引擎的「持续自适应多因素认证」。自适应 MFA 认证策略底层基于 Authing UEBA（用户或实体行为分析技术），可以针对用户行为和用户画像进行深度梳理分析，从而自动选择与当前行为相匹配的 MFA 策略。 在自适应 MFA 认证策略中，Authing UEBA 引擎会根据用户的行为和画像进行分析和判断，例如用户的登录历史、设备信息、IP 地址、地理位置、活动模式等等，从而确定当前用户的身份和风险级别，并选择与之相匹配的 MFA 策略。而持续自适应多因素认证（CAMFA）是在自适应多因素认证(AMFA)的基础上加上 Authing 身份自动化编排引擎。 Authing 持续自适应 MFA 业务架构图 当用户的业务系统接入 Authing 后，从业务系统后端上报的 UEBA 数据到 Authing 系统，通过在 Authing 配置的持续自适应 MFA 安全策略流，在订阅安全策略流发布的事件后。此时自适应安全策略将持续对 MFA 事件进行监听，当接收到 MFA 事件后，将执行相应的安全策略。 如果你希望更详细了解 Authing 「持续自适应多因素认证」，请识别下方二维码或点击阅读原文申请产品体验白名单，我们将在审核通过后的第一时间联系您。 扫描二维码，预约体验 Authing 是国内唯一以开发者为中心的全场景身份云产品，为企业和开发者提供高安全、高性能、高生产力的用户认证和访问管理服务。 Authing 目前已经服务包括可口可乐、招商银行、三星集团、复星集团、长鑫存储海底捞、知乎在内的 40000+ 企业和开发者。

Authing 是用户中心团队，我们是业务系统，大家冲刺一个目标、再做合并，然后让基于多租户的 B 端产品成功上线。那个阶段刚好有个客户卡在当时的时间点，一定要赶着上线，最后 Authing 的协作让我们赢得了客户信任，还是很振奋人心的！—— 风变科技 CTO 吴亮亮 在线教育行业一度淡出了创业者的视野。 经历过政策的调整和行业的震荡，转变内容方向、转变客户人群、转变垂直领域，是大多数相关企业的做法。 有这样一家企业，面对大环境的挑战不变初心、逆风而上，被视为业内“黑马”。他们深入研究“学习”的本质，用技术和服务让用户无痛化、沉浸式学习，编程课程一度霸屏朋友圈。随着 C 端流量成本高涨，他们也积极探索 B 端业务，尽管在探索中历经坎坷，但也率先跑出领域内的新模式。 他们就是风变科技，这次的对谈人正是风变科技 CTO 亮亮。 音频版本已经在 Authing 品牌播客「黑客与画家」中发布。 Q1： 您为什么会想到进入在线教育行业创业？当时和 CEO 怎么相识、并决定创立风变的？ 我们创业这件事是从大学开始的，那个时候我们算是第一波校园微信公众号开发者。创业做什么呢？其实就是为同学们在微信公众号上提供校园服务。比如说查成绩、查课表、表白墙、找老乡......各种各样的校园应用。因为有这样的校园应用，就会让我们离用户很近，每天在思考怎么给身边的同学提供服务。 我当时搞了很多黑科技，比如学校的教务系统，一到期末考试结束大家都查不出成绩，但是我做的公众号可以查到成绩；比如课程表，我会用公众号推送给他，你明天要上什么课，还有单双周等具体信息，提醒服务做得非常到位。那个时候做了很多很有趣的事情。 那时我们 CEO 也在做校园公众号，他不是技术性的运营者，但是他也成了他们学校里最大的公众号，所以他就想要找一个会写代码的 CTO，说有一个绝妙的想法、就差一个 CTO 了，所以来找到我，“骗”我给他免费写代码。他当时说项目特别好、跟腾讯合作，然后我们发现都是安徽池州老乡、也有信任基础，说做完请我吃池州最贵的大餐，加上志趣相投，就开始一起了。 其实也没想太多，因为大家都是非常优秀的创业者，我通过我的方式做到了我的校园里最大的公众号，他任何代码都不会也能做到最大，然后我们还有一个合伙人也很厉害，擅长做运营和市场。我们三人，CEO 是资源型选手，CMO 是市场运营型选手，而我是产品技术型选手，就组成了非常完美的团队。 创始团队早期合影 那时我们先做了一些没法商业化的校园项目，比如云打印，给打印店老板的电脑上装上驱动、学生可以在微信上面直接下单，打印机就开始打。还有类似校园版的“在行”，花几百块约见一个行业大佬，当时产品名叫“经验盒子”。我们一直在思考，校园里有哪些需求应该被解决，后来我们发现，其实学校里面真的什么都不缺的，缺的是更高质量或者、更符合年轻人和当今社会的教学资源和学习资源。 后来受《社交网络》和乔布斯的影响，我们还在学校旁边租了一个别墅创业，希望能成为一家超越 Facebook 和苹果的公司。那时候创业比较确定的方向是做成年人的教育，第一款产品叫熊猫书院，它能帮助大学生或是已经毕业了很多年的职场人，快速地在一周内精读一本书。 我们通过微信、公众号、微信网页开发，通过社群运营形成班级，当时有各种各样的科技园一班、二班。我们把内容提供好，然后大家在微信里完成了组队读书。那时刷爆了朋友圈，一个月收获 100 万用户和 100 万收入，于是 2016 年还没毕业我们拿到了 750 万融资，也从厦门搬到了节奏更快的深圳。我记得非常印象深刻的事就是毕业典礼，我穿学士服跟校长握手的时候，还在修代码、修 bug。 整体就是这样一段经历，从校园里做读书学习产品，到深圳创业，然后走上了学习教育的创业路线。 Q2. 风变准备如何改变现有的教育行业？和其他在线教育企业有何区别？ 准确来说，我们不算是传统意义上的教育公司，而是一家聚焦于教育技术的互联网公司。我们一直思考的是用产品、技术或者是用互联网的方式来去做不一样的创新。我们公司名叫风变科技，英文名叫 for change，就是为了改变一些事情，因为我们觉得这个世界和社会虽然很好了、但可以变得更好。 哪里可以变得更好呢？ 在学校里我们能学到专业的历史沉淀的知识，那未被满足的，是更加符合今天情况、更实用性的知识。所以我们才选择了从畅销的新书籍、新理念或者文化、方法开始，我们希望能把新的东西教给大家。 传统教育大家认为一定是年长的人才能去教，但这些新事物反而是我们年轻人学习能力更强。像我自己是非常喜欢学新东西的，而且我也会带着公司各个部门的同事都去学。举个例子，比如说我们最早期做风变编程这个产品，我不是教公司工程师去写代码，而是教内容运营、甚至是HR。然后我们发现对他们来说真的很有用，这时我们才把产品面向 C 端消费者开。所以说，好的教育我觉得是来源于人们真正地学会它、而且能实际应用到工作中。 很多云课堂等，就是把视频的教学资源放到网页上，这明显不是教育、不是真正的学习。学习要思考的问题是很多的，比如我们要去研究一个人为什么能够静下心来去学习，线下和线上完全不一样。其实我们一直在思考，怎样用技术去研发一个专门针对于学习者在线上完成学习的整套应用。 这个问题我们要从三个角度去思考，一是交互体验，二是数据，三是人工服务，我们始终在想着说把交互体验和数据智能和人工服务结合在一起，所以我们研发了大量的工具，甚至是自己写了一些平台和对应的编程语言，术语叫 DSL。 如果通俗易懂地说，我们的教育是缺乏 SaaS 的，只提供一个播放教学视频的线上平台，这不叫 SaaS，没有服务、也没法保证客户成功。一般 SaaS 服务 B 端企业，我们就是面向 C 端的。我们会在各个领域做出专属的教育 SaaS，让每个用户能够轻松地学会该领域的知识。举个例子，你要学量化交易，量化交易一般是由实时的股票大盘加上你的编写策略组成，编写策略一般是用 Python 去写的控制台。那这样的工具离普通的用户是非常远的，这时我们就得先把工具研发出来、然后再教大家理念知识。 可以理解成，我们要给每个学科修建一个多媒体教室。比如我要教你 PS，你的电脑上需要装好一个 PS；当然我们不教 PS，像我们会教 RPA 流程自动化，我在教你的过程中，你的电脑上一定已经安装好跟我一模一样的环境了。我说现在需要用 RPA 软件来控制你的微信群发一条消息，这时你的电脑马上就可以打开 RPA 工具和微信，跟着我教学的节奏实操就可以完成。 同样，2018 年为什么我们上线的 Python 编程课在朋友圈刷屏，就是因为大家只要打开一个网页，然后就可以跟着里面有一个智能的老师学习，那个老师叫吴枫，头像其实就是我的头像。 在这样的环境下，我们思考发现的问题是，好的技术离初学者是有门槛的。这个门槛来源于装环境或者一些非常复杂的工具的上手门槛，我们其实就是希望能够通过降低门槛，让大家能够快速去学习。比如说现在 AI 绘图很火，有 midjourney 这样的一些软件，但是你就发现，要玩转 stable diffusion 你的 GPU 要非常好或者显卡配置强，midjourney 你需要有美元信用卡去支付。我们要去教大家去使用这个技能时，这些东西我都给你解决完，我直接做了一个网页，在网页上直接输入你的提示词，就可以开始 AI 画画，这个东西我们内部叫 AI 艺术家，能帮助大家快速上手。 我们不断在思考如何通过软件工具降低大家的学习门槛，让学习无痛化、做到沉浸式交互式学习，让大家学完、学会才是我们的目标。 Q3. 仅到 21 年年中，风变编程的学员就已经突破 400 万人，当时也引发了诸多友商的加入，最后还是风变拔得头筹，你们内部盘点下来，可能的原因是什么？现象级产品背后是怎样的增长思维？ 我们做风变编程是 18 年开始的，19 年迅速增长，到 19 年下半年就有大量竞品来直接对标我们的产品。 B 端 SaaS 产品里有个东西叫 PLG（Product-Led Growth，产品驱动增长），在营销里有“增长黑客”，其实我们公司是把这两个东西做了一定的理解，然后实操应用。我们每一个产品在最早期的时候，都能够出现 PLG 这样的表现，再加上增长黑客的一些技巧，能够让它出现裂变式传播这样的效果。 像我最近在做的一个 AI 站点，一周时间用户日活到了几十万。大家觉得这个事很困难，但对我们没这么困难，原因是什么呢？很多做营销做得好的团队，产品技术跟不上，很多团队产品技术做得好，可能市场营销又缺失了。他们的知识体系有所缺失，而我们公司是很完整的团队，一旦一个产品做得好，市场运营就会把它在市场上大规模地去放大。里面可能需要借助一些营销裂变策略、广告投放，然后广告投放里又需要更精准的用户、种子人群，再加上竞价策略等，里面有很多细节、不是只要花钱就行。 而在这些背后，最重要的点，就是数据。你一定要让公司里面的每一个工种都能够有数据看板或者数据化的一个指标，这样的话他们才能去做优质决策。就比如说广告的投手，他能够看到数据；今天做增长黑客的运营，他能够看到现在的裂变系数是什么样子，什么时候需要去放大流量、什么时候要去做一些变量调控，里面有大量的 ABtest，这个背后其实都来自于技术的支持。最早期的时候，其实我们也没那么智能，就是我写 SQL，每天大家看数据的表现，后面才引入了非常多的工具链做面板和数据追踪，搭建出完善的数据体系。 在数据之外，当时能起来也有外部因素，因为朋友圈广告刚开始，我们对于这块广告做了数据追踪和快速跟进，也就抓住了微信大规模去推朋友圈广告的红利期。创业确实也是有窗口期的，能力之外，也需要一些运气。 这里也说下为什么选 Python 教学。一是我个人原因，当时在公司极力推广 Python，在公司里拉了一个微信小群一起学，还搞了Python 学习基金，学的同时一起吃东西、一起玩。我们认为未来应该每个人都去学 Python，今天 ChatGPT 很火，更加验证了这件事。今天我们把 AI 工具用好，可以帮你写邮件、翻译、写文章，但没办法帮你处理 Excel、没办法帮你从一个地址库里批量提取手机号等，不能直接帮你把工作处理完。这些工作，你现在如果写一段 Python 给 ChatGPT，它就能马上运行，因为 Python 是人类和 AI 之间最好的通讯语言。 Q4. 现在 C 端整体流量变贵，也看到你们早早从 C 到 B 再做跨界的尝试，是否有踩过一些坑可以分享给大家？ 2021 年我们就开始去积极拓展 B 端了，起初 B 端产品的设想是，能够让客户用低代码的方式，创造一个和风变类似的交互式课堂，当然也遇到了一些困难。 举个例子，我们刚开始推广的时候，是把我们自动化教学的技术变成一个 SaaS 平台，再去向其他的教育机构或者从业者提供服务，直接去卖软件作为服务。开发者们都有订阅付费的 SaaS 梦，我也非常喜欢做软件，所以早期我带了三四人的小团队快速把软件探索出来，给一些潜在客户和朋友分享以后，大家觉得很惊艳。 于是投入团队正式开始研发和商业化，那这时候困难就出现了，核心是客户理解或者说客户教育——如果你这个产品需要客户被教育，那大概率上你就不要再做了，因为你在中国没有能力教育市场。而且用户会从他们的角度思考问题、期待软件按他们所理解的样子去写，但软件不一定能完全遵从用户直觉的理解，因为有非常多的工程问题、成本问题，或者难以落地的情况，里面会有巨大的鸿沟。 这个产品早期还有硬性的问题，就比如企业没有投入人力去支撑，那就很难支持下去，因为他的上手门槛比较高，国内上市上手门槛高的话，客户去使用你、产品做推广会遇到很多挑战。 当然这个事也回过头给了我们一个思考，我们现在做的很多教学是依托于工具和软件的。举个例子，比如我们和 RPA 厂商合作推出 RPA 课程，其实我们就是在帮厂商去做客户教育。我觉得中国的软件市场是非常需要风变这样的公司的，像 Authing 这样优秀的身份云产品也需要客户教育，我们用 Authing、内部的工程师就是我去教育的。我们有一天或许可以做身份的课程、去布道身份云，让更多人用上好产品。 说回当时的情况，在中国做 SaaS 太难了，我相信所有做 SaaS 的软件从业者都有这样的体感。后来我们反思，不应该把软件单拎出来思考，因为风变最擅长的是整合内容资源、产品技术资源、运营服务资源，所以我们后来是把好的内容 + 好的工具 + 运营服务，以一整套向行业的从业者提供服务。 简单来讲，合作伙伴们需要好的课程、手上也有一些渠道或者流量，我们非常愿意开放给他们去推广。这是我们 B 端沉淀下来的路径，大家既可以向我们采购课程、又可以一起联名共建课程给客户提供服务，我们在后面提供强有力的支持。 做 B 端产品也很难。 我们做 C 端产品，我觉得做得已经很好了、那么多用户都满意，那 B 端应该不会有问题。但我发现 B 端是另一个思维方式，我们 C 端产品高度标准化、但 B 端高度定制化，会有不少产品需求不在我们的后期路线图中，这时候就需要做抉择、甚至有时要婉拒客户。 其实在 B 端领域，大部分公司虽然也想做标准产品，但优先是想活下去，所以经常要选择定制化。我们有 C 端业务支持，压力会稍许小一些。 然后 B 和 C 你都要敏捷迭代，我们都是标准的 Scrum 流程做项目管理。差别点是说用户故事的来源，B 端你用户故事更多来源自客户或者销售的口述，你对用户故事的筛选的把控力要做得更强。C 端经常不是用户来提需求，是我们通过大量数据的观察、或是对于产品的思考得出的，更多是产品经理思考出的需求。说实话 C 端做产品更轻松，因为自主可控性会更强，B 端会面临客户的压力，比如询问你功能何时能上线。还有，管销售团队并不轻松。 一是大家思维方式比较难对齐，二是我没办法直接帮助他们。原来我帮助 C 端运营，就是把产品和工具做好、把用户体验做到极致；但是 B 端产品定制化并不合适，另外还需要我去参加社交活动拓展资源，我觉得在这块我不是高手，当时 2021 年我每周基本都要出差飞好几个地方，后面还是觉得没做产品来得实在。 最后沉淀下来，招 B 端销售我们有个总结——如果他自己对产品的理解、对市场的拓展是独立的，他就是不需要管理的精英销售，也是我们现在的销售画像。作为老板，我能做的事情就是在外面找机会再对给他们。 今年因为 AI 搞得很火，所以我这边就会有很多资源过来，我就转给到市场销售团队去做好承接，就非常舒服。 当然，我们还是重 C 端的公司，B 端收入占比较小，所以压力会更小；如果纯 B 端公司，可能只留下一小撮独立销售还不够。 最后，我觉得心态层面也有坑。在你不清楚了解一些事情的困难的时候，我们都会有自我增强，特别对像我这样的创业者，容易过度自信。不是鼓励大家不去尝试，而是说我们应该更加及时地去观察到你当下的状态、不要太轴、不要觉得自己无所不能，哪怕你是一个超级个体、是超强的 CTO 或者 CEO，你都要及时去停下来审视一下今天的状态。尤其是节奏要调整好，先要让产品更加完善，比如说今年我们再去做销售和市场扩张，加大投入其实会更好，不能操之过急。无论是 B 到 C 还是 C 到 B 的跨界，都是有风险的，要谨慎对待。 Q5. 从 C 到 B、在具体技术研发侧也会遇到一些新场景，作为 CTO 你是如何解决的？ 当时几个人能快速把 B 端产品推上线，也是非常依赖于 Authing 的。 你可以想象下，我一周内上线一个 B 端产品，权限体系就不可能开发得完。其实最早期，产品在打磨阶段的时候都是本地版本，没有接账号体系，可以理解成 MVP。那时我们也在融资路演，我们要快速把 MVP 推到生产环境，于是就赶快接入了 Authing 的登录认证，用户可以使用了。 通过 Authing 快速上线身份体系 后来我们发现，其实这个场景最终应该是一个多租户的场景，我记得 Authing CEO 谢扬提过多租户在产品路线图上，因此我们做了沟通。当时我记得，Authing 非常快地组建了一个小团队去冲刺需求，我们两边一起开会过需求文档和产品技术方案。那时候我甚至感觉，我们像一个公司的两个团队，Authing 是用户中心团队，我们是业务系统，大家冲刺一个目标、再做合并，然后让基于多租户的 B 端产品成功上线。那个阶段刚好有个客户卡在当时的时间点，一定要赶着上线，最后 Authing 的协作让我们赢得了客户信任，还是很振奋人心的！ 我可以讲下我们 B 端产品的模式。我们作为平台方，客户他们需要一个独立的站点，有他们独立的管理系统和独立的 C 端界面，用来管理他们自己的学员。所以我们要服务好这些 B 端客户，再让他们去服务他们的 C 端客户。其次，我们现在部分的客户不是直接订阅我们的产品的，不是你买我这套系统多少钱；而是客户在我们这个平台上上线了一些课程，之后他去售卖的时候，我们会通过它的用量从这里面去做一定的分润，是这样的模式。 Authing 多租户架构，为风变提供 B 端课程分销底层系统 这对我们和对客户来说都非常的友好，它不需要付一大笔平台的软件服务费。这也不算是我们传统意义上所理解的分销，而是一种新型的按照商品售量的计费模式。而且今年 AI 越来越火，可能大家越来越希望有一些 AI 课程，所以我们平台的用量还会持续上涨。 其实不止外部客户用，我们公司内也在用这套多租户架构。我们公司内部有很多个团队，不是传统的部门制、有点类似阿米巴的模式，每个团队都是独立结算的，可以算作一个子团队、甚至子公司了。所以每个团队都会有自己的租户、域名、账号体系、管理员权限、团队成员权限等等，多租户就可以解决我们很多的管理问题。像我们原来的系统可能会非常依赖于总的 admin，现在的多租户体系让每个团队的独立性变得更强，自主的权限分配变得更加灵活。 多租户可适用于大型复杂组织内的身份治理，风变用于建设类“阿米巴”管理架构 现在我觉得每个系统都应该天然多租户，这样的话后面的拓展性可以变得更强。Authing 的多租户值得大家去尝试，因为大部分的工程师不能把多租户系统写得很明白，因为首先就要有基础的登录注册和权限控制，光是 RBAC（基于角色的权限管理）能写明白的工程师就不多；之后要设计多租户体系，租户里要绑定多种身份源，比如微信登录、GitHub 登录都要考虑，那这个管理后台就很难设计了对吧。然后你的 API 设计也很难，数据结构分离也是很麻烦的事。 实话说，2020 年我们公司内部做过权限管理系统，全都是我的一个 Java 团队，大概前后端加在一起 6-7 个人，做了大概 8-10 个月的时间，那个时候就是因为不认识 Authing CEO 谢扬，就没有去了解到这款产品。如果提前知道，就不选择自建团队了。 而且，会做权限的基本是老牌的程序员，Java 技术上可能是他们比较擅长的，所以我们当时选 Java 团队来做权限系统。但是我们公司原来的技术栈有 Golang、Node.js、Python，所以为了这个团队又引入了多语言技术栈，搞得我现在维护这个 Java 的项目还是挺麻烦的。 其实我觉得，未来像我们这样的公司就应该更多专注于做你擅长的业务领域的事情，不要老是天天因为软件而搞得大家很难受，技术是用来去解决问题的，云原生才是未来。 识别下方图片二维码，下载 Authing 多租户解决方案。 Q6. 过去在线教育经历了部分风波，现在 AI 又会带来新的革命，从过去到未来，你们是如何看待行业发展的？会怎样去应对和迭代？ 我觉得教育是持续值得做的事情、是长周期的，它不会因为政策或者风向出问题。当我们决定要做教育的时候，从来不会想着说踩风口，都是以 10 年甚至 20 年去看待这件事的。 所以我不认为一些市场波动会对我们造成什么影响，我们只会思考未来的教育应该是什么样子、今天的技术在教育上还有哪些值得应用的地方。然后我们也发现，教育的知识层出不穷，而且都是围绕工具展开的，所以我们也不需要着急说用一套技术解决所有问题，可能是去一个一个地做。像我们教量化的时候，做了量化工具，教 RPA 做了 RPA 工具，教 AI 做了 AI 工具，每一个端口上我们逐步做、然后再把共性的东西整合在一起。 而面向未来的 AI 时代，风变还是会坚持做三个方向上的事，第一是让好的 AI 工具能让更多的人能快速体验上、学习上。第二是持续做更好的内容，跟着我们的内容学下来，质量、学习效果、学习体验都是市场最佳。第三，风变的课程都有配套的运营服务，因为教育是有温度的，是离不开人的，哪怕你技术和产品内容写得再好，还是要有人去服务的。 今天如果大家学去学 AI 技能，你需要去思考的事是怎么利用 AI 变成超级个体，去能够开展自己的创业和副业。或者说，今天国家在大力推广数字化，政府有关部门也会颁发一些等级和能力认证，我们都会努力去做这样的打通，让大家学有收获、甚至拿到有含金量的证书、去升职加薪。这里有打个广告，大家在朋友圈看到风变的 AI 课程，值得去体验一下： 链接：https://ai.aigcfun.com/ 其实，我们不仅仅是把 AI 集成到我们的学习系统和课程里面，我们还会把这样的能力上架到 B 端的教学工具，每个做教育的都可以用我们产品作为工具，简单来讲就是做教育的独立站，同时你的独立站里可以集成一个 AI 老师。这是我们在做的事情，也在训练垂直领域的模型，比如说教医学的，教金融学、教哲学，这些语料集我们也在做。 推荐阅读 XRSPACE 总经理刘冠廷：元宇宙行业如何通过 2D、3D 联动，实现高速用户增长？ Authing 全球视野助力快用云科扬帆起航 ｜ 客户案例   Authing & 非夕科技｜助力先进制造企业树立数字化安全生产力标杆  

在经历全球范围的疫情冲击后，疫情对企业数字化转型的影响已经从初期被迫式、局部场景的"云办公"转化为长期深远地全场景影响。加之近年中美技术加速解耦，以及信创政策的加持下，中国企业在数字化转型中使用本地化解决方案代替原有的外企套装软件的情况正在加速。同时以  OpenAi 为主导的人工智能领域地突破，种种因素给企业数字化转型到来的新的难题和契机。 数据显示，在经历疫情后，中国企业数字转型成熟度稳步提升，转型成效显著的领军企业营收增速达到其他企业的 4 倍，国有企业和大型集团作为排头兵已经进入数字化转型的深水区和分水岭。数字化转型是涉及企业全业务、跨职能的系统性长期工程，数字化转型没有“银弹”，更不可能一蹴而就。 据统计，超半数企业由于缺乏前瞻性布局，经历大刀阔斧的转型后，数字化价值效益不明显。本文将剖析集团型企业数字化转型现状与难度，以及如何通过构建集团身份中台以及多租户架构，提升大型集团及下游子公司管理效能，并为集团构建适应未来发展的数字化身份基础设置。 01.集团型企业数字化管理现状洞察 集团型组织通常具备下游企业众多、业态丰富、层级复杂、跨多区域、人员庞杂且变动频繁等特点。同时由于集团型组织中的 IT 力量分布在旗下各子公司的各层级单位，并因不同子公司业务、区域、技术力量等客观因素的限制，导致在数字化建设过程中各子公司数字化转型的认知、侧重、程度等多方面存在差异，子公司与子公司间孤岛式搭建数字化体系，各子公司内部也是烟囱式构建数字化系统。这些因素进一步导致集团数字化转型面临以下挑战： 1.集团信息化较早、程度较深，老旧系统和传统的管理流程难兼容新数字化建设理念和需求 集团型企业通常信息化建设较早，程度较深。但由于早期信息化过程通常使用大量的套装软件以及主要依靠外部供应商提供信息化咨询和系统建设。在新技术加持的数字化转型背景下，集团内部的老旧系统和传统的信息化管理流程、制度老化，“修修补补又一年”的传统理念难兼容新数字化建设的需求，推倒重构周期过长、成本过高。 2.各子公司间孤岛式搭建数字化体系，集团难以实现统一管理所有子公司员工身份和应用系统数据 各子公司由于业务架构、技术能力、区域法规等多种客观因素的差异，以及不同子公司中员工、经销商、供应商、上下游合作伙伴等角色各不相同，各子公司基于自身业务架构和管理需求独立建设数字化体系，同时各自独立维护各类数字化应用系统以及管理复杂的身份体系。导致在集团内部形成一个个独立的数字化孤岛，重复损耗建造、维护、迭代成本，集团难以打通各子公司数据，无法统一管理各子公司员工身份和应用系统数据。 3.子公司内部烟囱式数字化建设，跨部门协作协同难，内部数据传递效率低，市场需求响应灵活度不足 绝大多数公司受长期规模经济专业化分工发展模式的影响，内部层级分明、职能分工明确，传统的利益格局和权利体系固化，导致资源共建共享和跨部门协同协作等数字化转型开放意识不足。在数字化转型过程中各部门围绕自身核心业务线搭建和实施相应的数字化系统，在内部形成以各个业务线为单位的烟囱式数字化结构，不同业务线的系统间数据割裂，导致公司内部数据传递效率低，无法充分发挥数据要素的价值。同时由于跨组织协同和各系统间数据流通受阻，而企业内部研发资源有限，导致市场需求响应灵活度不足。 4.集团难以向下游子公司敏捷推广和实施先进数字化转型经验，无法形成数字化规模经济效应 集团在深入数字化改革过程中，通常会调研和试点先进的数字化转型方法论，受阻于上述问题，由于没有一套完善的子公司数字化管理架构，试点成果的项目和经验难以快速复制和推广至下游各子公司。而传统的数字化系统部署、升级和维护工作主要依靠各子公司独立实施，这会导致集团整体的资源利用率降低，运营成本高。同时，集团如果拓展新的业务，很难快速为其提供和部署现有的数字化能力，全集团无法形成全场景的数字化规模经济效应。 02.构建集团数字化身份管理基础设施的重要性 全球知名咨询机构 Gartner 在 2019 年提出 EBC（Enterprise Business Capability,企业业务能力） 这一理念，并认为 EBC 正在成为数字时代企业的核心竞争力。简要来说，EBC 其中的一个理念倡导企业以数据驱动，从端到端，将企业内部数据从过去烟囱式和孤岛式转化为协同式，提升企业整体数字化能力。 1.细粒度管理集团内部及下游所有身份权限，保障集团信息安全与审计合规。 集团或企业的管理，本质上是对人的管理，在数字化时代同样如此。不同的是，数字化时代的身份不仅包含人的身份信息，也包括终端设备和系统等。同时，信息安全是企业管理的核心。如上文所述，随着业务上云、生态协作、多云混合等场景涌现以及移动互联、IOT 设备的普及，大量的设备接入和上云让企业的身份信任边界外扩，过去以企业内部防火墙为边界的身份与访问控制（IAM）已经无法应对现今分布式身份和权限管理需。 所以集团提前部署下一代身份基础设施，即基于云的身份管理与访问控制系统（IDaaS）。IDaaS 提供身份验证、授权、访问注册的统一身份中台，能够同时管理企业内部应用和 SaaS 应用，通过打通云上与本地系统的身份体系以及 OneID 能力，实现对集团内部员工和下游子公司员工、外部合作伙伴等角色的身份、权限、数据进行统一管控。 强大的 IDaaS 具备完善的权限管理和安全策略配置能力，例如 Authing IDaaS 提供基于 OPA 引擎的 RBAC&ABAC 权限管理模型，既可以管理业务中的实体资源，也可以管理数据、API、菜单、按钮等细颗粒度权限控制，不仅如此，Authing IDaaS 还提供强大的权限编排能力，实现集团及子公司全业务场景权限管理覆盖。Authing IDaaS 还提供完善的组织内用户行为审计日志，来满足集团安全合规需求。 2.多租户模式帮助集团实现下游子公司分级分权管理，提升集团数字化统一管理效能 集团身份治理的难点在于管理旗下众多的子公司复杂的员工、供应商、合作伙伴等角色身份信息。传统的 IAM 仅支持单租户模式，子公司独立管理和维护复杂的身份体系，而 IDaaS 同时支持多租户模式，可以帮助集团实现所有下游子公司的统一管理。 多租户模式是一种软件架构设计，它允许多个租户（下游子公司）共享同一个软件应用实例，同时保证数据的隔离和安全。仅依靠单一的多租户架构并不能有效管理集团子公司所有员工和其它角色身份信息。需要基于强大的身份中台能力的多租户架构，集团可以快速整合全体子公司身份体系，实现复杂的组织架构分级分权管理。 对于集团型企业而言，多租户架构为集团公司提供一个统一的身份管理平台，以及员工身份信息 OneID 能力，简化了对各子公司业务数据和流程的监控。集团公司可以在一个平台上查看和分析所有子公司的数据，为集团的统一管理提供高效的数据决策支持。多租户架构可以在很大程度上简化对旗下众多子公司的管理，提升集团整体数字化统一管理效能。不仅如此，基于身份中台的多租户架构还具备以下优势： 提高资源利用率，节省运维成本：由于多租户架构在一个应用实例中支持多个子公司，可以根据不同子公司实际业务需求分配资源，通过负载均衡和弹性扩容，使得系统可以根据租户的实际需求和系统负载自动分配资源。这种动态分配机制确保了资源在不同租户之间得到合理分配，提高了整体系统的性能和稳定性。在资源需求增长时，可以迅速分配更多资源以满足需求，在需求降低时，可以回收资源以减少浪费。这种弹性扩展能力有助于实现资源的最优化，显著降低 IT 基础设施、维护和升级的成本。 租户数据隔离，数据安全合规：虽然多租户架构下的各子公司共享同一个应用实例，但可以确保每个子公司的数据彼此隔离。此外，多租户架构还可以提供集中的权限管理能力和安全策略配置，以及提供完善的租户内用户行为审计日志，确保所有子公司的数据安全以及满足所在地区法律合规。 3.打通集团全链路身份体系，提升集团和旗下子公司运营管理效能 随着数字化进程的深入，多应用、混合云的环境，给使用传统 IAM 进行身份管理的企业带来沉重的管理负担。例如：对于集团下游子公司而言， IT 管理员需要维护每个员工在不同系统之间的账号信息，并做日志审计和授权管理，当员工使用企业内部 AD 域账号访问外部系统，以及外部系统需要通过 VPN 登录到内部 AD 域时，员工需要维护复杂的账户密码体系。 IDaaS 提供统一的用户目录，通过可信单一数据源将企业不同系统的用户身份数据进行统一整合和管理。还提供统一的应用管理平台。通过满足各类标准集成协议，使得集团可以通过一处集成应用与子公司关联，极大程度减少集团内重复的应用集成成本。 可靠的 IDaaS 方案还提供应用集成网络，来帮助集团和子公司快速集成所需应用，降低应用集成成本。例如 Authing APN（应用集成网络）预集成了 2000 多款数字化应用，以及支持多种主流协议的自建应用快速集成解决方案，实现数据和业务流程的无缝对接，集团可以通过多租户架构快速为每个子公司或新的业务线快速部署所需应用软件。​ 通过上述身份和应用系统的打通，以及与上文身份中台权限管理能力的结合，实现全集团应用系统的单点登录能力，员工只需认证一次，即可访问所有被授予访问权限的业务系统，提升员工办公效率以及防止密码泄露。同时，强大的 IDaaS 解决方案还提供身份自动化能力，来自动化实现集团内部上下游身份信息同步，极大程度降低企业 IT 人员运营管理负担，提升集团整体管理效能。同时还带来以下优势： 统一的升级和维护：通过基于身份中台的多租户模式，集团公司可以统一进行应用的升级和维护，避免了在多个子公司分别进行升级和维护的繁琐工作。这不仅可以降低运维成本，还可以确保所有子公司都能及时获得最新的功能和性能改进。 全场景的数字化规模经济效应：IDaaS 可以帮助集团公司打破原有的企业内部和集团内部数据壁垒。通过多租户模式提高集团公司业务模式创新和跨组织协同协作创新能力，形成以数字能力沉淀和按需调用赋能业务轻量化、协同化的数字化发展模式。随着越来越多的业务和子公司的接入，每个子公司的运营、部署、集成、维护等时间和成本将得到释放，实现集团全场景的数字化规模经济效应。 03.最佳实践案例分享：某全球知名大型集团 1.需求挑战 该集团旗下有 300 多家公司，近 400 个分部组织。组织结构庞大人员众多，身份体系混乱，由于各公司各组织分布在多个地区，组织架构和员工身份管理难度大，集团内部信息传递效率低。希望构建统一身份中台，整合各公司组织的员工身份体系以及保障同一自然人在全平台身份信息保持唯一。 由于各公司各组织分布在全球多个地区，需要有强大的权限管理能力、安全策略能力、完善的审计报告以及相关的合规资质来满足不同地区的数据安全合规要求。 各子公司均有不同程度的数字化能力，集团希望统一管理旗下所有子公司应用数据以及提供完善的数据看板。同时各子公司也能拥有完善的身份管理体系管理下属员工、经销商等角色。 2.解决方案 通过 Authing 为该集团构建的统一身份中台，以及 OneID 能力，快速整合旗下子公司身份体系，通过 Authing 多租户实现子公司分级分权管理，并保障各子公司间数据隔离。同时通过 Authing 身份自动化能力，实现集团上下游数据信息实时同步。极大程度提升了集团和企业的运营管理效率。 Authing 提供基于 OPA 引擎的 RBAC&ABAC 权限管理模型，以及提供完善的租户内用户行为审计日志。同时 Authing 还满足不同国家和行业的合规性要求，如三级等保认证、ISO 质量认证体系认证、欧盟 GDRP 数据保护条例、CMMI 3 级能力认证、国家商用密码产品认证等资质。 通过 Authing 多租户能力，集团可以通过控制台实现一处管理所有旗下子公司员工身份信息、应用数据信息等。同时各租户（子公司）拥有完善的租户管理控制台，可以有效的管理子公司内部的员工、供应商、经销商、合作伙伴等身份信息和权限。   如果你希望免费试用 Authing 或者希望要求我们的身份专家为你讲解多租户解决方案，请添加下方企业微信与我们联系。 Authing 是国内唯一以开发者为中心的全场景身份云产品，为企业和开发者提供高安全、高性能、高生产力的用户认证和访问管理服务。 Authing 目前已经服务包括可口可乐、招商银行、三星集团、复星集团、万科集团在内的 40000+ 企业和开发者。    

每周签约喜报系列客户为 Authing 近期签约客户所在行业中具有代表性的企业。 "我们当时找到 Authing，就是要把身份做到多端跨平台，iOS、安卓端的身份能和 Oculus、Pico 等 VR 身份统一打通、一键登录，连通用户的现有智能手机习惯和未来 3D 化的发展趋势。后来，我们也发现 Authing 在企业内部管理方面能有效管控员工的权限，尤其是我们 C 端会有大量数据，内部人员获取数据一定要经过审慎的安全措施和管控，这部分 Authing 也能完全满足我们的诉求。"——XRSPACE 总经理刘冠廷 近日，XRSPACE 续约并增购 Authing，通过 Authing 身份中台能力，帮助企业实现用户多端、跨平台地统一身份管理，支撑企业高速增长和保障企业数据安全。 XRSPACE 是元宇宙行业头部的高速增长企业，2021 年 XRSPACE 推出了全球首创在线虚拟展览平台 GOXR 以及 PartyOn 虚拟音乐世界，用户可通过手机 App、平板电脑、VR 头显及 AR 眼镜走入多元化的元宇宙，实现即时互动空间并随时参加线上活动。目前已经吸引超过 1200 多家教育机构、超 20 万访客和学生进入《GOXR》；已有超 5 万用户在《PartyOn》中创建派对空间，超 70 万人加入派对。近期 XRSPACE 获得由富士康领投的 2500 万美金融资。 识别下方图片二维码，下载《Authing 元宇宙行业解决方案》。 Authing 是国内首家以开发者为中心的全场景身份云平台，帮助企业和开发者更高效更安全地实现用户认证和管理。Authing 为客户提供统一身份认证、统一权限管理、统一安全管理、统一审计管理等一站式身份治理服务。Authing 持续以开发者为中心，支持 1000+ API 和十几种主流编程语言的 SDK。目前 Authing 已帮助招商银行、云南白药、长鑫存储、复星集团等多家国内外顶级企业应对内外部场景的各种身份管理需求与挑战。    

近日，在知乎企业信息化部门与 Authing 通力合作下，Authing 为知乎构建「统一身份中台」首期工程圆满完成。 针对知乎多组织架构及内部数百套应用下复杂的认证与授权管理场景，通过 Authing 5A + 1D 能力实现统一身份管理、统一应用管理、统一安全管理、统一权限管理、统一审计管理。构建开放性、拓展性优异的统一身份中台，支撑起知乎侧企业信息化发展和信息安全挑战。截至目前知乎侧 95% 以上的内部系统认证均已接入 Authing。 关于知乎 知乎是中文互联网高质量的问答社区和创作者聚集的原创内容平台，于 2011 年 1 月正式上线，以「让人们更好的分享知识、经验和见解，找到自己的解答」为品牌使命。知乎凭借认真、专业、友善的社区氛围、独特的产品机制以及结构化和易获得的优质内容，聚集了中文互联网科技、商业、影视、时尚、文化等领域最具创造力的人群，已成为综合性、全品类、在诸多领域具有关键影响力的知识分享社区和创作者聚集的原创内容平台。 关于 Authing Authing 是国内首家以开发者为中心的全场景身份云平台，帮助企业和开发者更快更安全地实现用户认证和管理。Authing 为客户提供统一身份认证、统一权限管理、统一安全管理、统一审计管理等一站式身份治理服务。Authing 持续以开发者为中心，支持 1000+ API 和十几种主流编程语言的 SDK。目前 Authing 已助力招商银行、云南白药、长鑫存储、复星集团等多家国内外顶级企业应对内外部场景的各种身份管理需求与挑战。

序言： 元宇宙领域创业并非坦途，似乎已经成为了行业共识。 即使到今天，VR/AR 领域的装备开支和上手学习成本居高不下，全球整体用户体量相比移动互联网也仍属早期阶段。 在这样的背景下，元宇宙公司如何持续且快速地获得用户增长，就成为各家管理者需要思考的难题。 其中，跑在行业前列的 XRSPACE 交出了一份独特的答卷：选择最用户最熟悉、最易上手的场景切入，在 2D 的移动端和平板端持续投入、并和 3D VR 端完成身份统一联动，最终快速向全球市场快速扩张、累积了大量活跃用户。 XRSPACE 创建的元宇宙世界 本次，我们深度对话了 XRSPACE 总经理刘冠廷，将为我们揭晓 XRSPACE 另辟蹊径的故事。音频版后续也将在 Authing 品牌播客「黑客与画家」中发布。 Q1：XRSPACE 已经成为了元宇宙行业的头部公司，从 2017 年“元宇宙”还没火之前就早早入场，当时是什么样的契机、对行业有怎样的预见？ 我们成立 XRSPACE 的愿景就是去建立 3D 的虚拟世界，六年前我们就坚定地相信这个愿景。 我们的创始人周永明先生（Peter）是前 HTC 的 CEO，我和他也是在 HTC 相识。2014 年，Peter 推出了第一个真的落地的 VR 头盔 HTC Vive，之后也就离开了 HTC，在 2017 年创立 XRSPACE。 我们都是亲历过智慧手机革命的人，2007 年 iPhone 第一次出来的时候，大家骂声蛮多的，到 iPhone 3GS 才逐渐增强，后来成为现象级产品。 我们就会想，后智慧手机时代会是什么？于是我们就去看了 5G、AI、区块链、VR、 AR 等这些技术，这才深刻体会到，后手机时代将会从 2D 的体验跳到 3D 的体验。譬如说你刚起床在卧室，去办公室上班，下班可能去健身房，回到家在你的客厅这些都是 3D 的空间，这里包含了 3D 的人物和即时互动。 从 2D 到 3D 并不是只有 VR、AR，也就是为什么我们在一年半前，携手 Authing 把产品输出至 iOS 和 Android Google play 上。手机上、平板上你也可以去体验这个 3D 世界——你有 VR、AR，就是沉浸式的；如果只是手机或平板电脑，那是 2D 的方式、但是你体验到的都是一个 3D 的世界。 Q2：XRSPACE 的拳头产品 GOXR 和 PartyOn，分别主打展览和 K 歌社交，正在向全球市场快速扩张、累积了大量活跃用户。在主流厂商都在做游戏的时候，选择这样的行业是基于什么样的战略考量？ 我们做过很多探索，比如办公或是说生产力（productivity）场景我们其实做过验证。 去年的 Meta 的 Zuckerberg 也在强调，他甚至跟 Microsoft 合作把 Office 360 植入到 Oculus 里面。但是，好比说开会是讲求效率，还要用户带着麻烦的头盔、设置好还需要时间，那其实不是在帮助他们，8 个小时有多少时间可以带着头盔？ 公司讲求效率的时候，你必须要有一个更简单的工具来帮助它，而不是讲求体验。所以我们在讲从 2D 到 3D，更多可以是社交、娱乐，这些方向不讲求效率，但重视体验。 GOXR 的 3D 展览与 PartyOn 的歌唱活动 虚拟世界人们的互动是非常有趣的，当我们决定说更加专注在这上面，也必须衡量这个 3D 的体验太新了，人们踏入这个 3D 世界还不知道要干嘛。 2D 的世界大家习惯于刷手机，3D 的用户习惯是需要去教育的。所以我们一开始我们先做的艺术文化，比如故宫博物院可以把它 3D 化，还会把一些宗庙放到 3D 世界让用户参观。 一定要让大家通过更接近日常生活、更易懂的方式进入元宇宙。 第二款产品 PartyOn 也是一样，尤其是在亚洲的市场，K 歌其实是一个你不用沟通大家都懂的东西， 目前全民 K 歌等手机上唱歌的方式，少了三五好友聚会、合唱的快乐，在手机这些都是做不到的，所以我们在各大平台，比如 Pico 的 App store 上也是蛮成功的 App。区别于游戏，让用户唱歌更为容易，后续我们还有一些蓝图，比如可以虚拟人的能力、表演等。 Q3：XRSPACE 的核心竞争力是什么？ 我们其实是少有的懂硬件的业内软件公司，当时还做过 VR 头盔。因为2017 年成立的时候，3D 的体验还太新了，那时候 Oculus 还没出现，但已经被 Meta 买了。所以我们那时候觉得必须要有一个适当的硬件产品让用户能够体验 3D 世界。19 年我们就跟德国电信合作、还办过开发者大会等。我们当时就做出过手势追踪、去除手柄，也是 Meta 后来推的 Oculus handtracking；Meta 上次被抨击 Avatar 是半身的，我们能够做到全身。 后续各家产品都推出以后，我们的 App 做了各类平台入驻，当然头盔也没有放下。我们之前去展览会，经常用户会问：“你们手机上都能做到这样、有没有做头盔啊？有头盔体验好 100 倍！”那我们确实有，能带来更为神奇的体验，也是我们远胜于其他软件厂商的技术积累体现。 不过 VR 头盔其实用户上手成本比较高，且没有办法每天用，所以我们把它延伸到人手一台的手机——我在中国用 Pico，你在德国拿着手机，他在美国拿着平板，我们共同进入 3D 空间，能感觉到我们是在一起的。当然，这里的多端身份联动也是借助 Authing 来实现的。 XRSPACE-GOXR 移动端用户身份认证旅程 XRSPACE-PartyOn 移动端用户身份认证旅程 一个常见的问题是，是否会担心各类后来者的竞争。在这里，我不敢说我们产品是最领先的，但一定是世界前几的。因为像虚拟人在 3D 环境里的即时互动、社交合唱时的语音传输，这些都需要把延迟做得特别的低，这样用户才会感觉在一起、像现实世界。这样底层的技术优势，也还是比较难去接近的。 Q4：XRSPACE 主要使用了哪些 Authing 的产品和服务？对咱们有何帮助？ 3D 元宇宙里的虚拟人，本质就是一个身份，其底层一定需要强大的身份基础设施支撑。 我们当时找到 Authing，就是想到需要把身份做到多端的跨平台，打通用户的现有日常习惯和未来的发展趋势，帮助用户做好 2D 到 3D 的迁移。直白来说，我们需要有 iOS 端、安卓端的开发，能和 Oculus、Pico 等 VR 身份实现统一打通，也能让用户轻松地一键登录。 只有把身份统一，后续的用户运营、体验收集、在各端用户行为记录的追踪和管理等等极为重要的增长手段，才有实现的基础。 这部分我们肯定也可以投入研发人力自己做，但我们更注重把核心元宇宙的部分开发好，专业的事交给专业的公司，这样才能构建起和谐的生态。而且对于一个创业公司，产品开发上线的速度也会加快，我们可以把资源放在更需要专注的地方。 和 Authing 的合作体验也非常好，前期我们发现 Authing 第三方登录认证的集成丰富度特别高，能满足我们长期的、全球化扩展需求。 Authing 支持国内外数十种登录方式、能够便捷登录集成 使用阶段，我们经常有一些技术开发上的诉求，我们员工和 Authing 技术人员的互动还是很有效率的，产品能力的升级和优化总是非常及时，配合程度是让我印象挺深刻的。 其次，Authing 在企业内部管理的能力上也很不错，能够管控员工的系统权限，尤其是我们 C 端会有大量数据、涉及到个人隐私等。内部人员去获取这些数据，一定是经过审慎的安全措施和管控，所有的访问和操作记录也都要留存，这部分 Authing 也能满足我们的诉求。 所以，Authing 其实扮演了一个中台的角色，无论是用户身份能力支撑我们的增长、还是内部管控保障我们的数据安全，都合作得很不错。 Q5：听说 XRSPACE 也和 AWS 紧密合作，底层的云设施对咱们的发展做到了怎样的支撑？ 没错，我们一开始的定位就是要走全球化路线，所以毋庸置疑选择了 AWS 的服务。我们主要使用的是它的整体基础建设（IaaS），因为 AWS 在全球的部署上有大量弹性的机器池，可以随时调用，对我们而言是非常便捷的。 前面也讲到我们云端的技术优势之一就是低延迟，AWS 有完善的解决方案，比如我们现在需要全球的加速来保障用户体验、比如是直播的即时互动和同步，像 AWS 的 CDN 等产品，和 Authing 一样支撑了我们的业务迅速发展。 未来，我们也期待和 Authing 以及 AWS 继续紧密合作！ Q6：最后大家也很感兴趣，AI 工具的崛起是否也会让您有新的行业思考？ 最近的 AI 新技术，也让我们有了更多的想法，比如现在很多 AI 作图、做视频还是 2D 的，后面虚拟世界是否也可以根据提示词、比如直接造出你想要的建筑或者小家？是否能直接把地球模拟出来？ 第二点，即时互动是我们差异化的优势，但用户不可能永远在线，那你不上线的时候，是否可以用 AI 定义一个虚拟的你，作为一个助理，当朋友来的时候做一个基础互动。其实现在 AI 很多还是只有专业人士在用，要跳出圈层一定得是更视觉化、更直观的。甚至通过训练，人们分不清楚这个虚拟人是否是 AI，相信技术会进步到这样的层面。

在上一篇文章中，我们介绍了 OIDC 授权码模式（点击下方链接查看），本次我们将重点围绕 授权码 + PKCE 模式（Authorization Code With PKCE）进行介绍 ，从而让你的系统快速具备接入用户认证的标准体系。 OIDC & OAuth2.0 认证协议最佳实践系列 02 - 授权码模式（Authorization Code）接入 Authing 为什么会有 PKCE 模式： PKCE 是 Proof Key for Code Exchange 的缩写，PKCE 是一种用于增强授权码模式安全性的方法，它可以防止恶意应用程序通过截获授权码和重定向 URI 来获得访问令牌。PKCE 通过将随机字符串（code_verifier）和其 SHA-256 哈希值（code_challenge）与授权请求一起发送，确保访问令牌只能由具有相应 code_verifier 的应用程序使用，保障用户的安全性。 【OAuth 2.0 协议扩展】PKCE 扩展协议：为了解决公开客户端的授权安全问题 「面向对象」public 客户端，其本身没有能力保存密钥信息（恶意攻击者可以通过反编译等手段查看到客户端的密钥 client_secret， 也就可以通过授权码 code 换取 access_token， 到这一步，恶意应用就可以拿着 token 请求资源服务器了） 「原理」PKCE 协议本身是对 OAuth2.0 的扩展， 它和之前的授权码流程大体上是一致的， 区别在于在向授权服务器的 authorize endpoint 请求时，需要额外的 code_challenge 和 code_challenge_method 参数；向 token endpoint 请求时， 需要额外的 code_verifier 参数。最后授权服务器会对这三个参数进行对比验证， 通过后颁发令牌。 01.授权码 + PKCE 模式（Authorization Code With PKCE） 如果你的应用是一个 SPA 前端应用或移动端 App，建议使用授权码 + PKCE 模式来完成用户的认证和授权。授权码 + PKCE 模式适合不能安全存储密钥的场景（例如前端浏览器) 我们解释下 code_verifier 和 code_challenge 对于每一个 OAuth/OIDC 请求，客户端会先创建一个代码验证器 code_verifier code_verifier：在 [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" 范围内，生成 43-128 位的随机字符串。 code_challenge：则是对 code_verifier 通过 code_challenge_method 例如 sha256 转换得来的。 用大白话讲下就是在认证是用户携带的是加密后的 code_challenge ，在用户认证成功通过 code 获取 Token 时，客户端证明自己的方式则是把 code_verifier 原文发送，认证中心收到获取 Token 请求时通过 code_verifier + code_challenge_method 进行转换，发现最终结果与 code_challenge 匹配则返回 Token ，否则拒绝。 1.1 整体流程 整体上，有以下流程: 1.用户点击登录。 2.在你的应用中，生成 code_verifier 和 code_challenge。 3. 拼接登录链接(包含 code_challenge ) 跳转到 Authing 请求认证。 4. Authing 发现用户没有登录，重定向到认证页面，要求用户完成认证。 5. 用户在浏览器完成认证。 6. Authing 服务器通过浏览器通过重定向将授权码（code）发送到你的应用前端。 7. 你的应用将授权码 (code) 和 code_verifier 发送到 Authing 请求获取 Token. 8. Authing 校验 code、code_verifier 和 code_challenge。 9. 校验通过，Authing 则返回 AccessToken 和 IdToken 以及可选的 RefreshToken。 10. 你的应用现在知道了用户的身份，后续使用 AccessToken 换取用户信息，调用资源方的 API 等 1.2 准备接入 1.2.1 整体流程 需要先在 Authing 创建应用： 配置登录回调和登出回调，配置为你实际项目的地址，我们在这里配置 localhost 用于测试。 若你想匹配多个登录/登出回调 可以使用 ‘*’ 号进行通配，登录/登出回调可以是如下格式 在协议配置中，我们勾选 authorization_code 并且使用 code 作为返回类型，如下图所示： PKCE 模式使用的是 code_verifier 来换取 Token ，所以需要配置获取 Token 的方式为 null 1.3 接入测试 1.3.1 所需调用接口列表 GET${host}/oidc/auth 发起登录（拼接你的发起登录地址） POST${host}/oidc/token 获取 Token GET${host}/oidc/me 获取用户信息 POST${host}/oidc/token/introspection 校验 Token POST${host}/oidc/token 刷新 Token POST${host}/oidc/revocation 吊销 Token GET${host}/session/end 登出 1.3.2 Run in Postman所需调用接口列表 https://app.getpostman.com/run-collection/24730905-5d29e488-719e-4ffe-af21-a7c18298d328?action=collection%2Ffork&collection-url=entityId%3D24730905-5d29e488-719e-4ffe-af21-a7c18298d328%26entityType%3Dcollection%26workspaceId%3D13ff793c-024c-459d-b1f6-87e91c4769ed#env%5BAuthing%20OIDC%5D=W3sia2V5IjoiaG9zdCIsInZhbHVlIjoiaHR0cHM6Ly9kZWVwbGFuZy5hdXRoaW5nLmNuIiwiZW5hYmxlZCI6dHJ1ZSwidHlwZSI6ImRlZmF1bHQifSx7ImtleSI6ImNsaWVudF9pZCIsInZhbHVlIjoiNjM4MmNmNDg2ZTVhNjk0NDNhZjI5NzFiIiwiZW5hYmxlZCI6dHJ1ZSwidHlwZSI6ImRlZmF1bHQifSx7ImtleSI6ImNsaWVudF9zZWNyZXQiLCJ2YWx1ZSI6Ijc3NWMyM2NlMjkwYzkwZDQwNDUxNGU3MDgyMDkzZWIzIiwiZW5hYmxlZCI6dHJ1ZSwidHlwZSI6ImRlZmF1bHQifSx7ImtleSI6ImFjY2Vzc190b2tlbiIsInZhbHVlIjoiIiwiZW5hYmxlZCI6dHJ1ZSwidHlwZSI6ImRlZmF1bHQifSx7ImtleSI6ImlkX3Rva2VuIiwidmFsdWUiOiIiLCJlbmFibGVkIjp0cnVlLCJ0eXBlIjoiZGVmYXVsdCJ9LHsia2V5IjoicmVmcmVzaF90b2tlbiIsInZhbHVlIjoiIiwiZW5hYmxlZCI6dHJ1ZSwidHlwZSI6ImRlZmF1bHQifV0= 1.3.3 发起登录 GET${host}/oidc/auth 这是基于浏览器的 OIDC 的起点，请求对用户进行身份验证，并会在验证成功后返回授权码到您所指定的 redirect_uri。 生成 code_challenge 和 code_verifier 在线生成 https://tonyxu-io.github.io/pkce-generator/ 离线生成 首先，我们要生成一个 code_challenge 和 code_verifier,以下是使用 JavaScript 语言生成 PKCE 所需要的 code_verifier 和 code_challenge 的脚本： // 生成随机字符串function generateRandomString(length) {  var result = '';  var characters = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';  var charactersLength = characters.length;  for (var i = 0; i < length; i++) {    result += characters.charAt(Math.floor(Math.random() * charactersLength));  }  return result;}// 生成 code_verifiervar codeVerifier = generateRandomString(128);// 对 code_verifier 进行 SHA-256 编码，并将其转换为 base64url 格式的 code_challengevar sha256 = new jsSHA("SHA-256", "TEXT");sha256.update(codeVerifier);var codeChallenge = btoa(String.fromCharCode.apply(null, new Uint8Array(sha256.getHash("ARRAYBUFFER"))))  .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');// 将 code_verifier 和 code_challenge 用对象形式返回var pkce = {  codeVerifier: codeVerifier,  codeChallenge: codeChallenge}; 以上代码使用 jsSHA 库计算 SHA-256 哈希值，使用 base64url 编码将哈希值转换为 code_challenge。你可以将以上代码复制到你的 JavaScript 代码中，并使用 pkce.codeVerifier 和 pkce.codeChallenge 调用 OAuth 2.0 授权请求。 举例 code_verifier: 4aHg5fN1AGdbnBAfVKMf9ZMK4PUOBTwQSKKk9V8wYXOFYDZklMl7dzDUhnQi4sYhzGb6PWCkNQqLP70K1DNOneEDq8iyASepAdGjGBBmCs4BGCDDJNwLrGpnJEfmrI66 code_verifier 的长度为 43 ～ 128 ，我们生成的是 128 位 code_challenge: OhMk95M9qWkKd06--utVtRzQh8Y0Qtqo4cPqqzMJyMw 发起登录地址（浏览器中打开） https://{host}/oidc/auth?scope=openid+profile+offline_access+username+email+phone&redirect_uri=http://localhost:8080/&response_type=code&prompt=consent&nonce=6e187def-1a19-4067-8875-653f024d5a9f&client_id={client_id}&state=1676881862&code_challenge={code_challenge}&code_challenge_method=S256 体验地址 https://oidc-authorizationcode-withpkce.authing.cn/oidc/auth?scope=openid+profile+offline_access+username+email+phone&redirect_uri=http://localhost:8080/&response_type=code&prompt=consent&nonce=6e187def-1a19-4067-8875-653f024d5a9f&client_id=63f30f5bf629268cc27d93c6&state=1676881862&code_challenge=OhMk95M9qWkKd06--utVtRzQh8Y0Qtqo4cPqqzMJyMw&code_challenge_method=S256 参数说明 1.3.4 获取 Token POST${host}/oidc/token 用户在 Authing 侧完成登录操作后， Authing 会将生成的 code 作为参数回调到 redirect_uri 地址，此时通过 code 换 token 接口即可拿到对应的访问令牌 access_token 请求参数 请求示例 curl --location --request POST 'https://{host}/oidc/token' \--header 'Content-Type: application/x-www-form-urlencoded' \--data-urlencode 'client_id={应用ID}' \--data-urlencode 'client_secret={应用密钥}' \--data-urlencode 'grant_type=authorization_code' \--data-urlencode 'redirect_uri={发起登录时指定的 redirect_uri}' \--data-urlencode 'code={/oidc/auth 返回的code}' \--data-urlencode 'code_verifier={code_verifier}' 响应示例（成功） {    "scope": "openid username email phone offline_access profile",    "token_type": "Bearer",    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImVtSzBGbVRIa0xlQWFjeS1YWEpVT3J6SzkxV243TkdoNGFlYUVlSjVQOUUifQ.eyJzdWIiOiI2M2ViNTNjNDQxYTVjMmYwNWYyNGJiMDMiLCJhdWQiOiI2M2ViNDU4NTE1NmQ5NzcxMDFkZDM3NTAiLCJzY29wZSI6Im9wZW5pZCB1c2VybmFtZSBlbWFpbCBwaG9uZSBvZmZsaW5lX2FjY2VzcyBwcm9maWxlIiwiaWF0IjoxNjc2MzY2OTE0LCJleHAiOjE2Nzc1NzY1MTQsImp0aSI6ImVmVU04enNrbl92LXYzeXZfbDVHRV9fQ2JEY0NNZDhEVDFnYVI0bHRqcHAiLCJpc3MiOiJodHRwczovL29pZGMtYXV0aG9yaXphdGlvbi1jb2RlLmF1dGhpbmcuY24vb2lkYyJ9.E3gAYzCQbJmrtM5zl91OPHm2YPnDxzRejw75oVMF1tLqCS0trj6CSBxyxP3Z9t6Eb_oAu1f_3I6XC3KC-l0DTM6q7_R2rnW4LWlik2rDCLuGpG0FqFScLZhwafmrPsVn93yaBQfEEoaLviqKhj3DgOymKqHZzFG3taaz2k_pWsxt4z97DtKjRTiqyMvcSfHsVrjSKELaC-5S_PHPWcQ70iX85IwUb6i5ldZGxYmODCvChNC9p4D4IOT3atvyEHgBTmjA9ZKI-T7hCVHSO91WZY3l1p4iWdi6KdP1oMGTy8WbmUHG9SiWO1Efh_9I5ZpRzVNWXINLv-lZ0d2aZKjg2w",    "expires_in": 1209600,    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI2M2ViNTNjNDQxYTVjMmYwNWYyNGJiMDMiLCJhdWQiOiI2M2ViNDU4NTE1NmQ5NzcxMDFkZDM3NTAiLCJpYXQiOjE2NzYzNjY5MTQsImV4cCI6MTY3NzU3NjUxNCwiaXNzIjoiaHR0cHM6Ly9vaWRjLWF1dGhvcml6YXRpb24tY29kZS5hdXRoaW5nLmNuL29pZGMiLCJub25jZSI6IjhiYjg3MjdhLWU1MGUtNDUzOC05ZmZmLWZhOTFlNWQ0Y2MwYSIsIm5hbWUiOm51bGwsImdpdmVuX25hbWUiOm51bGwsIm1pZGRsZV9uYW1lIjpudWxsLCJmYW1pbHlfbmFtZSI6bnVsbCwibmlja25hbWUiOm51bGwsInByZWZlcnJlZF91c2VybmFtZSI6bnVsbCwicHJvZmlsZSI6bnVsbCwicGljdHVyZSI6Imh0dHBzOi8vZmlsZXMuYXV0aGluZy5jby9hdXRoaW5nLWNvbnNvbGUvZGVmYXVsdC11c2VyLWF2YXRhci5wbmciLCJ3ZWJzaXRlIjpudWxsLCJiaXJ0aGRhdGUiOm51bGwsImdlbmRlciI6IlUiLCJ6b25laW5mbyI6bnVsbCwibG9jYWxlIjpudWxsLCJ1cGRhdGVkX2F0IjoiMjAyMy0wMi0xNFQwOToyNjoyOC4wNjhaIiwiZW1haWwiOm51bGwsImVtYWlsX3ZlcmlmaWVkIjpmYWxzZSwicGhvbmVfbnVtYmVyIjoiMTg1MTY4Mjk5OTUiLCJwaG9uZV9udW1iZXJfdmVyaWZpZWQiOnRydWUsInVzZXJuYW1lIjpudWxsfQ.GweoWBCEyHQGP6G9ohbfBMUMALlbZMM9hRAes1De7BM",    "refresh_token": "KanvCEmonS_FgCRdFftOCwka2f8Qjj4tcsIfJF-VC1W"} 响应示例（失败） {    "error": "invalid_grant",    "error_description": "授权码无效或已过期"} 1.3.5 所需调用接口列表 GET${host}/oidc/me 获取用户信息 此端点是 OIDC 获取用户端点，可以通过 AccessToken 获取有关当前登录用户的信息。 请求参数 请求示例 curl --location --request GET 'https://{host}/oidc/me?access_token={access_token}'  响应示例（成功） {    "name": null,    "given_name": null,    "middle_name": null,    "family_name": null,    "nickname": null,    "preferred_username": null,    "profile": null,    "picture": "https://files.authing.co/authing-console/default-user-avatar.png",    "website": null,    "birthdate": null,    "gender": "U",    "zoneinfo": null,    "locale": null,    "updated_at": "2023-02-14T09:26:28.068Z",    "email": "xxx@authing.cn",    "email_verified": true,    "phone_number": "185xxxx9995",    "phone_number_verified": true,    "username": "neo",    "sub": "63eb53c441a5c2f05f24bb03"} 响应示例（失败） {    "error": "invalid_grant",    "error_description": "Refresh Token 无效或已过期"} 1.3.6 校验 Token POST${host}/oidc/auth 此端点接受 access_token、id_token、refresh_token ，并返回一个布尔值，指示它是否处于活动状态。如果令牌处于活动状态，还将返回有关令牌的其他数据。如果 token 无效、过期或被吊销，则认为它处于非活动状态。 access_token 可以使用 RS256 签名算法或 HS256 签名算法进行签名。下面是这两种签名算法的区别： RS256 是使用 RSA 算法的一种数字签名算法，它使用公钥/私钥对来加密和验证信息。RS256 签名生成的令牌比 HS256 签名生成的令牌更加安全，因为使用 RSA 密钥对进行签名可以提供更高的保护级别。使用 RS256 签名算法的令牌可以使用公钥进行验证，公钥可以通过 JWK 端点获取。 HS256 是使用对称密钥的一种数字签名算法。它使用同一个密钥进行签名和验证。HS256 签名算法在性能方面比 RS256 签名算法更快，因为它使用的是对称密钥，而不是使用 RSA 公钥/私钥对来签名和验证。使用 HS256 签名算法的令牌可以通过 shared secret （应用密钥）进行验证。 在实际应用中，RS256 算法更加安全，但同时也更加消耗资源，如果系统需要高性能，可以选择 HS256 签名算法。 验证 Token 分为两种方式 本地验证与使用 Authing 在线验证。我们建议在本地验证 JWT Token，因为可以节省你的服务器带宽并加快验证速度。你也可以选择将 Token 发送到 Authing 的验证接口由 Authing 进行验证并返回结果，但这样会造成网络延迟，而且在网络拥塞时可能会有慢速请求。 以下是本地验证和在线验证的优劣对比： 在线校验 需要注意的是，id_token 目前无法在线校验，因为 id_token 只是一个标识，若需要校验 id_token 则需要您在离线自行校验 请求参数 请求示例 curl --location --request POST 'https://{host}/oidc/token/introspection' \--header 'Content-Type: application/x-www-form-urlencoded' \--data-urlencode 'client_id={应用ID}' \--data-urlencode 'client_secret={应用密钥}' \--data-urlencode 'token={ token }' \--data-urlencode 'token_type_hint={token_type_hint}' 校验 access_token 响应示例（校验通过） {    "active": true,    "sub": "63eb53c441a5c2f05f24bb03",    "client_id": "63eb4585156d977101dd3750",    "exp": 1677648467,    "iat": 1676438867,    "iss": "https://oidc-authorization-code.authing.cn/oidc",    "jti": "ObgavGBUocr1wsrUvtDLHmuFSgoebxsiOY4JNRqIhaQ",    "scope": "offline_access username profile openid phone email",    "token_type": "Bearer" 校验 access_token 响应示例（校验未通过） {    "active": false} 校验 refresh_token 响应示例 (校验通过） {    "active": true,    "sub": "63eb53c441a5c2f05f24bb03",    "client_id": "63eb4585156d977101dd3750",    "exp": 1679030867,    "iat": 1676438867,    "iss": "https://oidc-authorization-code.authing.cn/oidc",    "jti": "6F2TO1v1YZ1_N7I3jXYHjK-vZzKtlD0IiP5KPoUFUCQ",    "scope": "offline_access username profile openid phone email"} 校验 refresh_token 响应示例（校验未通过） {    "active": false} 离线校验 可参考文档（Authing 开发者文档）： https://docs.authing.cn/v2/guides/faqs/how-to-validate-user-token.html#%E6%9C%AC%E5%9C%B0%E9%AA%8C%E8%AF%81 我们简单说下，若您使用离线校验应该对 token 进行如下规则的校验 1.格式校验 - 校验 token 格式是否是 JWT 格式 2.类型校验 - 校验 token 是否是目标 token 类型，比如 access_token 、id_token、refresh_token 3.issuer 校验 - 校验 token 是否为信赖的 issuer 颁发 4.签名校验 - 校验 token 签名是否由 issuer 签发，防止伪造 5.有效期校验 - 校验 token 是否在有效期内 6.claims 校验 - 是否符合与预期的一致 示例代码 下面是一个示例 Java 代码，可以用于在本地校验 OIDC RS256 和 HS256 签发的 access_token import com.nimbusds.jose.JWSObject;import com.nimbusds.jwt.JWTClaimsSet;import com.nimbusds.jwt.SignedJWT;import java.net.URL;import java.text.ParseException;import java.util.Date;public class OIDCValidator {    private static final String ISSUER = "https://your-issuer.com";    private static final String AUDIENCE = "your-client-id";    private final URL jwkUrl;    public OIDCValidator(final URL jwkUrl) {        this.jwkUrl = jwkUrl;    }    public JWTClaimsSet validateToken(final String accessToken) throws ParseException {        final SignedJWT signedJWT = SignedJWT.parse(accessToken);        if (signedJWT == null) {            throw new RuntimeException("Access token is null or empty");        }        final JWTClaimsSet claims = signedJWT.getJWTClaimsSet();        if (claims == null) {            throw new RuntimeException("No claims present in the access token");        }        if (!claims.getIssuer().equals(ISSUER)) {            throw new RuntimeException("Invalid issuer in access token");        }        if (!claims.getAudience().contains(AUDIENCE)) {            throw new RuntimeException("Invalid audience in access token");        }        final JWSObject jwsObject = signedJWT.getJWSObject();        if (jwsObject == null) {            throw new RuntimeException("No JWS object found in the access token");        }        // Fetch the JWKs from the JWK set URL        final JWKSet jwkSet = JWKSet.load(jwkUrl);        final JWK jwk = jwkSet.getKeyByKeyId(jwsObject.getHeader().getKeyID());        if (jwk == null) {            throw new RuntimeException("No JWK found for the access token");        }        if (!jwsObject.verify(jwk.getKey())) {            throw new RuntimeException("Invalid signature in access token");        }        if (claims.getExpirationTime() == null || claims.getExpirationTime().before(new Date())) {            throw new RuntimeException("Expired access token");        }        return claims;    }} nce 值对access_token 进行验证，并验证 JWT 中 claims 的格式、类型、签名、有效期和 issuer。如果发生任何验证错误，则将抛出 RuntimeException。使用时需要传入对应的 JWK URL 和 access_token 进行调用，例如： *final URL jwkUrl = new URL("https://your-issuer.com/.well-known/jwks.json");final OIDCValidator validator = new OIDCValidator(jwkUrl);final String accessToken = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE1MTYyMzkwMjJ9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c";final JWTClaimsSet claims = validator.validateToken(accessToken);* 这个示例只校验了 RS256 和 HS256 签名算法。 1.3.7 刷新 Token POST${host}/oidc/token 此功能用于用户 token 的刷新操作，在 token 获取阶段需要先获取到 refresh_token 。 请求参数   请求参数 curl --location --request POST 'https://{host}/oidc/token' \--header 'Content-Type: application/x-www-form-urlencoded' \--data-urlencode 'client_id={应用ID}' \--data-urlencode 'client_secret={应用密钥}' \--data-urlencode 'refresh_token={刷新令牌}' \--data-urlencode 'grant_type=refresh_token' 响应示例(成功） {    "refresh_token": "6F2TO1v1YZ1_N7I3jXYHjK-vZzKtlD0IiP5KPoUFUCQ",    "scope": "offline_access username profile openid phone email",    "token_type": "Bearer",    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImVtSzBGbVRIa0xlQWFjeS1YWEpVT3J6SzkxV243TkdoNGFlYUVlSjVQOUUifQ.eyJzdWIiOiI2M2ViNTNjNDQxYTVjMmYwNWYyNGJiMDMiLCJhdWQiOiI2M2ViNDU4NTE1NmQ5NzcxMDFkZDM3NTAiLCJzY29wZSI6Im9mZmxpbmVfYWNjZXNzIHVzZXJuYW1lIHByb2ZpbGUgb3BlbmlkIHBob25lIGVtYWlsIiwiaWF0IjoxNjc2NDQ0MjY4LCJleHAiOjE2Nzc2NTM4NjgsImp0aSI6IkEtZUlQYkJ5N3lJLTliUmp1RnJHeXNCSXdjbWtOUl9WalpYODB2aU05VFkiLCJpc3MiOiJodHRwczovL29pZGMtYXV0aG9yaXphdGlvbi1jb2RlLmF1dGhpbmcuY24vb2lkYyJ9.Kk3jSK5BSUEDVTQMdMAdG5cBCxZt31vQiD-XYHNA84Gd3Mo8eDLcQpjMEzQ8HJ4_b9IgMOz5ydXz0zAQ6AjLMW3Rl49qhTGDB7Kq7tHTFmDO8itoO2LQTCLPCPtP3TkoOgptlFD_sd32nefH-HojNhuqwKw469Byw3xnW5xEs3wSuOoUdHwR2n9j1T1Zgp3e90xmBjbtbofQE1z0IWtCnrfJ9ujWsKXoN_7OAXbCTa-Ak_DhgLHU7xutQaaBOgD28lLLT5xclgBWfv7Leyx_kBnVGT5Jvo1tfA6AUEp6wJO4GUBzsijLefI04VDzBGypNuFJlw_jOhSp-SWxJjQSwQ",    "expires_in": 1209600,    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI2M2ViNTNjNDQxYTVjMmYwNWYyNGJiMDMiLCJhdWQiOiI2M2ViNDU4NTE1NmQ5NzcxMDFkZDM3NTAiLCJpYXQiOjE2NzY0NDQyNjgsImV4cCI6MTY3NzY1Mzg2OCwiaXNzIjoiaHR0cHM6Ly9vaWRjLWF1dGhvcml6YXRpb24tY29kZS5hdXRoaW5nLmNuL29pZGMiLCJuYW1lIjpudWxsLCJnaXZlbl9uYW1lIjpudWxsLCJtaWRkbGVfbmFtZSI6bnVsbCwiZmFtaWx5X25hbWUiOm51bGwsIm5pY2tuYW1lIjpudWxsLCJwcmVmZXJyZWRfdXNlcm5hbWUiOm51bGwsInByb2ZpbGUiOm51bGwsInBpY3R1cmUiOiJodHRwczovL2ZpbGVzLmF1dGhpbmcuY28vYXV0aGluZy1jb25zb2xlL2RlZmF1bHQtdXNlci1hdmF0YXIucG5nIiwid2Vic2l0ZSI6bnVsbCwiYmlydGhkYXRlIjpudWxsLCJnZW5kZXIiOiJVIiwiem9uZWluZm8iOm51bGwsImxvY2FsZSI6bnVsbCwidXBkYXRlZF9hdCI6IjIwMjMtMDItMTRUMDk6MjY6MjguMDY4WiIsImVtYWlsIjpudWxsLCJlbWFpbF92ZXJpZmllZCI6ZmFsc2UsInBob25lX251bWJlciI6IjE4NTE2ODI5OTk1IiwicGhvbmVfbnVtYmVyX3ZlcmlmaWVkIjp0cnVlLCJ1c2VybmFtZSI6bnVsbH0.DGoJrzkgti44zw-MotVM1KpLxbJTzc5pfh-xYun_xDQ"} 响应示例(失败） {    "error": "invalid_grant",    "error_description": "Refresh Token 无效或已过期"} 1.3.8 撤回 Token POST${host}/oidc/auth 撤销 access_token / refresh_token 。 请求参数 请求示例 curl --location --request POST 'https://{host}/oidc/token/revocation' \--header 'Content-Type: application/x-www-form-urlencoded' \--data-urlencode 'client_id={应用ID}' \--data-urlencode 'client_secret={应用密钥}' \--data-urlencode 'token= {token}' \--data-urlencode 'token_type_hint={token_type_hint}' 响应示例(成功) HTTP 200 OK 响应示例(失败） {    "error": "xxxx",    "error_description": "xxxx"} 1.3.9 用户登出 GET${host}/oidc/session/end 使用此操作通过删除用户的浏览器会话来注销用户。 post_logout_redirect_uri 可以指定在执行注销后重定向的地址。否则，浏览器将重定向到默认页面 请求参数 请求示例(浏览器访问) GET https://oidc-authorization-code.authing.cn/oidc/session/end?id_token_hint={id_token}&post_logout_redirect_uri=http://localhost:8080/&state=1676452381 02.本章总结 本章我们介绍了 OIDC 授权码模式的接入流程以及相关接口的调用方式，对于小白来说可能需要整体跑一遍流程才能熟悉，我们也建议你 fork 我们的 postman collection 跑一遍流程，对 PKCE 模式你就基本掌握啦。 接下来我们还会介绍 OIDC 的授权码+PKCE 流程，以及接入 Authing 的方式，需要你对授权码模式的流程有一定了解哦。 往期精彩内容 如何使用 Authing 实现 AWS CLI 单点登录？ Authing 结合 APISIX 实现统一可配置 API 权限网关 什么是事件驱动（EDA）？为什么它是技术领域的主要驱动力？  

近日，Authing 入选【2022 年度中国高科技高成长企业系列榜单 】- 【云原生高成长企业榜】，该榜单由【第一新声】联合【天眼查】发起的"数字中国"系列之 2022 年度中国高科技高成长企业系列榜单发布，该榜单旨在发现和挖掘被资本市场关注，同时受客户认可的高科技、高成长、好口碑、稳交付、跨周期的优秀企业。 本次年度榜单共包括综合榜、高成长 SaaS 企业榜、高成长硬科技企业榜三大类，涵盖高科技上市企业、独角兽、未来独角兽、新锐企业等不同阶段企业，基于【天眼查】大数据优势，通过多种方式，收集企业自主提交数据信息，建立独家评选指标体系，并邀请经纬创投、光速中国、靖亚资本、云启资本、红点中国、绿洲资本、启迪之星创投、浑璞投资、齐芯资本、力合资本、光源资本等数十家一线投资机构投资人以及数十位甲方 CIO 评审从各个维度给到的专业评审意见。围绕“高科技、高成长”，从业务数据、财务数据、产品能力、服务能力、市场影响力等多维度展开榜单评选，最终评选出相应榜单。 Authing 是国内首款以开发者为中心的 IDaaS 产品，通过图模型的编排引擎替代决策树编排，在高安全、高可用、高性能的前提下，实现上下游平台身份 APIs 全生命周期高效管理与灵活连接。提供 OPA（组织过程管理） SaaS，完善 OPA 计算监控、事件监控、决策监控、决策设计器、代码编写等，覆盖决策计算全生命周期，以实现下一代事件驱动的低代码决策引擎和自动化风控引擎。助力企业大幅提升企业身份治理效能。 权威认可 2023 年 3 月，Authing 入选金融信创生态实验室《金融信创优秀解决方案》 2023 年 3 月，Authing 入选《网络安全优质初创企业 HOT50》报告 2023 年 2 月，Authing 入选德勤“中国明日之星”企业榜单 2023 年 1 月，Authing 入选 “2022 年中国产业数字化领军企业” 2022 年 12 月，Authing 入选长城战略咨询《2022 中国潜在独角兽企业研究报告》 2022年 12 月， Authing 荣获 2022 中国数字化转型与创新评选之“年度安全创新产品”、荣登《中国网络安全企业 100 强》身份与访问安全细分榜。 2022 年 10 月，Authing 入选 Gartner《2022 中国网络安全技术成熟度曲线》报告位列Sample Vendor IAM 领域首位（Hype Cycle for Security in China, 2022）。 2022年 11 月，Authing 入选艾瑞咨询 2022 年《中国企业级 SaaS 行业研究报告》。 2022 年 9 月，Authing 入选“中国信科独角兽及新物种榜单”。 2022 年 9 月，Authing 入选国际云安全联盟 CSA 2022 年 6 月，Authing 获得云原生产业联盟颁发的「2022 年度云原生新锐企业」。 2022 年 5 月，Authing 成功入选世界经济论坛（World Economic Forum）2022 年技术先锋榜单——全球 100 家最有前途的“技术先锋”（Tech Pioneer），中国大陆仅 15 家公司上榜。 2022 年 4 月，Authing 正式加入 W3C（万维网联盟）组织， 将参与 WebRTC、DID、Web 应用及安全、身份验证、JSON-LD、数据集交换、MiniApps 等国际互联网标准制定。 科技部认定的「2021 国家高新技术企业」；中国信息通信研究院评选的「国内身份管理与访问控制领域创新企业」。 2021 年 8 月，Authing 入选福布斯亚洲「最值得关注公司」百强榜单，创始人谢扬入选福布斯亚洲 30 Under 30。