免费注册,打造高效身份管理
authing blog banner
查看文章
联合活动|国有企业全球化与数字化转型案例大会
经济是未来世界经济竞争格局的战略高地,“十四五规划”明确提出要推进数字产业化和产业数字化,国有企业数字化转型大势所趋。 2023 年 3 月 31 日,中国软件行业协会信息主管(CIO)分会、数字产业创新研究中心共同举办“2023 国有企业全球化与数字化转型案例大会暨探营华润数字化创新”活动。 本次国有企业全球化与数字化转型案例大会主题聚焦于“科技引领·共建国企数字化新生态”,旨在通过研究和推广国有企业数字化转型典范模式与案例,邀约更多数字化实战者分享案例与经验,为企业提供数字化转型启示! Authing 是国内首款以开发者为中心的全场景身份云产品,目前已服务包括招商银行、中煤科工集团、高等教育出版社在内的 40000 + 企业和开发者。作为本次大会的联合创新机构,Authing 是企业数字化转型的实战者与创新者,在国有企业数字化转型中有充分的先进实践,能够为企业提供丰富的案例与经验。 3 月 31 日 下午,Authing 首席解决方案架构师将与其他嘉宾共同探讨国有企业如何发挥数据优势赋能业务增长。 继国资委提出要“打造一批具有全球竞争力的世界一流企业”后,国有企业纷纷加快国际布局,基于数字化转型,实现自身高质量发展,形成一批具有全球话语权和影响力的领军企业。 如果你想和企业数字化创新者一起深入探访、体验、对话国有企业数字化转型案例,深度剖析国有企业数字化转型与创新过程中的热点、难点,可以添加 Authing 小助手企业微信,回复「数字化创新报名」,获取 Authing 专属报名特快通道。 Authing 小助手   Authing 是国内唯一以开发者为中心的全场景身份云产品,为企业和开发者提供高安全、高性能、高生产力的用户认证和访问管理服务。 Authing 目前已经服务包括可口可乐、招商银行、三星集团、复星集团、元气森林在内的 40000+ 企业和开发者。
最佳实践| 探索 Authing 企业级云原生权限治理平台
在现代企业中,数据已经成为最重要的资产之一。 有数据显示,全球大约有一半的组织在过去的一年中经历了至少一次成功的网络攻击事件,其中,39% 的攻击事件是由内部人员造成的。为了保护企业的数据和信息资产,许多政府和行业规范要求企业必须实施权限管理措施。证监会第 152 号文中要求证券基金经营机构应当建立对信息系统权限的定期检查与核对机制,我国《信息安全技术-网络安全等级保护基本要求》中也明确指出身份与访问控制、安全审计工均作为网络安全保护的重要测评单元。 目前,在金融、医药研发、先进制造等行业客户出于数据资产安全及合规的需求,对统一的细粒度权限管理的诉求日益增长。Authing 基于行业客户的痛点及先进实践,与行业客户共同探索企业级云原生权限治理平台的最佳实践。 01 企业如何进行统一权限治理? 权限治理是围绕着企业核心资产所实施的一系列综合性的管理过程。对员工信息、业务系统、核心数据等进行访问权限、数据权限、功能权限等方面的管控,以加强信息安全、提高管理效率、优化资源配置。 企业规模、业务类型和组织结构的不同对权限治理的要求也有所不同,但企业在各个阶段进行权限管理有其共同性,在实施权限治理方案时都会面临相似的挑战。 权限统一管理难:企业员工的身份信息分散在不同应用系统中,以及不同业务场景下对不同角色的不同权限难以精准分配。这导致企业统一权限管理困难,也增加了因权限泄露和不当操作带来的安全风险。 权限生命周期管理难:在员工的入转调离全生命周期过程中,涉及权限的创建、增加、修改、禁用、删除等操作,需要IT部门逐个系统修改操作。例如:员工离职后,企业需要及时地收回其访问权限,但如何确保权限的及时回收,避免权限滥用和泄漏成为困扰多个企业的问题。 实现多维度权限控制难。企业需要在多个维度上控制权限,包括用户、角色、组织、应用程序、数据等。如何在不同维度上有效地控制权限,并实现细粒度的权限管理。 处理权限重叠问题难。在不同系统、服务和数据中,可能存在相同或类似的权限,如何处理权限之间的交集和冲突是一个难题。 技术集成困难。不同的应用程序和系统可能使用不同的身份认证和和授权机制,如何将这些机制集成到一个统一的权限治理框架中,是一个技术挑战。 02 Authing 统一权限治理解决方案 2.1 整体架构 2.2 Authing 权限中台优势 降低 80% 研发周期 以鉴权为例,在使用 Authing 前,开发者需要数十行代码才能生成,且需要多次查询数据库实现。 // 查询用户关联的角色列表 List<Subject> subjectList = client.getSubjectList(namespace, user); // 查询对应角色关联的策略列表 List<Policy> policyList = client.getPolicyList(subjectList); // 查询对应策略关联的资源列表List<Resource> resourceList = client.getResourceList(policyList); // 查询对应资源所有的操作列表 List<Action> actionList = client.getActionList(resourceList); // 过滤被拒绝的操作 List<Action> allowActionList = client.filterDenyAction(actionList); if(user.role == "ADMIN" || (user.geo == "CHINA" && resourceList.contains(resource) && allowActionList.contains(action) )){ // 鉴权通过 } 使用 Authing 后,两行代码搞定! if(client.checkPermission(namespace, user, resource, action)){ // 鉴权通过 } 降低 80% 数据泄露风险 避免企业出现研发人员删库跑路、离职人员依然保有关键系统权限问题,加强对企业核心资源控制力度,保护企业核心数据与资源资产安全。 提高 70% 审计效率 强化企业资源统一审计力度,促进企业精细化管理,帮助企业高效分析整个业务系统的用户行为与数据信息,提前识别潜在风险,降低企业内外部恶意攻击风险。 2.3 Authing 权限中台产品速览 细分资源类型:数据资源分为字符串(适用路径指代)、数组资源(适用数据集合)、树结构资源(适用菜单),更细粒度管控权限、更贴合业务场景。 策略化授权:授权更加清晰,将数据权限和资源权限灵活组合,提高资源管理效率。 权限视图:高效审计提高复杂场景授权效率,便于权限治理。 2.4 典型场景 API 统一鉴权 当企业使用多个应用程序时,需要共享某些资源,例如用户信息、订单数据等。企业可以使用 API 统一鉴权来确保每个服务和应用程序都能够访问它们所需的资源。 例如,当用户访问订单管理功能时,订单微服务将向 API 统一鉴权服务发送一个包含访问令牌的请求。API 统一鉴权服务将验证访问令牌的有效性,并检查该用户是否具有访问订单管理的权限。如果验证通过,则订单微服务将返回用户的订单信息。如果验证不通过,则订单微服务将返回一个错误消息,表示该用户无权访问该资源。 功能菜单权限管理 企业的一些业务软件系统中常常会有多个功能菜单,如用户管理、订单管理、库存管理等。这些菜单需要根据用户的角色或权限进行控制,以确保每个用户只能访问其具有权限的功能菜单。 例如某企业的 ERP 系统需要对菜单进行权限管理。系统中有三种角色:管理员、销售员和采购员,管理员可以访问所有菜单,销售员只能访问销售相关的菜单,采购员只能访问采购相关的菜单。企业可以在功能菜单权限管理系统中定义这些角色,当用户登录系统时,系统会验证该用户的角色,并根据其角色来确定其可以访问的菜单。 数据权限管理 数据权限管理是指企业在数据访问控制方面对用户进行细粒度的控制,以确保每个用户只能访问其具有权限的数据。例如某企业员工的个人信息和薪资记录,需要对这些数据进行权限管理,以确保敏感数据只能被授权的用户访问,HR 部门可以访问所有员工的数据,而普通员工只能访问自己的数据。数据权限管理功能可以根据员工的部门、岗位、职级等信息,将员工分为不同的权限组,并控制每个权限组可以访问的数据范围。 当用户访问员工数据时,系统会验证该用户的身份和权限,并根据其权限来确定其可以访问的数据范围。如果用户尝试访问其没有权限的数据,系统将拒绝该请求,并返回一个错误消息,告诉用户他们没有权限访问该数据。 03 客户案例:某国有证券资管公司 某国有证券资管公司拥有十几万员工,业务遍布全国数百个分部。集团总部和分部又有不同的业务结构,从股东、监事、董事再到高级管理层、实际业务部门,每个大部门下属众多小部门,权限管理错综复杂,出现了系统数据割裂、权限管理流程复杂、审计工作量巨大等问题。 主要有以下三个痛点: 员工入转调离生命周期与业务系统权限流程割裂,每个业务系统需要单独维护权限体系,账号到期无法进行统一回收,无法满足合规性且存在数据泄露隐患。 现有业务体系下权限定义、分配流程复杂且重复,所有业务系统均要对相同的资管产品进行权限分配和开通。 权限数据采样、提取、抽查工作量巨大,缺少统一、直观的可视化权限审计平台。 在考察了国内外众多身份认证企业后,该公司选择了 Authing。Authing 基于事件驱动的云原生身份自动化管理平台,为该公司统一身份管理权限治理提供了解决方案: 输出身份业务最佳实践 深入业务场景调研身份、权限相关建设问题,并输出建设和管理规范。 打通上下游业务体系 Authing 打通资管公司的上游统一账号体系,通过统一权限网关集成业务系统,实现权限集中化的下放、分配和回收,一出配置,全局生效。 建立可视化审计平台 基于 Authing 安全审计和可视化能力,实现对于员工、管理员的细颗粒度审计合规需求,保证事后追踪和溯源。按照角色、用户、组织等多维度进行权限审阅。 身份自动化工作流 通过工作流画布灵活编排内外部身份管理业务流和数据流,依赖底层的元数据引擎和事件引擎,打造身份管理全生命周期可视化编排体验。 在使用 Authing 后,有效保证了该资管公司权限管理合规性与安全性,避免因员工入转调离权限管理混乱造成的数据泄漏风险。同时,降低了研发开发周期与成本,提高了企业运营效率。   添加官方微信 预约 Authing 权限治理专家进行沟通   Authing 是国内唯一以开发者为中心的全场景身份云产品,为企业和开发者提供高安全、高性能、高生产力的用户认证和访问管理服务。 Authing 目前已经服务包括可口可乐、招商银行、三星集团、复星集团、元气森林在内的 40000+ 企业和开发者。
Authing 新增 AWS、钉钉、腾讯 QQ 、百度、新浪微博等多种身份源|功能更新
Authing 身份源新增: AWS(Web 端)、钉钉(移动端)、腾讯 QQ(移动端)、Linkedln(移动端)、百度(移动端)、新浪微博(移动端)。 身份源提供商(Identity Providers,简称 IdP) 是一种身份认证服务,其主要作用是管理和控制用户身份信息,以便用户可以安全地访问各种应用程序和服务。常见的应用场景例如很多应用软件提供微信第三方登录,在这个场景中微信则作为身份源提供商。 添加第三方认证能最大限度减少用户体验的摩擦,为用户提供高效安全的优质登录体验。多样化的社会化登录方式能满足企业不同客群的登录习惯,有助于增强用户信任度并提高注册转化率。 通常,集成一个应用所需的多个身份源需要耗费数周的时间,而 Authing 提供 20 多种开箱即用的企业和社会化登录方式,如:微信、QQ、Facebook、Google、Twitter 等,将集成时间从数周降低至几分钟。 在本次身份源更新中,Authing 身份源新增: 长按识别二维码跳转至 Authing 开发者文档了解详情**。 IdP 连接流程 一个典型的 Web 端应用与 IdP 连接流程包含以下步骤: 跳转:用户在 Authing 控制台(点击文字底部阅读原文)登录页面点击第三方登录按钮(比如 Google、GitHub),系统自动弹出其第三方的登录页面; 请求:用户在第三方的登录页面输入该账户的账号信息及密码; 验证:第三方 IdP 验证用户身份; 授权:验证用户身份之后,浏览器携带临时凭证发送给 Authing 控制台,Authing 使用此凭证从第三方 IdP 换取该用户的信息。 在 Authing 产品中,我们将身份源提供商(IdP)分为以下几种: 社会化身份源: 企业身份源: 自定义数据库: 如果你希望将用户凭据存储在自己的服务器上,Authing 可以连接到你配置的自定义数据库,并将其作为身份源。本质上,你可以使用自定义脚本连接到任何种类的数据库或 Web 服务。 截止目前,Authing 一共支持国内外 20 多种社会化登录方式以及数十种企业身份源,Authing 还在持续扩充身份源目录,帮助企业和开发者减少重复开发,提高生产力。   Authing 是国内唯一以开发者为中心的全场景身份云产品,为企业和开发者提供高安全、高性能、高生产力的用户认证和访问管理服务。 Authing 目前已经服务包括可口可乐、招商银行、三星集团、复星集团、元气森林在内的 40000+ 企业和开发者。
开启零信任之旅的第一步|身份云研究院
2022 年一项报告显示,有超过 97% 的被调查组织已经制定或计划在未来几个月内制定一项明确的零信任计划,而在 2019 年这个数字只有 16%。实施零信任架构仍然是许多企业的首要任务。 根本原因在于,安全环境的变化导致传统的以网络边界为中心的安全策略已不再适用。疫情催化了混合办公和企业上云的进程,内部员工、外包员工、供应商、合作伙伴等可以在更多的设备和地点访问企业的内部资源,这导致企业的信息安全风险面剧增。据统计,全球网络攻击事件呈指数级增长,其主要攻击目标依然是身份。反过来说,企业决策者应该认识到,了解用户及其设备的身份是保护组织信息安全最基础和最关键的步骤,不论是员工、外包团队、设备、供应商、合作伙伴等,企业内外的每个实体都应进行身份认证才能获得对应操作的授权。 然而零信任还存在一个最大的误区,就是零信任并非是一个产品名称或者产品集合,组织实施零信任架构并非只需要通过采购几个零信任工具就能一蹴而就,它是一个伴随组织全生命周期的安全管理策略。 本文将主要探讨,为什么身份是零信任的基石?如何使用 Authing 开启零信任的第一步? 基础概念: 传统的安全管理方法是假定组织网络内的一切都可以信任; 零信任架构下的安全管理方法是假定所有用户、设备和网络都是不可信的; 核心原则: 身份是访问控制的基础:信任来自于端到端所有对象的身份,基于身份而非网络位置构建访问控制。 最小权限原则:资源访问按需分配,仅授予执行任务所需的最小特权。 实时计算访问控制策略:根据主客体信任评估和访问需求进行策略计算,并持续评估以保证策略实时变更。 资源受控安全访问:所有业务场景下全部资源基于单个访问请求连接,进行强制身份识别和授权、鉴权和通道加密。 基于多源数据持续进行信任评估:包括身份、访问上下文等的实时多源数据的多样性和可靠性,提升信任评估策略计算能力。 从身份治理开启零信任第一步 对于实施零信任的负责人来说,渴望依照一个符合企业现阶段实施零信任的范式执行以保证最高投入产出比。然而不同企业在准备实施零信任时处在各个不同的发展阶段,且面临的安全风险也不尽相同。对于已经采购了零信任工具的企业来说,也很难量化其实施的具体效果和回报。但每个企业都可以从身份治理开启零信任的第一步,并且越早实施边际效益越高。 身份是访问控制的基础单位,同样也是零信任架构的基石。在实际业务场景中,我们需要用身份来描述、控制和管理几乎所有事物,例如:员工、客户、承包商、本地应用程序、SasS 应用程序、API、服务器、虚拟机、容器、IoT、数据集、NFT 等。 零信任主张安全体系从网络中心化转变为身份中心化,所有访问行为都以身份为中心进行细粒度的自适应访问控制。企业默认不信任网络内外部的任何人、设备、系统和应用,而是应该基于认证和授权重构访问控制的信任基础,并且基于更多的数据源或上下文对访问者进行持续的可信度评估,根据评估结果动态地调整授权和访问控制策略。 理想状态下,持续不断的认证并且不给用户带来体感上的负担是企业平衡安全和用户体验的最佳实践。而企业需要知晓现阶段身份治理状态,以便更好地实施下个阶段的零信任策略。下文简述了四个阶段来帮助企业了解目前的身份治理状态。 直面混乱无序的身份管理 数字化背景下,企业开始接入越来越多本地应用和 SaaS 产品。而这些应用程序并没有有效地集成在一起,或者使用如 AD 等内部部署目录来管理。但传统的 AD 方案已经不能满足现代信息化需求,使用场景单一、拓展性低、配置复杂。 对于 IT 部门来说,需要逐个维护不同系统间的身份,导致更多无意义的重复劳动;对于用户来说,更多的系统意味着更多的账密,不一致的登录认证体验,更差的用户数字旅程;对于企业来说,除了上述问题,因为各系统间的数据割裂,企业无法有效发挥这些数据的价值;而对于非法入侵者来说,更多割裂的系统就有更多可攻击的窗口。 开始构建统一的身份管理 解决上述问题,从混乱无序到高效治理只需要通过 Authing 实现各个系统快速整合,以实现统一身份管理。通过 Authing 的 APN(应用网络)以及 ASA 实现企业内外部应用系统高效集成。通过 Authing 的单点登录,实现用户(员工、客户、外部供应商等)高效一致的登录认证体验。通过 Authing 的统一用户目录,统一用户身份数据标准,聚合用户数据。通过 Authing 的自动化身份供给能力,帮助 IT 部门只需要一处管理用户信息,即可实现全链路的身份信息同步及授权。 接入自适应的风控引擎 在实现统一身份管理的基础上,自适应身份管理能最大程度减少认证过程与用户体验间的摩擦。通过用户上下文信息(例如:地理位置、设备信息、行为分析等)自适应判断该用户对此应用访问的验证策略。例如当用户在陌生的位置登录、陌生的设备登录可以自动增加多因素认证(生物特征、验证码、令牌等)来判断该用户是否合规。或者当用户多次输入错误密码、或者试图下载敏感信息时自动增加多因素认证。或者当用户在企业安全的网络环境和地理位置时,可以设置不需要增加多因素认证,而且这些策略可以更加灵活自由的配置在不同的流程节点中。自适应统一身份管理不仅能有效提升用户体验,还能让 IT/安全部门实施更加灵活的信息安全策略。 最终实现自动化的身份中台 以身份为中心的零信任架构的更进阶的形态,则是实现全面的身份管理自动化。如同汽车制造自动化流水线,通过预设置机器人的工作流程,实现大规模高效的自动化生产,避免了人为操作失误,提高了生产力以及降低了制造成本。 同理,身份管理自动化在上述三个阶段基础上,企业根据现阶段企业安全战略,预设置基于不同业务场景需求的身份管理自动化流程,则可以完全自动化的零信任身份治理。规避了企业中大量的重复低效劳动以及人为操作失误的风险,大幅提升企业的效率和信息安全。并且随着企业的发展,可以随时根据不同阶段企业信息安全战略灵活调整和升级身份管理自动化流程。 信息安全是一个持续斗争的过程,而零信任则是这场斗争的指导战略。身份是零信任架构的基石,确保“正确的身份”在“正确的时间地点”享有“正确的权利”。对于所有企业来说,以身份为基础,通过 Authing,组织可以更高效更轻松地开启零信任之旅。如果您目前正在或计划实施零信任,可以点击官网链接,联系我们的身份专家为您讲解。
Authing 发布 「Authing 令牌」1.4.0 版本,提供安全跨端登录认证解决方案
「Authing 令牌」是 Authing 针对移动端设备的登录、认证及授权开发的工具型应用。目前支持 iOS 和 Android 系统,是 Authing 云原生身份管理产品的重要组成部分。 近日,Authing 令牌上线了 1.4.0 版本功能,该产品新增以下核心能力: 绑定 & 体验登录 Authing 控制台客户端应用及 Guard,并查看用户信息; 基于生物识别能力,支持系统级别的指纹识别及人脸识别认证登录; 通过移动端推送登录认证 Web 端应用,实现免密快速登录认证 Authing Web 端应用能力; 移动端应用扫码,完成移动端的快速登录认证; 绑定 & 体验登录 Authing 控制台客户端应用及 Guard,并查看用户信息: 您可以通过扫码或输入您在 Authing 控制台创建的客户端应用的信息,体验该应用的品牌化 Guard 及登录流程: 通过扫码录入应用信息并登录用户信息: 通过输入 URL 录入应用信息并登录用户信息: 基于生物识别能力,支持系统级别的指纹识别及人脸识别认证登录: 在设备支持的情况下,目前安卓系统应用支持指纹识别认证登录,iOS 系统应用支持指纹、人脸识别认证登录: 安卓指纹识别认证登录能力: iOS 人脸识别认证登录能力: 通过移动端推送登录认证 Web 端应用,实现免密快速登录认证 Authing Web 端应用能力: 您可以在配置好推送登录方式的 Guard 上,输入该用户的用户名/手机/邮箱后,Authing 令牌将会收到一条确认登录的 Push 消息,点击确认登录,即可快速完成基于设备的认证登录 : 移动端应用扫码,完成移动端的快速登录认证: 您可以在移动端应用扫描 Web 端具有登录态的二维码(目前位于 Web 端应用的个人中心),完成移动端的快速登录认证; 需要特别注意的是,某些功能只有在您的 IT 组织启用时才可使用。 有关详细信息,请查看 Authing Doc 文档。 网址 :https://docs.authing.cn/v2/guides/authingVerify/ Authing 同样支持通过集成安卓或 iOS SDK 到您自己的移动端 APP,来实现相应的能力。 有关详细信息,请查看 Authing Doc 文档。 网址 :  https://docs.authing.cn/v3/reference/mobile/sdk-for-android/install.html https://docs.authing.cn/v3/reference/mobile/sdk-for-ios/quick.html; Authing CEO 谢扬表示,Authing 令牌是一款轻量级应用程序,可让用户通过生物识别及 MFA 组合策略安全地访问应用程序,降低他人获得帐户访问权限的可能性,确保仅有帐户所有人本人能够访问其被授权的应用。未来,我们将在 Authing 令牌集成移动端的 SSO 单点登录面板,为所有移动和基于 Web 的应用程序可靠地集成 SEP,并提供完整的联合引擎和可扩展的访问策略。
Authing 入选《网络安全优质初创企业 HOT50》报告
近日,Authing 入选由安全牛发起的《网络安全优质初创企业 HOT50》(2023 版)报告。该报告旨在从创新技术应用角度,寻找推动我国网络行业更好发展与变革的新兴产业力量。该报告调研面向 2018 年后成立的国内网络安全初创企业,基于申报厂商的企业经营能力、成长性、技术先进性、资本关注度以及行业应用维度,从中筛选出 50 家代表性厂商进行年度推荐。 Authing 作为国内唯一一款以开发者为中心的 IDaaS 产品,通过图模型的编排引擎替代决策树编排,在高安全、高可用、高性能的前提下,实现上下游平台身份 APIs 全生命周期高效管理与灵活连接。提供 OPA(组织过程管理) SaaS,完善 OPA 计算监控、事件监控、决策监控、决策设计器、代码编写等,覆盖决策计算全生命周期,以实现下一代事件驱动的低代码决策引擎和自动化风控引擎。助力企业大幅提升企业身份治理效能。 权威认可 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。 关于 Authing Authing 是国内唯一以开发者为中心的全场景身份云产品,为企业和开发者提供高安全、高性能、高生产力的用户认证和访问管理服务。 Authing 目前已经服务包括可口可乐、招商银行、三星集团、复兴集团、海底捞、元气森林、知乎在内的 30000+ 企业和开发者。
喜报|Authing 又新签这些客户啦!
Authing 是国内唯一一款以开发者为中心的 IDaaS 产品,在高安全、高可用、高性能的前提下,实现上下游平台身份 APIs 全生命周期高效管理与灵活连接,实现下一代事件驱动的低代码决策引擎和自动化风控引擎,助力企业大幅提升企业身份治理效能。 Authing 既是客户的支持者,也是客户的产品专家和战略顾问,更是值得信赖的合作伙伴。我们提供全球化的身份专家支持团队,7*24 小时不间断支持。“客户第一”是刻在 Authing 基因中的使命,客户的成功,就是 Authing 的成功。 截止目前,Authing 已经服务了包括可口可乐、招商银行、复兴集团、海底捞、元气森林在内的 40000+ 企业和开发者。近期,我们又与一批国内外各领域领先的企业达成合作,本文仅展示部分近期签约的代表性企业。   01 云南白药 & Authing 云南白药创制于 1902 年,集品牌、产品和公司名称于一身,业内公认是中华老字号最具有创新力的代表。品牌价值 300 多亿元,排全国药企前 4 、中药第 1,2021 年 7 月入选全球制药品牌价值 25 强、被评为中国最强的医药品牌,入选 2021 全球药企排名第 34 。1993 年作为云南第一股上市,1999 年全面进行现代化企业再造,2016 年至 2019 年完成混改和整体上市。云南白药把守护生命与健康作为企业使命,致力于成为领先的医药健康综合解决方案提供商。   02 广发证券资产管理 & Authing 广发证券资产管理有限公司系广发证券旗下全资子公司,是华南地区首家券商系资产管理公司。广发资管全面继承了广发证券原资产管理部的相关业务,各项指标基本保持在券商资管的第一梯队。广发证券(广发证券股份有限公司)是国内首批综合类证券公司,先后于 2010 年和 2015 年在深圳证券交易所及香港联合交易所主板上市。公司被誉为资本市场上的“博士军团”,在竞争激烈、复杂多变的行业环境中努力开拓、锐意进取,以卓越的经营业绩、持续完善的全面风险管理体系及优质的服务持续稳健发展,成立 31 年来,始终是中国资本市场最具影响力的证券公司之一。   03 北京信息科技大学 & Authing 北京信息科技大学,是一所以工学为主,工、管、理、经、文、法 6 个学科门类协调发展的北京市重点支持建设高校,工信部国防科工局与北京市共建高校,入选教育部“卓越工程师教育培养计划”、国家“ 111 计划”、首批北京市深化创新创业教育改革示范高校、首批北京市属高等学校数字校园示范校,是“一带一路”中波大学联盟首批成员。   04 法大大 & Authing 法大大(深圳法大大网络科技有限公司)是国内领先的电子合同与电子签云服务平台,致力为企业、政府和个人提供基于合法数字签名技术的电子合同和电子单据的在线协同签署及管理服务,构建商业契约的数字化基础能力,助力企业数字化转型和社会数字化升级。法大大电子合同与电子签平台通过 SaaS 和 OpenAPI 为用户提供便捷、安全、公正的云服务,企业的各种数字化业务系统、IT 系统及产业互联网平台,可与法大大平台无缝集成,实现具体业务场景与电子签的全链路数字化闭环,进而促进业务发展、效率提升、安全保障和风险控制。   05 本末科技 & Authing 直驱型精准动力专家本末科技(本末科技有限公司 )致力于使用直驱技术,去除任何机器中的减速器,使得原本娇贵、吵闹、低效、笨重的传统机器脱胎换骨。本末拥有机器人关节方面从传感器、驱动器到电机本体的全套设计生产技术,同时独特的直驱方案也为众多行业提供了与传统减速器方案差异化的产品选择。目前,本末科技的产品主要服务于家用机器人、工/商用机器人、健身行业等若干领域。本末科技颠覆式的直驱型精准动力解决方案,也正在为更多行业提供着与众不同的产品可能。   06 智信科技& Authing 福建智信科技有限公司作为国家高新科技企业、福建省科技型企业、福建省重点上市后备企业,是一家专注于通信业务和数字商品服务平台开发及运营的公司,自主研发具有独立知识产权的“满天星”数字商品服务云平台,连接 1500 多个代理渠道,遍布全国 31 个省市 33600 个线上线下分销网点,服务 300 多个行业客户,每年为 12 亿人次提供高效、安全、多元化的数字商品,是国内数字商品行业发展最快速的互联网企业之一。   点击 Authing 官网 预约身份专家讲解客户案例          
OIDC & OAuth2.0 认证协议最佳实践系列 02 - 授权码模式接入 Authing
在上一篇文章中(OIDC & OAuth2.0 协议及其授权模式详解|认证协议最佳实践系列【1】),我们整体介绍 OIDC / OAuth2.0 协议,本次我们将重点围绕授权码模式(Authorization Code)以及接入 Authing 进行介绍,从而让你的系统快速具备接入用户认证的标准体系。 接入 Authing 后的优势: 在整个 Authing 的身份源中,已经包含了社会化登录方式 微信、微博、QQ、FB、TW ...等等,企业登录方式 飞书、钉钉、企微、AD 等等,只要你完成了接入 Authing 就意味着你的业务系统具备了这些能力。 01 授权码模式(Authorization Code) 1.1 整体流程 整体上,有以下流程: 在你的应用中,让用户访问登录链接,浏览器跳转到 Authing,用户在 Authing 完成认证。 浏览器接收到一个从 Authing 服务器发来的授权码。 浏览器通过重定向将授权码发送到你的应用后端。 你的应用服务将授权码发送到 Authing 获取 AccessToken 和 IdToken,如果需要,还会返回 refresh token。 你的应用后端现在知道了用户的身份,后续可以保存用户信息,重定向到前端其他页面,使用 AccessToken 调用资源方的其他 API 等等。 流程图如下: 1.2 准备接入 在 Authing 创建应用及配置 创建应用: 配置登录回调和登出回调,配置为你实际项目的地址,我们在这里配置 localhost 用于测试。 若你想匹配多个登录/登出回调,可以使用 ‘*’ 号进行通配,登录/登出回调可以是如下格式: 在协议配置中,我们勾选 authorization_code 并且使用 code 作为返回类型,如下图所示: 1.3 接入测试 01 所需调用接口列表   GET${host}/oidc/auth 发起登录(拼接你的发起登录地址) POST${host}/oidc/token 获取 Token GET${host}/session/me 获取用户信息 POST${host}/oidc/token/introspection 校验 Token POST${host}/oidc/token 刷新 Token POST${host}/oidc/revocation 吊销 Token GET${host}/session/end 登出   02 Run in Postman 以下要介绍的接口可以通过我们的在线 postman collection 自行 fork 体验。 03 发起登录   GET${host}/oidc/auth 这是基于浏览器的 OIDC 的起点,请求对用户进行身份验证,并会在验证成功后返回授权码到您所指定的 redirect_uri。 拼接发起登录地址(浏览器中打开): https://{host}/oidc/auth?scope=openid+profile+email+phone+username&redirect_uri={redirect_uri}&response_type=code&client_id={应用 ID}&state={state} 如您需要额外获取 refresh_token 则请求格式为: https://{host}/oidc/auth? scope=openid+profile+offline_access+username+email+phone&redirect_uri=http://localhost:8080/&response_type=code&client_id={应用 ID}&prompt=consent&state={state} 点此体验: https://oidc-authorization-code.authing.cn/oidc/auth?scope=openid+profile+offline_access+username+email+phone&redirect_uri=http://localhost:8080/&response_type=code&prompt=consent&nonce=054d3c0e-9df9-46f2-a8fa-a7f479032660&client_id=63eb4585156d977101dd3750&state=1676366724 参数说明: 04 获取 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}'   响应示例 (成功) { "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": "授权码无效或已过期" }   05 通过 AccessToken 获取用户信息   GET${host}/session/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": "Access Token 无效" }   06 校验 Token   POST${host}/oidc/token/introspection   此端点接受 access_token、id_token、refresh_token ,并返回一个布尔值,指示它是否处于活动状态。如果令牌处于活动状态,还将返回有关令牌的其他数据。如果 token 无效、过期或被吊销,则认为它处于非活动状态。   1.验证 Token 分为两种方式: 本地验证与使用 Authing 在线验证。我们建议在本地验证 JWT Token,因为可以节省你的服务器带宽并加快验证速度。你也可以选择将 Token 发送到 Authing 的验证接口由 Authing 进行验证并返回结果,但这样会造成网络延迟,而且在网络拥塞时可能会有慢速请求。 access_token 可以使用 RS256 签名算法或 HS256 签名算法进行签名。下面是这两种签名算法的区别: RS256 是使用RSA算法的一种数字签名算法,它使用公钥/私钥对来加密和验证信息。RS256 签名生成的令牌比 HS256 签名生成的令牌更加安全,因为使用RSA密钥对进行签名可以提供更高的保护级别。使用RS256签名算法的令牌可以使用公钥进行验证,公钥可以通过 JWK 端点获取。 HS256 是使用对称密钥的一种数字签名算法。它使用同一个密钥进行签名和验证。HS256 签名算法在性能方面比 RS256 签名算法更快,因为它使用的是对称密钥,而不是使用 RSA 公钥/私钥对来签名和验证。使用 HS256签名算法的令牌可以通过 shared secret (应用密钥)进行验证。 在实际应用中,RS256算法更加安全,但同时也更加消耗资源,如果系统需要高性能,可以选择 HS256 签名算法。 以下是本地验证和在线验证的优劣对比: 2.在线验证 需要注意的是,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 }   3.离线校验   可参考文档:离线校验 ( 文档链接:https://docs.authing.cn/v2/guides/faqs/how-to-validate-user-token.html# ) 我们简单说下,若您使用离线校验应该对 token 进行如下规则的校验: 1.格式校验 - 校验 token 格式是否是 JWT 格式 2.类型校验 - 校验 token 是否是目标 token 类型,比如 access_token 、id_token、refresh_token 3.issuer 校验 - 校验 token 是否为信赖的 issuer 颁发 4.签名校验 - 校验 token 签名是否由 issuer 签发,防止伪造 5.时间校验 - 校验 token 是否在有效期内 6.claims 校验 - 是否符合与预期的一致 以上 6 点均校验通过,我们才能认为 token 是有效且合法的。 下面是一个示例 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; } } 这段代码使用 Nimbus JOSE+JWT 库来解析和验证 JWT token。它使用指定的 issuer 和 audience 值对access_token 进行验证,并验证 JWT 中 claims 的格式、类型、签名、有效期和 issuer。如果发生任何验证错误,则将抛出 RuntimeException。使用时需要传入对应的 JWK URL 和 access_token 进行调用,例如:   这个示例只校验了RS256和HS256签名算法。 07 刷新 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 无效或已过期" }   08 撤回 Token   POST${host}/oidc/token/revocation   撤销 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" }   09 用户登出   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 SSO (Single Sign-On) 单点登录 & SLO (Single Logout) 单点登出 2.1 SSO 实现 SSO(Single Sign-On) 单点登录,即同时访问多个应用仅需要登录一次。 举例:我们现在有两个站点分别是 http://uthing.com http://ething.com 我们希望用户在 http://uthing.com 进行认证后,跳转到 ething 后无需二次认证,反之也是一样的。 具体流程: 1.用户访问 http://uthing.com ,uthing 前端发现用户未认证,跳转至 Authing 进行认证。 2.用户在 Authing 发起认证完成,Authing 创建 SSO Session ,下发临时授权码 (code) 重定向到 uthing 后台。 需要注意的是,在这里我们也可以重定向到前端页面,再由前端页面自行判断如果是 Authing 回调请求,则携带临时 code 到 uthing 后台去获取 token 。 3.uthing 后台通过 code 向 Authing 换取 access_token、id_token、refresh_token 等,并下发给前端。 4.uthing 前端通过 access_token 可以直接向 Authing OIDC 用户信息端点获取当前用户信息。 5.uthing 前端在在后续请求后台时,携带由 Authing 颁发的 access_token ,后台在接受到用户请求后去 Authing 校验 Token 是否有效,有效则可放行,若 Token 校验失败或已过期则返回错误信息。 6.用户访问 http://ething.com ,ething 跳转至 Authing 进行认证。 7.由于用户在 Authing 已经完成认证,创建了 sso_session ,Authing 侧直接下发临时授权码 (code) ,无需二次认证,后续流程同 1 。   我们发现,用户在 uthing 认证成功的时候,再访问 ething 的时候会向 Authing 跳转一下,才能完成后续流程,这是由于 http://ething.com 和 http://uthing.com 并不是同一个站点,无法实现 cookie 共享,如果你的产品地址是 : http://uthing.xxx.com http://ething.xxx.com 我们则可以利用相同域下 cookie 共享的方式实现 SSO ,从而避免此问题。 2.2 SLO 实现 SLO(Single Logout) 单点登出,即多个应用仅需要登出一次,其他应用也自动登出 。 01 场景 1 如果你的产品地址是同一个域,例如: http://uthing.xxx.com http://ething.xxx.com 则 SLO 流程如下: 1.用户在某个站点登出,我们则需要调用 OIDC 登出端点销毁 Token,由于是 cookie 共享实现的 SSO ,然后清除 http://xxx.com 对应会话的 cookie 即可。 2.ething / uting 应当在每次发起请求前,判断 cookie 中是否存在登录态,若不存在,则需要跳转默认页面提示用户已经登出。 02 场景 2 如果你的产品地址不是同一个域,例如: http://uthing.com http://ething.com 则 SLO 流程如下: 1.用户在某个站点登出,我们则需要调用 OIDC 登出端点销毁 Token,在 Authing 的应用配置中,你应当先把应用都添加到 SSO 中,或者 http://uthing.com 和 http://ething.com 使用 Authing 的同一个自建应用,当用户在某个站点登出后,另外一个站点的 Token 也会失效。 2.用户未登出的站点发起请求,当后台校验 Token 失败后,则下发清除 cookie 的命令并跳转默认页面提示用户已经登出,需要登录。 03 本章总结 本章我们介绍了 OIDC 授权码模式的接入流程以及相关接口的调用方式,对于小白来说可能需要整体跑一遍流程才能熟悉,我们也建议你 fork 我们的 postman collection 跑一遍流程,对授权码模式你就基本掌握啦。 接下来我们还会介绍 OIDC 的授权码+PKCE 流程,以及接入 Authing 的方式,需要你对授权码模式的流程有一定了解哦。
Authing 官方
·
2023.03.03
·
1046 人阅读
什么是事件驱动(EDA)?为什么它是技术领域的主要驱动力?|身份云研究院
伴随企业数字化进程进入“深水区”,企业面临着日益复杂的 IT 系统和业务流程,不同系统间的壁垒导致企业运转效率下降以及协同摩擦增加。而事件驱动架构(Event-Driven Architecture,EDA)已成为解决这些问题的关键技术。 事件驱动是指在分布式系统中,各个组件之间的交互基于事件通信,而非直接的请求-响应模式,具有异步、松散耦合等特征。在 EDA 中,组件之间通过发布(Publish)和订阅(Subscribe)事件来实现协作,事件可以是用户操作、系统状态变化、传感器数据等。 Gartner 将事件驱动架构(EDA)列为十大战略技术趋势之一,并强调事件驱动架构 (EDA) 是技术和软件领域发展的主要驱动力。EDA 是实时敏捷数字业务的核心,通过“监听”物联网 (IoT) 设备、移动应用程序、生态系统以及社交和业务网络等事件源,以数字形式实时捕获真实世界的业务事件。 过去,以 API 为中心的应用程序设计架构显著提升了业务的敏捷性,但随着数字化业务场景越来越复杂,企业对于实时智能、敏捷响应、上下文自适应等需求增加。仅依靠 API 为中心的请求驱动模型就显得力不从心。随着越来越多数字化系统的接入,应用程序变得更难拓展,连接的 API 网络更难管理,不同系统间的数据壁垒越筑越高,系统的耦合度越来越高。而依托事件驱动架构异步、松耦合的特性,将各个业务系统解耦,降低系统间的依赖程度,最大程度提升企业数字敏捷性。 本文将主要探讨什么是事件驱动?事件驱动对业务的帮助和价值是什么?   01 什么是事件驱动? 想象一个常见的场景。 当你的公司需要招聘一名新员工,基础流程包括:发布职位广告-面试-录用-人事准备-入职程序-工作安排。这是一个基础的招聘流程,在这个流程中,每一个步骤都是基于一个特定的事件来进行的。例如,招聘过程是基于公司需要新员工这个事件的触发来进行的;面试是基于收到应聘者申请这个事件的触发来进行的;录用是基于面试考核通过这个事件的触发来进行的。 以上是一个常见的事件驱动用例。该用例是企业标准的招聘流程或系统,企业管理者只需要搭建好整套招聘流程和拟定标准,以及每个节点所需要的人员。在管理者需要招聘新员工时,只需要发布指令,该招聘系统则会自动依照流程运作,直至返回招聘结果。以上述场景为例,事件驱动架构主要包括四个关键组件: 事件:在系统中发生的任何事情都可以看作是一个事件。在员工入职流程中,例如发布招聘广告、收到应聘者申请、发出录用通知、完成培训等都可以看作是事件。 事件源:事件源是触发事件的对象。在员工入职流程中,例如发布招聘广告的人员、收到应聘者申请的招聘专员、发出录用通知的人事专员等都可以看作是事件源。 事件处理程序:事件处理程序是针对特定事件的处理逻辑。在员工入职流程中,例如招聘专员负责面试和录用流程,人事专员负责人事准备和入职程序,部门经理负责为新员工安排工作等都可以看作是事件处理程序。 事件队列:事件队列是用于存储事件的数据结构。在员工入职流程中,事件队列可以是公司的招聘管理系统或人事管理系统。 在事件驱动架构中,事件源触发一个事件,该事件被放入事件队列中等待被处理。事件处理程序从事件队列中获取事件并执行相应的逻辑,最终完成事件的处理。在上述员工入职流程中,当公司需要新员工时,招聘专员发布招聘广告并收到应聘者申请,这些事件会被放入事件队列中,招聘专员则会从事件队列中获取这些事件并执行面试和录用流程。 在实际业务场景中,虽然有很多数字化工具帮助处理相关信息,但依旧有很多程序需要手动执行,不仅效率低,还存在很多因人为操作失误带来的风险隐患。 例如在上述场景中,员工各类应用系统账号创建、各系统员工身份数据的同步(包含权限等)、员工入转调离身份信息管理、员工离职后的权限及信息删除等员工全生命周期管理均需要手动操作。这无疑是一项重复机械的劳动,对于体量较大的或人事变动较多的组织来说更是如此。并且还存在因为漏关权限等人为误操作带来的企业信息安全隐患。而基于事件驱动架构设计的身份自动化编排系统,则可以通过无代码的形式将员工全生命周期编排成一个事件流,以实现员工全生命周期自动化管理,同样的场景也可以复用在用户、合作伙伴管理中。 当然,以上仅仅是一个基础用例。基于事件驱动的身份自动化管理系统还拥有无穷的想象和创新空间。   02 事件驱动对企业的价值 Gartner 报告指出,掌握“事件驱动的 IT”和以事件为中心的数字业务战略将成为大多数全球企业 CIO 的首要任务。企业严重依赖技术来构建可扩展、敏捷和高度可用的业务。事件驱动架构正在成为支持现代企业实时运营、快速适应变化并做出明智业务决策的关键基石。 降低系统之间的依赖性 在传统的系统中,不同的组件需要在代码层面进行耦合,例如通过函数调用或共享变量等方式。这种紧密的耦合会导致组件之间高度依赖,当一个组件需要修改时,往往需要同时修改其它组件的代码,这样会导致系统的不稳定性和难以维护。 相比之下,事件驱动架构中,组件之间通过事件进行通信,而不是直接调用代码或共享变量。当一个组件完成某个任务时,它将触发一个事件,然后将这个事件发送给系统中的其他组件。其他组件可以根据自己的需要选择是否要监听这个事件,如果监听则可以响应事件并执行相应的操作。这种机制使得系统中的组件可以相对独立地进行开发和维护,减少了代码之间的耦合度。 这种松耦合方式使得系统具有更高的可维护性和可扩展性。当需要修改某个组件时,仅需要对该组件进行修改,而不需要同时修改其他组件的代码。这不仅简化了开发过程,同时也使得系统更加健壮和灵活,因为不同的组件可以独立地进行部署和升级。同时,这种事件驱动架构的松耦合特性也使得系统更加容易进行扩展和集成,因为新的组件可以很容易地添加到系统中而不会影响到其他组件的运行。 提高可用性和可靠性 传统的系统通常采用紧耦合的方式,即各个组件之间紧密依赖,一个组件的故障很容易影响到其他组件的正常运行,从而导致系统的故障和不可用。在事件驱动架构中,当某个组件出现故障时,其他组件可以选择是否监听该事件,不受影响的组件可以继续执行自己的任务而不受影响。因此,这种松散的耦合方式可以提高系统的可用性和可靠性。 此外,事件驱动架构还可以通过异步事件处理的方式来提高系统的可用性和可靠性。异步事件处理的特点是事件的处理是非阻塞的,即组件不需要等待事件的处理结果就可以继续执行自己的任务。这种处理方式可以降低系统的延迟,并且能够处理大量的并发请求,从而提高系统的性能和可靠性。 事件驱动架构还可以通过实现事件溯源机制来提高系统的可靠性和容错性。事件溯源机制是指将事件的历史状态记录下来,并且可以回溯到任何一个事件的状态。这种机制可以帮助企业快速恢复系统,以及减少因故障而导致的数据丢失。通过记录和回放事件,企业可以更加容易地发现和解决系统的问题,从而提高系统的可靠性和容错性。 敏捷开发 事件驱动架构可以帮助开发人员更快地开发和部署应用程序。由于每个组件都是独立的,因此可以并行地开发和测试每个组件,从而缩短应用程序的开发时间。在部署方面,企业可以选择只部署需要的组件,而不是整个应用程序,这将进一步加快部署速度。 支持灵活的架构演进 企业可以通过向系统中添加新的事件、更改现有事件的结构或添加新的组件来扩展其功能。通过这种方式,企业可以实现较小的增量更改,同时仍保持整个系统的稳定性和可靠性。 另外,事件驱动架构还可以通过使用适当的事件类型来促进组件之间的松散耦合。例如,企业可以定义通用事件类型来处理跨多个组件的通信和协作。这种松散耦合使得企业可以更容易地更改系统的某些部分而不影响整个系统。 在灵活的架构演进方面,事件驱动架构还支持多种部署选项。企业可以选择在本地、云端或混合部署中使用事件驱动架构,以适应其业务需求和可用资源。 实时的数据处理与分析 在事件驱动架构中,事件是系统的核心,组件通过触发和处理事件来进行通信与协作。因此,事件驱动架构非常适合处理实时数据,并且可以轻松地将数据从一个组件传输到另一个组件。企业可以构建实时数据处理系统,从而更快地对业务数据做出决策和反应。例如,企业可以使用事件驱动架构来监控网站流量、分析用户行为、检测异常等。在这种情况下,组件可以通过触发和处理事件来快速响应这些实时数据,并执行必要的操作。 此外,事件驱动架构也可以用于构建复杂的数据流处理系统,例如处理大数据、实现实时分析等。这些系统需要处理大量的数据,并且需要快速而准确地处理数据。事件驱动架构可以通过使用分布式事件处理系统来实现这些目标,同时保持系统的可扩展性和可靠性。这些优势可以帮助企业更好地了解自己的业务,优化业务流程,并提高企业的竞争力。   推荐阅读: 市场营销新视角,从这一步开始与竞对拉开距离|身份云研究院 ChatGPT 用户破亿背后... 如何增强企业数字敏捷性?|身份云研究院  
Online
Contact us online
To create a perfect identity system
WeCom
authing
Add Wecom to receive industry information
Token
authing
authing
Download the Authing token and experience fast login authentication!
Free Trial
Online
Phone