在当今数字化时代，网络安全已成为全球企业和个人无法回避的重要议题。网络威胁的种类和复杂性也日益增加，网络安全领域将面临一场深刻的变革，充满挑战与不确定性。2025 年，网络安全将迎来更复杂、动荡，充满风险和不确定性的新时代。从零日漏洞频发到供应链攻击的日益加剧，再到人工智能系统的滥用，网络攻击的方式正在发生前所未有的变化。身份和访问管理（IAM）已经成为企业网络安全的核心组成部分。身份不仅是用户和系统之间的访问桥梁，更是企业防御外部攻击、确保数据安全的第一道防线。2025 年身份领域将迎来三大重要趋势，企业如何在数字化竞赛中占得先机，稳居安全防线的最前沿。 01.零信任将在身份领域占据 C 位 根据 Gartner 的预测，2025 年全球信息安全终端用户支出预计将达到 2120 亿美元，较 2024 年的 1839 亿美元增长 15.1% ，其中安全服务增速最快。随着对安全需求日益增长，零信任（Zero Trust）模型已成为现代网络安全架构的核心。零信任模型专注于验证每一个试图访问系统的人和设备，作为网络安全的最佳实践正在获得认可。零信任框架的“永不信任，总是验证”的原则在组织面临日益复杂的网络攻击时变得更加重要。任何用户或设备在其身份和授权得到验证之前都不被信任，不能访问资源，而是通过持续的验证和监控来确保网络资源的安全访问。2025 年，零信任不仅仅是为了保护数字资产，它还将重新定义企业的整体安全框架，应对生成式 AI 的崛起和数字生态系统架构的变化。AI 将通过智能自动化、自适应安全机制和实时风险分析，进一步增强零信任架构的能力。而零信任框架将保护 AI 系统本身，确保 AI 应用程序和数据免受新型威胁的侵害。两者相辅相成，共同为企业构建出更加弹性、可扩展且主动应对安全挑战的网络防护体系。 02.基于 AI 的身份防护成为关键 Gartner 预测，到 2027 年，总体网络攻击中约 17% 将涉及生成式人工智能（GenAI）。生成式人工智能的普及加剧了身份威胁的复杂性，同时也提升了安全防御的潜力。AI 在防御和攻击策略中处于前沿。诸如 ChatGPT 和 Bard 这样的 AI 工具，在利用大语言模型展示了生成式 AI 转变商业流程的同时，也带来了新的风险。生成式 AI 的普及使得身份威胁的复杂性大大增加，黑客不再仅仅依靠传统的攻击手段，而是借助 AI 加速漏洞发现、生成更具欺骗性的网络钓鱼攻击、以及采用更加隐蔽的恶意软件规避技术。开发者在构建和维护企业身份安全体系时，必须认识到 AI 技术在防护过程中的核心作用，并积极应用基于 AI 驱动的身份平台。基于 AI 驱动的身份平台能够通过高级身份验证手段，如生物识别技术、行为分析和多因素认证（MFA），为用户提供更强的安全保障。利用 AI 的能力实时分析和识别潜在的异常行为，有效预防身份盗窃、欺诈和其他身份相关的攻击。 03.量子加密浮出水面 在 2024 年量子计算取得了显著进展，量子处理器在量子比特稳定性和可扩展性方面达到了里程碑式的成就。IBM、谷歌等公司均已宣布推出量子系统，能够解决传统计算机无法高效解决的问题。量子计算正在迅速从理论研究转向实际应用。随着量子计算逐渐从理论走向实际应用，网络安全成为其最直接的影响领域之一，尤其是在保护数字身份的领域。未来，越来越多企业将普遍采用量子抗性加密和量子密钥分发技术，来加强身份管理体系。企业需要尽早布局，更新身份认证架构，采用量子安全技术来保护用户身份和敏感数据。随着量子技术逐渐成为主流，基于量子的身份认证平台将成为未来网络安全防护的核心组成部分。由于量子计算机尚未普遍可用或适用于所有应用，结合量子和经典技术的混合系统正在作为过渡解决方案出现，并可能成为未来企业身份管理的主流。 04.三大身份安全技术，快速提升企业安全防护力 持续自适应多因素认证 - 企业零信任最佳范式 Gartner 提倡为了实现对更复杂威胁的防控，建议将安全思维方式从“应急响应”到“持续响应”转变。下一代的安全保护流程的核心是持续、普遍的监控和可见性，企业的安全监控应该无处不在，并尽可能多的包含 IT 堆栈层，包括网络活动、端点、系统交互、应用程序事务和用户活动监控。「持续自适应多因素认证（Continuous Adaptive Multi-Factor Authentication，CAMFA）」是一种安全身份验证方法，它在自适应多因素认证（基于上下文属性判断当前安全状况以增加因素认证）的基础上增加了实时风险评估技术对用户进行动态评估安全系数。在时间维度上，持续自适应多因素认证在用户整个使用旅程中持续不断的对其进行信任评估，以决定是否需要增加额外的认证流程。这样做的好处就是企业的安全得到实时监控，而用户只会在进行风险操作时被提示需要进行额外的认证。 基于 AI 的用户行为检测 Authing 通过集成 AI 和机器学习算法，能够从用户的行为数据中识别潜在威胁，实时监测并评估用户风险。当系统从断层登录检测到用户时，或尝试访问其平时不常接触的的敏感资源时，AI 会标记这些异常行为并触发相应的安全响应步骤，如动态增加认证要求。基于 AI 的分析能够在短时间内完成风险评估，自动决定是否进行额外的验证步骤，确保对异常活动的快速反应。AI 行为分析不仅局限于登录检测，还能对用户在整个身份生命周期中的活动进行全面监控。系统能够识别并标记出用户在非常规时间段或不同设备上的登录行为，或者是其访问的资源异常，这些都可能是攻击者试图通过伪装成正常用户的方式进行攻击的迹象。通过与现有身份管理系统的深度集成，Authing 能够根据这些行为特征，快速进行动态身份验证，减少人工干预的需要，并且能在数秒内做出反应。 后量子密码系统 随着量子计算的发展，传统加密算法面临被破解的风险。而后量子密码学致力于开发能够抵御量子计算攻击的密码算法，如格基密码和哈希签名等。抗量子密码（PQC），也称后量子密码，是能够抵抗量子计算对公钥密码算法攻击的新一代密码算法，旨在研究密码算法在量子环境下的安全性，并设计在经典和量子环境下均具有安全性的密码系统。其基于数学原理，以软件和算法为主，依赖计算复杂度，易于实现标准化、集成化、芯片化、小型化和低成本，能够提供完整的加密、身份认证和数字签名等解决方案。PQC 的出现，可有效地防止攻击者窃取和破解加密信息，为网络信息安全提供保障。除了抗量子密码外，将现有密码系统向能够抵御量子计算攻击的后量子密码系统迁移也是一项重要任务。后量子迁移过程需对现有的密码系统进行评估和分析，确定其在量子计算机攻击下的脆弱性，并设计出能够抵御量子攻击的替代方案。Authing 将 PQC 与身份认证相结合，结合了传统的经典加密技术和新兴的后量子密码算法，掌握后量子密码算法和协议及其性能特点等，及国内外相关标准化进展并研究了密码系统风险评估、迁移策略等制定了相关方案，为企业提供了一种既能利用现有的加密技术，又能逐步引入量子安全的平衡方案。企业可以通过逐步替换现有的脆弱加密算法，采用后量子加密标准，并通过混合系统逐步建立起对量子攻击的抵御能力。混合系统的优势在于，它能够平滑过渡到量子安全的未来，同时确保系统的兼容性和性能不会因为完全依赖新技术而受到影响。

近日，为规范银行业保险业数据处理活动，保障数据安全、金融安全，促进数据合理开发利用，维护社会公共利益和金融消费者合法权益，金融监管总局制定《银行保险机构数据安全管理办法》（以下简称《办法》）。《办法》强调了数据分类分级与安全管理的重要性，而身份数据作为最具敏感性和关键性的核心数据涉及客户信息保护，甚至直接影响金融交易的合法性与安全性。针对身份数据的管理与保护，是银行保险机构履行合规义务的核心，也是提升数字化运营效率、强化客户信任的重要基础。如何从企业内部开始，确保员工、合作伙伴、客户等各方实体的身份安全成为解决问题的关键。 01.《办法》重要内容 强化数据治理顶层设计。要求银行保险机构建立与业务发展目标相适应的数据安全治理体系，落实数据安全责任制，按照“谁管业务、谁管业务数据、谁管数据安全”的原则开展数据安全保护工作。 落实分类分级管理要求。要求对业务经营管理过程中获取、产生的数据进行分类管理。根据数据的重要性和敏感程度，将数据分为核心、重要、一般三个级别，并将一般数据进一步细分为敏感数据和其他一般数据，并采取差异化的安全保护措施。 强化数据安全管理体系。要求银行保险机构建立健全数据安全管理制度，对委托处理、共同处理、转移、公开、共享等相关数据处理活动开展安全评估，采取相应技术手段保障数据全生命周期安全，保障数据开发利用活动安全稳健开展。 加强个人信息保护。按照“明确告知、授权同意”的原则处理个人信息，按照金融业务处理目的的最小范围收集个人信息。共享和向外部提供个人信息，应履行个人告知及取得同意的义务。 完善风险监测处置机制。将数据安全风险纳入全面风险管理体系，明确数据安全风险监测、风险评估、应急响应及报告、事件处置的组织架构和管理流程，有效防范和处置数据安全风险。 02.内部身份治理是金融安全第一道防线 在金融行业的多重安全防护体系中，内部身份治理无疑是第一道防线。这不仅仅是因为它涉及到每一个企业内部与外部的角色——员工、合作伙伴、供应商、客户等，还因为它直接关联到企业的核心业务数据和资产。在各种金融机构中，身份治理的应用有所不同但目的相同——确保数据安全。无论是为了应对各种复杂的安全威胁，还是为了满足日益严格的合规要求，强大和高效的内部身份治理系统都是不可或缺的。通过精准的身份管理和权限控制，金融机构可以在业务场景中建立信任边界，将敏感信息的访问控制在授权范围内，形成一堵坚实的“防火墙”。 应用场景多样化 随着金融业务的复杂化和全球化，身份治理的应用场景变得愈加多元。不同类型的金融机构在身份治理中的侧重点有所差异。例如，银行机构在日常运营中，需要为分行员工、客户经理以及客户提供高度灵活的权限管理，以支持他们在不同场景下高效协作，同时保证客户敏感信息的安全性。而对于保险公司而言，代理人团队的分级管理和客户数据的保护则是身份治理的核心所在，帮助规范信息访问权限、避免数据滥用，并提升客户信任度。无论场景如何变化，身份治理的目标始终如一。保护数据安全，维护业务的连续性，助力机构合规运营，同时增强客户体验和内部管理效率。 外部威胁增加 金融机构面临的外部威胁正在以指数级速度增长，从传统的网络攻击到高级持续性威胁（APT），再到针对身份信息的钓鱼攻击，无不考验着机构的安全防护能力。传统的静态管理模式显然已无法满足现代金融环境的需求。金融机构亟需引入动态化、智能化的身份治理体系，以应对不断变化的威胁态势。只有这样，金融机构才能从根本上防范身份安全漏洞，将内部身份治理转化为企业的竞争优势和数字化创新的重要保障。 内部身份治理与法规合规 金融企业需要遵循多种法规，而法规通常都有严格的身份和数据管理要求。这些法规都明确要求金融机构对客户和员工的身份信息进行严格管理，并确保数据的安全性和隐私保护。合规的身份治理体系不仅有助于企业防范法律风险，避免因违反相关法规而受到罚款或其他法律责任的追究，还能在市场中建立企业的声誉，提升客户对企业的信任度，促进企业的长远发展。 03.构建智能化身份治理体系，推动金融安全全面升级 与其他行业相比，金融行业在信息技术和数据应用方面通常更为先进。这意味着，金融机构不仅需要解决当前的安全问题，还需要有预见性地考虑未来的发展趋势和可能的风险。只有建立了一套完善的内部身份治理体系，金融机构才能有效地进行数据分析、客户关系管理、算法交易等高级业务活动。Authing 与金融机构数据安全治理的核心目标深度契合，为银行保险机构在数据安全管理方面提供了全面支持和保障。基于事件驱动的身份自动化基础设施Authing 提供了国内首个身份自动化平台，Authing 身份自动化平台是基于事件驱动的下一代身份领域业务策略和数据策略的可视化工作流编排平台。旨在满足客户侧多元的针对用户目录、组织架构、登录认证、安全管理等功能灵活性的配置需求，能够进一步以面向变化设计系统架构、敏捷迭代的原则，支撑客户纷繁复杂的身份和组织架构自动化管理需求。Authing 身份自动化平台可以帮助企业免除身份和账号管理过程中繁杂的定制化开发过程，基于下一代「低代码、无代码」的设计理念和可视化、拖拉拽的编排方式，快速构建和管理您的身份管理工作流程，大幅降低企业内部身份管理成本及身份安全风险。 Authing 提供国内首个持续自适应多因素认证产品 在《办法》中明确提出将数据安全风险纳入全面风险管理体系，并强化了数据安全风险的监测、评估、应急响应、报告及事件处置的管理流程，以有效防范和处置数据安全风险。随着金融行业对数据安全的要求不断提高，单一的传统认证方式已经难以满足现代企业在多样化威胁面前的安全需求。持续自适应多因素认证（ Continuous Adaptive Multi-Factor Authentication，简称 CAMFA ）作为一种全新的身份验证方法，成为企业应对安全挑战的有效手段。它在自适应多因素认证（基于上下文属性判断当前安全状况以增加因素认证）的基础上增加了实时风险评估技术对用户进行动态评估安全系数。在时间维度上，持续自适应多因素认证在用户整个使用旅程中持续不断的对其进行信任评估，以决定是否需要增加额外的认证流程。这样做的好处就是企业的安全得到实时监控，而用户只会在进行风险操作时被提示需要进行额外的认证。 超细粒度分级管控，确保职责分明不越界 随着金融行业对数据保护和隐私要求的不断提高，尤其是在《办法》中明确提出要加强个人信息保护，金融机构面临着更加严格的合规压力。单一、固定的用户旅程已无法满足业务的快速发展需求，权限管理必须具备动态调整的能力，突破对传统权限管理思维的突破，适应不断变化的业务场景和岗位职责。Authing 提供的「管理员权限」功能，以业务为导向，通过角色和权限的细粒度分配，使权限管理回归到对业务实际需求的精准支持。系统将各类权限聚合起来组成「角色」，给后台管理员（员工）赋予不同的角色，就可以控制其在系统中可接触的空间范围，确保他们「权责分明」、「不越界」。Authing 新版管理员不仅不局限于超级管理员的权限分配与管理，还支持协作管理员将自己拥有的权限继续授权，达到层层下放的授权效果，实现灵活又严谨的权限管理能力。从全局考虑数据资产，基于场景对业务流程不断进行切片细化，用数据优化、重构，推动整个商业模式，实现细粒度的权限管理，以用户为中心，实现全场景业务权限的集中化、可视化、个性化。

随着产品功能的持续拓展和用户需求的多样化，平台在不断优化其控制台界面和用户管理功能，提升操作效率并提高用户体验。尤其在企业级应用场景下，系统的操作流畅度和界面直观性对于用户的工作效率至关重要。本次菜单重构和用户管理优化的实施，着重提升用户使用便捷性，减少操作的繁琐性，帮助用户能够更高效地完成管理任务，提升日常操作的流畅度。一起看看新的功能和改进是否正好解决了您的痛点！ 01.控制台菜单目录优化 菜单结构的优化始终是提升用户体验的重要一环，尤其在复杂的后台管理系统中，合理的功能布局和清晰的菜单结构对于提高工作效率至关重要。Authing 本次优化的主要目标是让功能块更加合理的布局，用户可以更快地找到所需功能，降低操作复杂度。 【组织机构】二级菜单重命名：原【组织机构】中的二级菜单【组织机构】被更名为【组织与部门】，菜单结构变得清晰，以便用户理解和使用。 成员管理的顺序调整：为了优化工作流程，原【成员管理】被移动至【组织机构】下的第一个二级菜单位置，减少了菜单层级的嵌套，用户能更快速、直接地访问成员管理功能，优化了日常操作流程。 设备管理与会话管理迁移：为了进一步提升安全管理效率，【设备管理】和【会话管理】从【组织机构】菜单中移至【安全设置】下，安全管理和身份管理部门更加清晰。 新增【身份治理】菜单：针对企业在权限管理方面的需求，新增了一级菜单【身份治理】，将【权限审计】【职权分离】【审批中心】作为二级菜单移至其中，强化了身份和权限治理功能。 同步中心与公共账号的调整：【同步中心】被移至【自动化】下，简化了流程设置；【公共账号】则被移至【设置】下，用户能够更加高效地进行设置与管理。 02.用户详情页的优化 在产品使用过程中，用户信息管理是身份管理平台中不可忽视的核心功能之一。为了更好地服务用户、提升管理效率，对用户授权详情页面进行了深入优化，特别是在【用户信息】 Tab 顶部的呈现方式进行了大幅调整。通过对信息优先级的排序与展示，优化了页面布局，使得用户能够更便捷地查询和管理用户信息，提升了整体的操作体验。 高频查询字段优先展示用户在日常操作中，经常需要频繁查询和修改的信息，比如用户名、邮箱、手机号、部门、岗位等。为了让这些高频使用的字段更加突出，授权将其优先展示在用户详情页面通过这种方式，用户可以快速访问最常用的信息，无需再次寻找，极大提升了操作效率。随着企业用户需求的表单，信息表单中往往包含一些不常用或无效的字段，这些字段会导致页面的崩溃和信息过载。为了避免这种情况，认证对无用或无效的字段进行隐藏了处理，确保用户的注意力能够集中在关键信息上，减少了信息的视觉，并提高了用户对页面内容的关注度和操作便捷性。 支持即时修改标题名称在用户信息管理流程中，标题处显示的名称是关键字段，通常是用户的身份标识或在系统中展示的主要信息。为了提升用户的编辑体验，对【用户信息】页面进行身份验证的标题处进行了优化，允许用户直接修改标题显示的名称，并在失焦或按回车时即时保存，让用户能够更加快速、方便地进行名称修改，节省了操作时间。 重置密码按钮在授权用户详情页面的优化流程中，除了信息展示和编辑功能的改进，还特别关注了页面元素的简化和布局优化。重置密码按钮从页面显眼的位置移动到【更多】菜单中，是优化中的重要内容之一。在传统的界面设计中，许多不常用的功能按钮往往会引起严重眼部的位置，导致页面稀疏和杂乱。重置密码功能虽然是一个重要的操作，但对于大多数用户来说，日常使用频率并不是高。为了优化页面视觉体验，将【重置密码】按钮移至【更多】菜单中，避免了页面元素的过度强调，使页面更加简洁，用户能更集中注意核心操作项，减少了不必要的视觉干扰。 03.成员入职/创建成员的优化 为了更好地满足客户需求，提升成员管理的便捷性和一致性，Authing 对成员入职和创建成员的功能进行了全面优化。原先在【成员管理】页面的【创建成员】与【组织机构】页面的【成员入职】中，分别存在两个入口用于新增成员，Authing 对这两个入口进行了统一。现在，无论用户是在【成员管理】页面还是【组织机构】页面，都可以通过相同的配置项和逻辑进行新增成员的操作。用户可以确保在不同入口处获得一致的使用体验，减少了因配置差异而引发的困扰，提高了操作的连贯性和效率。整合配置项与交互用户在创建成员时，所需填写的内容优化并重新设计【创建成员】时可填写的内容：用户名、选择部门、邮箱、手机号、姓名、所属岗位、密码等新增成员时，必须填写的关键字段包括【用户名】、【选择部门】，其他字段如岗位、扩展字段等则可以根据需求选择填写。 部门选择交互优化以前用户在选择部门时可能面临较为繁琐的操作流程，需要逐层展开部门列表，进行多次点击和确认，才可以完成部门的选择。现在，用户只需点击【选择部门】后，弹出二级窗口，方便地选择具体的部门。用户选择完毕后，点击【确定】即可保存结果，使得部门选择过程更加简便直观。 首次登录信息配置在为成员设置首次登录信息时，Authing 重新设计了相关的交互方式。开启【发送首次登录地址】开关后，用户可以选择通过【邮箱】或【短信】发送登录链接。选择【邮箱】后，邮箱字段成为必填项；选择【短信】后，手机号字段成为必填项，满足了不同客户的需求，并确保了成员能够顺利收到登录信息。 扩展成员信息功能点击【 + 填写更多信息】后，用户可以进一步填写如昵称、身份证号、国家/省/市等额外的扩展字段。这些字段可以根据企业的不同需求进行自定义，灵活适应不同的管理场景。除了系统预设的字段，Authing 还支持用户自定义扩展字段，企业管理员可以根据不同的场景需求，更好地进行用户管理。 Authing 不仅让身份和权限管理变得更加简单、直观，也为企业带来了更高效的团队协作能力。在确保信息安全的基础上，企业能够更加灵活地进行身份治理、权限控制和员工管理，确保每一项操作都能高效且合规地完成。现在，您可以前往官网，立即注册并体验全新优化的功能界面，亲自感受这些改进如何帮助您提升日常工作效率，优化团队协作。无论是提升员工入职效率，还是增强权限管理的精确性，Authing 都能为您的企业提供完美的解决方案。注册账号，免费体验，开启更加高效的身份与权限管理之旅！

在数字化转型的浪潮中，身份不仅是技术生态中每个人与系统之间的关键纽带，它同时承担着所有人安全风险。据统计数据显示，超过 80% 的数据泄露事件涉及身份泄露，身份逐渐成为网络攻击的主要目标。身份认证不仅仅是一个简单的登录框，应该在每个环节提供多层次的防护，构建起多层次、全方位的身份安全防护体系。企业在强化身份安全的同时，必须认识到用户体验同样至关重要。在竞争激烈的市场环境中，用户体验成为品牌与用户对话的创意，只有将身份安全与用户体验的结合，才能确保企业在竞争中保持优势。 01.抛弃过时的身份认证 传统账密登录 传统的身份认证方法，如用户名和密码加上短信验证码，曾经被广泛应用。随着网络攻击手段的不断发展，传统方式已经变得越来越脆弱，难以有效应对现代复杂的安全威胁，反而可能为攻击者提供了突破口。社会工程攻击和 SIM 卡交换攻击已经能够轻易绕过这些传统认证方式。攻击者通过模拟合法用户的身份获取短信验证码入侵账户。企业若仍依赖于这些过时的身份认证方式，可能会暴露出更多的安全隐患，导致用户数据泄露或账户被盗用。 密码疲劳问题 为了保证身份安全，许多企业要求用户不断进行繁琐身份验证。虽然有效提高了安全性，但也让在用户每次都进行登录或进行敏感操作时，必须经历一系列冗长的身份验证步骤。过于繁琐的身份验证过程可能会让用户感到困扰，大多数用户往往倾向于使用简单或完全相同的账号口令，用于不同平台的系统登录，甚至为图便利，在不使用系统的时候也不退出系统。用户的个人身份信息分散在各个应用系统中，“密码疲劳”问题多发，核心资产数据直接暴露于黑客攻击之下。 过度身份认证 大部分企业通过增加身份认证方式来保障用户信息安全，但过度的身份验证步骤在无形中增强了用户的“难度”。当用户在使用产品或服务时需要经历繁琐的身份验证过程，如重新输入密码、验证码或完成多个步骤的多因素认证，会产生疲劳感和挫败感，甚至也可能让用户迅速放弃使用你的产品或服务。哪怕是最细枝末节的糟糕体验也会让用户很快放弃你的产品，但企业很难做到保证数据安全的同时为合法客户提供低摩擦的登录体验。 02.一切从 Authing 开始，保护用户登录旅程的每个阶段 登录前根据《 2024 人工智能安全报告》显示，2023 年基于 AI 的深度伪造欺诈增长了 3000% 。这些伪造不仅限于娱乐或恶搞，更频繁地被用于金融欺诈、网络攻击、身份盗用等恶意行为，使得企业和个人的安全防护面临前所未有的压力。深度伪造技术的泛滥，正在迅速改变数字空间的风险格局，任何人都有可能成为虚假信息的受害者，而识别真伪的难度正在不断加大，凸显了对 AI 安全和监管的迫切需求。预计 2023 年至 2030 年间，网络犯罪中人工智能的采用率将增长 37% 。Authing 通过强大的安全监控系统进行身份验证，基于持续自适应信任的技术模型，可以持续收集每个用户在登录之后的每一个资源访问的行为数据，持续计算分析用户当前的风险水平与可信评分，并且能够根据风险水平实现自适应的访问许可或者控制操作。系统会在用户尝试登录系统时，实时分析结果，动态评估风险并采取相应的验证措施，确保只有经过严格验证的用户才能访问数据，避免非法分子通过不法手段盗取账号。 登录时归根结底，推动业务发展的关键在于为客户提供简单、无缝的用户体验，同时不影响安全性。客户期望能够在任何时间、任何地点，轻松、快速地访问服务，同时也希望拥有灵活的登录选项，满足他们不断变化的需求。而 Authing 可通过灵活、安全的无密码登录选项提供完美平衡，允许用户快速安全地登录。它们还是一种防网络钓鱼的替代方案，可以替代不太用户友好的登录选项，例如常用的用户名和密码加 MFA 组合。持续自适应 MFA 还可以通过评估新设备、网络或位置和不受信任的 IP 等风险信号来减少 MFA 疲劳，只会在高风险身份验证尝试时触发第二次挑战。 单点登录 单点登录（SSO）是目前企业降本增效以及提升用户体验的主流选择方案。相关的安全性配置也非常重要，包括适当的会话管理、强制重新认证、定期会话失效等策略，以防止会话劫持和重放攻击。Authing 通过将多个应用集成至一个工作台，实现了单点登录的强大能力，而无需进行额外的开发工作。用户只需完成一次登录，即可安全高效地访问所有被授予权限的应用系统，这极大地简化了繁琐的登录流程，显著提升了业务操作的效率。 Passkey 无密码认证 Authing 作为国内领先的身份认证服务商，率先推出 Passkey 无密码认证服务，填补国内密码认证缺陷，降低数据泄漏风险。Passkey 无密码认证能够大幅提升用户体验，免去用户记录大量平台密码的困扰，且在需要频繁认证的业务场景下，避免频繁输入各类口令的麻烦。即使服务端发生账号泄漏事故，或因用户的安全意识不足，遭遇密码暴力破解、钓鱼攻击以及社会工程促使的主动泄漏等问题，攻击者也无法通过获取的密码用于登录用户账号，不会因用户账号凭证泄漏造成更大的危害。Passkey 实现的是在原本的「用户名-密码」安全体系外，寻找一种更为简单、直接，但同样具备安全性的用户身份验证方式。 持续自适应 MFA Authing 通过全方位扫描和分析用户身份和行为，采用无监督学习方式，深度学习用户的特定行为模式（例如登录时间、习惯、设备、生物特征等），以主动发现合法账号是否受到非法使用的威胁。并提供基于身份自动化编排引擎的「持续自适应多因素认证」对黑客源头进行精准打击，有效预防非法个体持有合法账号进行非法活动。自适应 MFA 认证策略底层基于 Authing UEBA（用户或实体行为分析技术），可以针对用户行为和用户画像进行深度梳理分析，从而自动选择与当前行为相匹配的 MFA 策略。在自适应 MFA 认证策略中，Authing UEBA 引擎会根据用户的行为和画像进行分析和判断，例如用户的登录历史、设备信息、IP 地址、地理位置、活动模式等等，从而确定当前用户的身份和风险级别，并选择与之相匹配的 MFA 策略。在时间维度上，持续自适应多因素认证在用户整个使用旅程中持续不断的对其进行信任评估，以决定是否需要增加额外的认证流程。这样做的好处就是企业的安全得到实时监控，而用户只会在进行风险操作时被提示需要进行额外的认证。 登录后许多企业认为，用户一旦登录完成，身份认证的任务就结束了。实际上，随着用户的涌入，缺乏统一的管理和控制会导致一系列潜在的风险和安全隐患。企业必须大量持续存在关注用户的行为和权限，确保登录后的每一个步骤都建立在安全监控之下。为了保证合规性和增强安全性，企业需要建立完善的审计日志系统，完善的审计日志是企业保障合规性的前提，通过可视化的行为数据快速获悉用户在平台中的行为日志，支持自定义监听用户事件，帮助管理员实时掌握访问报告、授权信息等。所有应用系统都具备一个统一的出入口，日志集中管理，以便 IT 人员排除问题，追溯问题的起因，让身份管理更加安全合规。通过集中管理安全审计日志，可以更好地监控系统的访问情况、行为轨迹和异常事件，及时发现并应对潜在的安全威胁。 轻松实现品牌化配置，提升用户感知许多开发者在最初设想时，认为开发一个登录认证模块只是简单的几个步骤：设置一个登录框，验证用户名和密码，然后允许用户访问系统。然而，实际的开发过程远比这复杂得多，涉及到大量的工作和细节处理。开发者不仅需要接入多种登录方式，还需配置复杂的认证流程，设计用户友好的前端样式，并确保系统在高并发情况下的稳定性和性能优化。如用户名和密码登录、社交媒体登录（如 Google 、Facebook 登录）、单点登录（ SSO ）等，每种方式都需要单独的集成和配置。并且用户体验至关重要，设计一个简洁、美观且用户友好的登录界面需要投入大量精力。响应式设计需要确保登录页面在各种设备和屏幕尺寸下都能良好显示。企业可以借助 Authing ，快速集成多种登录方式和安全认证机制，简化开发过程，提升系统的安全性和用户体验。并且 Authing 提供的 1000+ API 和丰富的文档支持，可以帮助开发者高效完成登录认证模块的开发和维护，确保系统的合规性和可靠性。同时，品牌化作为 Authing 最为注重的模块之一，给用户提供了非常强大的自定义功能。 在数字化转型飞速发展的时代，用户身份安全与体验的平衡已经成为企业成功的关键。企业应该认识到，身份认证不仅仅是一个安全问题，它还是提升用户体验、增加用户信任的重要阶段。企业应从传统认证方式的束缚中解脱出来，采用更智能的身份认证解决方案，打造一个既安全又便捷的数字化身份体验，为用户提供更高价值的服务。Authing 作为国内领先的身份认证服务平台，凭借领先的技术和解决方案，帮助企业在确保安全的基础上，提升用户体验，致力于为企业提供全方位的身份安全解决方案。

12 月 12 日，“ 2024 全球开放式创新论坛”在上海隆重开幕，以“跨界联创，新质跃迁”为主题，深入探讨新质生产力的发展实践。论坛期间，璞跃中国（Plug and Play China）与清华大学技术创新研究中心联合揭晓了第二届“全球开放式创新榜单”，旨在表彰全球开放式创新领域的杰出企业。Authing 凭借其在身份认证和访问管理领域的卓越创新，成功跻身“ POC50 最具概念验证能力创业公司 50 强”榜单，成为企业服务领域的佼佼者。 开放式创新百强榜单沿袭了首届评选的严谨标准，针对大企业，评审团队从创新参与度、创新成果性、创新持续性、创新差异性四大核心维度进行全面考量。而对于初创企业，榜单则依据创新性、成长性、持续性、差异性和国际化这五大关键指标进行综合评价。作为一家致力于推动开放式创新和数字化转型的公司，Authing 凭借持续创新和卓越的技术优势，不断提升产品功能和服务能力，助力更多企业在全球竞争中脱颖而出。此次入选标志 Authing 在身份认证领域取得了卓越的成就，也为其未来在全球市场的发展奠定了更加坚实的基础。

随着互联网、物联网和移动终端等技术的迅猛发展，登录认证面临着新的挑战和需求。虽然登录认证在信息系统中是传统且古老的组成部分，但未来的发展前景依然广阔。不论是用户登录、PC 端、移动端还是智能设备的访问，身份认证在保障业务操作安全、资金安全、系统间通信和与外部系统集成等多个方面起到至关重要的作用。随着认证方式的不断演进，从最初的 Cookie 和 Session ，发展到如今的多端登录、多因素认证以及 API 令牌等多种认证手段。同时，用户终端设备的不断升级也推动着认证方式和手段的不断创新。但对于开发者来说，构建一个安全、高效的登录认证系统往往面临安全性设计复杂、用户体验优化难度、开发时间等问题。从加密算法设计到多平台兼容，再到用户体验的优化，都需要投入大量的时间和资源。开发者需要在短时间内轻松构建稳定、安全的登录认证体系。 01.开发者接入系统遇到的问题 登录认证系统自研复杂 开发者需要构建一个能够有效防御多种网络安全威胁（如身份盗用、数据泄露、暴力攻击破解、中间人攻击等）的登录认证系统，同时还需要考虑针对敏感操作添加多因素认证。开发者需要设计出安全性高效的解决方案，这也是为什么许多团队更倾向于使用专业认证平台作为认证。并且由于登录认证系统需要考虑安全性、兼容性和用户体验，开发者往往需要投入大量的时间和资源来设计和实现。尤其是在项目周期紧张的情况下，如何在有限的情况下期间构建一个既安全又稳定的认证系统，是开发者的一大挑战。 用户体验优化难 在当今的数字化时代，用户体验已经成为应用成功的关键因素之一。用户不仅仅关注应用功能是否强大，更关注交互是否畅通、使用是否便捷。尤其是在多端场景下，开发者需要兼顾不同设备的配置与用户。随着无密码认证等新技术的出现不断改变着用户对身份验证的需求，用户对应用的登录体验也提出了更高的要求。开发者需要的不仅仅是技术能力，更需要从用户角度出发，深入了解用户需求，权衡其中利弊。无论是直接的登录流程、快速的身份验证，还是避免繁琐操作，用户体验优化往往是技术挑战和设计挑战并存的问题。 多平台兼容性 随着认证技术的不断演进，从传统的基于 Cookie 和会话的认证方式逐步发展到如今广泛应用的多因素认证和 API 等新型技术，开发者不仅需要兼容多个平台，还需要保证这些平台间的认证机制能够无缝集成。在多平台环境下，用户可能会在不同的设备间频繁切换，例如从 PC 登录切换到移动端继续操作。系统能够在不同平台间同步认证状态，避免用户在设备切换时需要高效重复登录。开发者需要保证每个平台的用户界面都能够应答认证状态与交互信息，系统能够在不同的操作系统、浏览器和设备上稳定运行。 02.Authing 助力开发者快速接入认证体系 当使用 Authing 进行用户认证时，你不需要自己实现用户管理逻辑，所有的相关操作（如创建删除用户、配置登录流程、重置密码等）都可以通过 Authing 控制台托管登录页、API & SDK 完成。用户资料将被安全地存储在 Authing 云上的数据库中，你不需要额外保存一份用户资料，而是直接使用 Authing 中存储的用户信息实现你的业务需求。为此，需要先将你的业务数据与 Authing 用户联表。 接入用户认证方式使用 Authing 接入用户认证流程，一共有以下几种方式： 使用 Authing 托管登录页 Authing 托管登录页是最简单、安全的集成方式。这是因为登录流程由 Authing 维护，并由 Authing 保证安全。对于应用集成，建议使用 Authing 托管的登录流程。你的业务系统将用户重定向到 Authing 登录页，在此用户进行身份验证，然后重定向回在控制台配置的应用登录回调 URL。此设计被认为是安全性最佳实践。在自定义配置方面，托管模式提供了登录注册表单自定义配置，可通过控制台配置和 CSS 进行界面自定义。 使用 Authing 提供的内嵌登录组件 内嵌登录组件（Guard）被认为是灵活性和集成之间的最佳平衡。如果集成需要更深入的自定义级别，或者在一些前后端分离的场景中无法使用托管模式，可以选择使用此模式。内嵌登录组件由 Authing 构建和更新，使用行业最佳实践安全性设计，仅需要几行 JavaScript 代码就可以集成到你开发的项目中。它可以直接从 CDN 或 NPM 加载，也可以从源代码构建。Authing 登录组件同时提供 Javascript 原生、React、Vue 和 Angular 的多种集成模式，在你的任何项目中都可以无缝集成并享有高度自定义灵活性。 使用 API & SDK Authing 提供 RESTFul 和 GraphQL 两种形式的 API ，你可以基于此自定义 UI 和认证流程。同时 Authing 支持了 Java、JavaScript/Node.js、Python、PHP、C#、Swift、Go、Ruby、微信小程序等多种语言的 SDK，你可以选择自己熟悉的 SDK。 在不同场景下的接入 AuthingAuthing 可以集成到标准 Web 应用、单页 Web 应用、客户端应用以及后端应用等各种场景中，你可以分别阅读不同场景的接入方式： 在标准 Web 应用中接入 Authing 本文以 Node.js Web 框架 Express 为例，介绍如何在传统的 Web 项目（如 Express MVC 、Django、PHP Laravel 等）中快速接入 Authing，实现登录、退出、获取用户信息等功能。这里一共牵涉到三方：终端用户浏览器、应用服务器、 Authing 服务器，完整流程如下：1、终端用户浏览器请求应用服务，发现用户未登录，跳转到 Authing 托管的登录页。2、用户在此登录页完成登录之后，终端用户浏览器会在请求参数中携带授权码 (Authorization Code) 等数据跳转到应用服务器预先配置好的回调链。3、应用服务器使用授权码 (Authorization Code) 向 Authing 服务器请求换取用户信息。4、应用服务器获取到用户信息之后，建立与终端用户的会话。5、终端用户得到登录成功提示，认证流程完成。流程图如下所示： 在 Authing 中进行配置在开始前，你需要在 Authing 中创建一个应用。你可以前往 Authing 控制台的应用列表页面创建应用。配置回调链接路径：应用->自建应用->应用详情页->应用配置->认证配置当用户在 Authing 登录成功之后，浏览器会跳转到你配置的回调链接（Callback URL）。此回调链接应该是你应用中的一个路由，你需要在此路由中完成换取用户信息等操作。你必须配置此回调链接，否则用户将无法登录，而会显示 invalid_redirect_uri 错误提示。此示例代码的回调链接为 https://console.authing.cn/console/get-started，将其复制到 登录回调 URL 配置项中，然后点击保存。 配置登出回调链接你需要配置退出登录之后的回调地址（Logout URLs）。用户在 Authing 托管登录页退出登录之后，返回该地址。你必须配置此回调链接，否则用户将无法退出，而会显示 misconfiguration 错误提示。此示例代码的回调链接为 http://localhost:3000，将其复制到 登出回调 URL 配置项中，然后点击保存。集成 Authing 到你的系统安装依赖此处是 node.js 示例，你需要安装支持标准 OIDC 协议的 openid-client 和 passportjs。 yarn add express express-session passport openid-client 初始化在项目的最开始我们需要初始化 openid-client 的 Issuer，初始化参数如下： client_id: OIDC Client ID，在 Authing 中即你的 应用 ID； client_secret: OIDC Client Secret，在 Authing 中即你 应用的密钥； issuer: OIDC Issuer，你可以在应用的端点信息中获取。获取方式如图所示，你需要保存好这些内容或记住获取方式，以后可能会频繁使用： 这里出于演示考虑，passport.serializeUser 中直接传 user 给回调函数 done，这会将用户信息存储在 req.session.passport.user 中，正式生产环境下不建议这么做，因为如果用户信息被修改而 session 没有更新，会造成数据不一致。passport.deserializeUser 传给回调函数 done 的第二个参数将会挂载到 req.user 上。 passport.serializeUser(function(user, done) { console.log("serializeUser", user);done(null, user.sub);}); passport.deserializeUser(function(userId, done) { console.log("deserializeUser", userId);done(null, userId);}); 详细示例代码如下： const express = require("express");const session = require("express-session");const passport = require("passport");const { Strategy, Issuer } = require("openid-client");const OIDC_CLIENT_ID = "YOUR_APPLICATION_ID";const OIDC_CLIENT_SECRET = "YOUR_APPLICATION_SECRET";const OIDC_ISSUER = "YOUR_OIDC_ISSUER";const REDIRECT_URI = "http://localhost:3000/auth/callback";(async () => {const issuer = await Issuer.discover(OIDC_ISSUER);const client = new issuer.Client({client_id: OIDC_CLIENT_ID,client_secret: OIDC_CLIENT_SECRET,id_token_signed_response_alg: "HS256",token_endpoint_auth_method: "client_secret_post",}); passport.use("oidc",new Strategy({ client,params: {redirect_uri: REDIRECT_URI,scope: "openid profile email phone",grant_type: "authorization_code",response_type: "code",},},(tokenset, userinfo, done) => {return done(null, userinfo);})); passport.serializeUser(function(user, done) {done(null, user);}); passport.deserializeUser(function(user, done) {done(null, user);});const app = express(); app.use(session({secret: "secret",resave: true,saveUninitialized: true,})); app.use(passport.initialize()); app.use(passport.session()); app.listen(3010, () => console.log(`Example app listening at http://localhost:3010 🚀`));})(); 完成登录逻辑首先我们初始化一个登录路由： app.get("/login", passport.authenticate("oidc"));app.get("/auth/callback", passport.authenticate("oidc", {successRedirect: "/user",failureRedirect: "/403",})); 使用其中任意一种登录方式登录之后，浏览器会跳转到 http://localhost:3000/auth/callback（这是我们第一步中在应用详情中配置的回调链接），在这里会向 Authing 服务器获取用户信息，获取用户信息成功之后再跳转到 /user 路由。完成展示用户信息逻辑接下来我们来实现 /user 路由的逻辑，前面介绍到用户登录成功之后用户信息会被挂载到 req.user 上，所以这里我们添加以下简单的逻辑： app.get("/user", (req, res) => { res.send(req.user);});app.get("/session", (req, res) => { res.send(req.session);}); 访问 /user 可以看到当前登录用户的用户信息： 访问 /session 可以看到当前登录用户的 session： 完成退出登录逻辑最后我们实现退出登录逻辑：1、首先通过 req.session.destroy() 清除当前应用的 session；2、跳转到 OIDC 应用的退出登录链接。 const OIDC_LOGOUT_URL = "{{YOUR_APP_DOMAIN}}/login/profile/logout";const LOGOUT_REDIRECT_URL = "http://localhost:3000"; app.get("/logout", (req, res) => { req.session.destroy();const logoutUrl = `${OIDC_LOGOUT_URL}?app_id=${OIDC_CLIENT_ID}&redirect_uri=${LOGOUT_REDIRECT_URL}`; res.redirect(logoutUrl);}); 在单页 Web 应用中接入 Authing单页 Web 应用（Single Page Application，简称 SPA）指的是一种 Web 应用或者网站的模型，它通过动态重写当前页面来与用户交互，而非传统的从服务器重新加载整个新页面。这种方法避免了页面之间切换打断用户体验，使应用程序更像一个桌面应用程序。在单页 Web 应用中，所有必要的代码（HTML、JavaScript 和 CSS）都通过单个页面的加载而检索，或者根据需要（通常是为响应用户操作）动态加载适当的资源并添加到页面。与单页 Web 应用的交互通常涉及到与后端服务器的动态通信。在 SPA 应用中接入 Authing 最简单的方式是使用 Authing 提供的内嵌登录组件和 Javascript SDK 来进行登录和认证。本文以 React 项目为例。获取应用 ID登录 Authing 后，Authing 会为你创建一个默认用户池和应用，你也可以自己创建应用，在应用详情中，可以获取应用 ID，点击复制按钮复制即可：安装 Authing 登录组件 yarn add @authing/react-ui-componentsORnpm i @authing/react-ui-components --save @authing/react-ui-components 中有 Authing 提供的一些 React 组件和获取 AuthenticationClient 的 API，其中就包括 AuthingGuard 登录组件。配置 AuthingGuard import React from 'react'import ReactDOM from 'react-dom'import { Guard } from '@authing/react-ui-components'// 引入 css 文件import '@authing/react-ui-components/lib/index.min.css'const App = () => {const appId = 'AUTHING_APP_ID'// 登录成功const onLogin = (userInfo) => { console.log(userInfo)// 这里可以重定向到其他页面了// ...}return <AuthingGuard appId={appId} onLogin={onLogin} />}ReactDOM.render(<App />, root) 通过传入 appId，AuthingGuard 就可以展示登录框进行登录了。退出登录现在你已经可以登录了，同时需要一个方法使用户登出，可以通过 AuthenticationClient 实现。 // src/index.js import { initAuthClient } from '@authing/react-ui-components'// 在项目入口文件中初始化 AuthenticationClientinitAuthClient({ appId: 'AUTHING_APP_ID',}) import React from 'react'import { getAuthClient } from '@authing/react-ui-components' const LogoutButton = () => { return <button onClick={() => getAuthClient().logout()}>退出</button>} export default LogoutButton 获取用户信息用户登录后，你可能还需要获取当前登录用户的用户信息。 // src/index.js import { initAuthClient } from '@authing/react-ui-components'// 在项目入口文件中初始化 AuthenticationClientinitAuthClient({ appId: 'AUTHING_APP_ID',}) import React, { useState, useEffect } from 'react'import { getAuthClient } from '@authing/react-ui-components' const UserInfo = () => { const [user, setUser] = useState() const [isAuthenticated, setIsAuthenticated] = useState(true) useEffect(() => { getAuthClient() .getCurrentUser() .then((userInfo) => { if (userInfo) { setUser(userInfo) } else { setIsAuthenticated(false) } }) }, []) return isAuthenticated ? ( user ? ( <div> <img src={user.photo} alt={user.username} /> <h2>{user.username}</h2> <p>{user.email}</p> </div> ) : ( <div>Loading...</div> ) ) : ( <h3>暂未登录</h3> )} export default UserInfo getCurrentUser 能获取当前登录用户的信息，若未登录会返回 null。 在客户端应用中接入 Authing Authing 提供 Android SDK 和 iOS SDK 帮助开发者在移动 APP 中快速集成 Authing。下面以 Android 应用的集成方式为例。安装下载 jar 包并将 jar 包导入 libJar 包下载地址：https://download.authing.cn/packages/jar/commons-codec-1.15-rep.jar(opens new window)https://download.authing.cn/packages/jar/core.jar(opens new window)将 Jar 包导入 lib，如下图所示： 配置 build.gradle implementation "com.google.code.gson:gson:2.8.6"implementation "com.squareup.okhttp3:okhttp:4.8.0"implementation files('libs/core.jar')implementation files('libs/commons-codec-1.15-rep.jar') 安装 Authing Java/Kotlin SDK。用户注册登录Authing Java SDK 支持手机号验证码、邮箱、用户名等多种注册登录方式，以手机号验证码登录为例：发送验证码 String phone = "phone number";authenticationClient.sendSmsCode(phone).execute(); 使用验证码登录 String phone = "phone number";String code = "1234";User user = authenticationClient.loginByPhoneCode(new LoginByPhoneCodeInput(phone, code)).execute(); 集成微信登录你可以使用 AuthenticationClient 的 loginByWechat 方法，所需四个参数均为微信返回的参数： val authenticationClient = AuthenticationClient("YOUR_USERPOOL_ID") val code = "#returned code from wechat#"; authenticationClient.loginByWechat(code).enqueue(object: cn.authing.core.http.Callback<User> { override fun onFailure(error: ErrorInfo?) { } override fun onSuccess(result: User) { val user = result }})

近日，由市青企协、青商会、夏商民兴超市、硕铭品牌咨询联合北京 Authing 身份云、亚马逊云科技共同举办的 Authing 全解决场景方案研讨会在厦门成功举办。此次活动汇聚了来自各行业的专家、企业代表及技术领袖，其中包括团市委青年发展部、厦门银祥集团有限公司、普华永道中天会计师事务所等 30 多个政府和企业代表出席此次会议，围绕数字和云技术的创新与实践展开研究探讨。 重量嘉宾致辞，共话数字化新未来活动开始，夏商集团运营部总经理、夏商民兴超市党支部书记、董事长、市青企协常务副会长潘虹女士为大会致辞。她在讲话中指出，当前数字化转型正向外部的和深度改变企业运营方式，而以 Authing 作为代表的身份服务厂商，为企业提供了高效、便捷的身份认证方案。潘女士表示，希望本次研讨会成为连接技术与应用的桥梁，为企业发展注入新动力。潘女士的致辞点燃了现场气氛，也为研讨会的主题分享拉开了序幕。 技术与实践碰撞，探索 Authing 身份云的无限可能Authing 技术负责人王辰凯率先带来了《 Authing 全场景身份云》主题分享，从战略布局到具体应用，全面演练了 Authing 身份云在数字身份管理领域的技术实力与洞察行业力。王辰凯首先分析了当前企业面临的身份管理挑战，包括传统认证系统的高复杂性、多系统数据孤岛、业务中的数据合规以及用户隐私保护需求。针对这些痛点，基于云原生架构，打造了高度灵活且可扩展的全身份云解决方案，能够覆盖从单点登录（SSO）、多身份认证（MFA）到零信任场景架构的多种身份认证场景。他特别提到，Authing 身份云平台通过 1000+ API/SDK ，不仅能够无缝集成企业现有 IT 系统，还支持快速对接 SaaS 应用和定制化业务场景，为企业提供了“一站式”的身份管理体验。 Authing 身份解决方案架构师梁天翼以《 C 端数字化体系最佳实践》为主题，分享了蒸汽云眼如何帮助企业提升客户体验与安全性。他围绕企业如何利用身份数字化技术优化客户体验、提升安全性展开，结合多个客户案例，深入剖析了蒸汽云眼在不同领域中的实际应用及其带来的显著效果。通过统一的身份管理和精细化的用户分层，能够帮助企业在全生命周期中为客户提供个性化服务。他指出，随着消费者对数字服务的要求迫切提高，企业在提供高效、服务的同时，必须注重客户体验的优化。Authing 身份云通过统一的身份管理和精细化的用户分层，能够帮助企业在全生命周期中为客户提供个性化服务。 聚焦云技术与安全，助力企业全球化发展随着全球经济数字化转型加速，企业国际化已成为重要的发展方向。然而，在进入全球市场时，企业往往会面临一系列复杂的技术难题。例如，不同区域的数据合规要求、边界网络延迟导致用户体验下降、全球 IT 基础设施的不一致性等。针对这些挑战，亚马逊云科技依托全球分布的基础设施和丰富的技术服务，为企业提供了高效、安全的解决方案。亚马逊云科技业务拓展经理曾毅带来了如何通过云计算技术助力企业出海的精彩演讲，真实案例展示了云科技在全球化业务中的重要作用。 随着数字化转型的加速，企业正在拥抱云计算、大数据、物联网等新技术。但传统的安全防护措施已经难以应对这些新兴威胁，企业迫切需要更加标准化、系统化的安全解决方案。华为坤灵产品业务总监郑恩荣带来了《华为坤灵安全产品介绍》。他从企业面临的安全挑战切入，全面解析了华为坤灵产品如何通过先进的安全策略、数据保护等相结合规工具，为企业数字化转型筑牢坚固防线。 本次 Authing 全场景解决方案研讨会的圆满落幕，展示了 Authing 身份云在助推企业数字化进程中的关键作用。Authing 作为国内身份云领域的领导者，将继续携手更多行业伙伴，共同探索技术创新与应用的无限可能。未来，Authing将以更开放的姿态、更先进的技术和更全面的服务，为企业创造更多价值，为行业发展注入新的活力。数字化时代，创新无止境。让我们期待 Authing 与行业伙伴携手，共同迈向数字身份的美好未来！

随着企业业务场景的迫切需求的复杂化，传统的用户管理方式已经难以满足跨系统、多平台的身份。无论是企业的内部运营，还是面向客户的服务体系，都离不开高效、可靠的用户管理。用户目录不仅是一个简单的用户信息存储工具，更是企业实现认证、权限管理和安全保障的身份重要支撑。企业用户目录需要具备强大的扩展性和架构动态性变化的业务场景，支持多种认证协议以实现系统间的无缝集成，同时在安全性和灵活性上高效满足企业的定制化需求。如何构建和管理用户目录，已经成为企业提升生产力、强化安全防护和优化用户体验的关键。 01.企业遇到的问题 用户数据孤岛化 随着企业的业务拓展和系统数量的不断增加，用户数据孤岛化现象日益严重。许多企业在不同的业务系统中采用独立的用户管理模块，但各个模块内数据互不相同，导致用户在不同系统中的信息可能会出现不一致的情况。并且每个系统都有自己的一套用户信息维护，缺乏统一的标准和接口，导致不同系统间的数据无法有效同步和共享。例如，员工在某个系统中更新了个人数据，但其他系统中的数据没有及时同步更新，造成了信息失真。 用户界面需求丰富 在各行各业的企业对用户信息的需求存在着显著的差异，不同行业、不同场景的用户字段的需求各不相同。例如，金融行业可能需要用户的信用评分、交易记录等特定字段。而在医疗行业，用户的健康档案、就诊记录和医药这些行业特定的字段。但传统用户目录的字段是固定的，难以根据实际业务需求进行扩展，导致企业在管理用户数据时需要借助额外的工具和方法。在高度个性化和差异化的市场环境下，企业往往需要利用丰富的用户数据来做出精准决策和个性化服务。 登录配置缺乏灵活性 在某些情况下，部分企业针对特定群体或业务场景限制用户注册或访问权限，可能需要根据不同的用户角色、地域、设备、访问环境等因素，实施细粒度的访问控制和注册管理。企业可能需要根据特定的业务场景安全需求，快速调整用户的访问权限或者设置注册的某些特定条件，比如限制某些用户只能通过某种特定的认证方式登录，或者通过设置时间窗口来限制用户的访问权限。传统用户目录往往无法根据这些复杂条件灵活配置，导致管理员需要依赖额外的工具或手动操作，增加了系统管理的复杂性和人力成本。 02.Authing 用户目录助力企业实现高效身份管理 你可以把 Authing 用户目录理解为存储了你所有用户资料的目录，可以在用户目录中搜索用户、查看用户资料；以及对用户目录配置进行管理，如禁止注册、配置白名单等；这个用户目录的 Schema 是可扩展的，可以添加自定义的用户字段；同时你可以以多种标准协议（如 SAML、LDAP、OIDC、OAuth2.0）作为身份提供商（Identity Provider）对外提供身份认证能力。用户目录配置项本文介绍用户目录相关的一些配置项，如禁止注册、频繁注册限制、登录失败次数限制、注册白名单等。 禁止注册 你可以在控制台的 安全设置->通用安全->注册安全 中开启 禁止注册 开关： 开启「禁止注册」之后，普通用户将无法通过登录表单或者 API 注册，只有管理员可以手动创建账号。 频繁注册限制 你可以在控制台的 安全设置->通用安全->注册安全 中开启 频繁注册限制 开关，限制在多少秒内不能超过多少次注册。 登录失败次数限制 你可以在控制台的 设置 - 安全信息 中开启 登录失败次数限制 开关，限制同一账号在多少秒内不能超过多少次失败登录。 若在规定时间内超过次数后，该用户再次登录需要输入图形验证码。 配置注册白名单 你可以在在控制台的 组织机构->注册白名单 中开启邮箱、手机号、用户名白名单，开启之后只有在白名单内的手机号、邮箱、用户名才能注册（管理员手动创建账号不受限制）。 禁止邮箱未验证的用户登录 默认情况下，未验证邮箱的账号可以进行登录，你也可以在 安全设置->通用安全->登陆安全 中修改此配置。 注册时发送欢迎邮件 关闭之后将不会发送欢迎邮件。你可以自定义欢迎邮件模版。 添加自定义用户字段用户自定义字段是除了基础用户字段之外，可以给用户对象添加的额外字段。开发者可以通过设置自定义字段，存储少量业务相关的数据。 配置自定义用户字段 可以定义以下几种类型的自定义字段：字符串、数值、日期、布尔值、枚举值。你可以在设置 - 字段管理 - 用户扩展字段 页面配置自定义用户字段。 在给新创建的自定义字段命名时，你可以编辑该字段在多种语言环境下的显示名称：1、直接在「显示名称」下的输入框中编辑，得到默认展示的字段名称2、勾选「中文」，并编辑中文环境下的字段显示名称3、勾选「English」，并编辑英文环境下的字段显示名称3、勾选「繁體」，并编辑繁体中文环境下的字段显示名称4、勾选「日本語」，并编辑日语环境下的字段显示名称特别的，如果该字段的显示环境未包含在上述四种语言环境的范围内，将会采用你配置的「默认展示的字段名称」进行显示。配置自定义字段之后，你可以开启应用的注册信息补全页面，让用户补全这些自定义字段的信息。在 应用详情 - 高级配置 页，开启 自定义本应用的登录框。 然后切换到 品牌化，勾上 开启注册信息补全 开关，然后选择刚刚添加的自定义字段。 数据类型 可以选择字符串、数字、布尔值、枚举值、日期，这会决定页面最终的展示样式。点击保存，之后访问应用的登录页面。用户点击注册之后将跳转到下面这个注册信息补全页面。用户成功注册之后，你可以在用户详情页面看到用户刚刚输入的自定义字段值。 使用 API & SDK 管理用户自定义数据Authing 同时支持了 Java、JavaScript/Node.js、Python、PHP、C#、Swift、Go、Ruby、微信小程序等多种语言的 SDK，你可以选择自己熟悉的 SDK。 使用应用 ID(AppID) ，应用密钥(App Secret)和应用 Host(App Host)初始化 Java SDK 的 AuthenticationClient。 import cn.authing.core.auth.AuthenticationClient;// 使用 AppId, App Secret 和 AppHost 进行初始化AuthenticationClientOptions options = new AuthenticationClientOptions(); 首先使用用户的 token 初始化 SDK。 authenticationClient.setAccessToken("ID_TOKEN"); 设置自定义字段。 List<UserDefinedData> list = authenticationClient.setUdv('school', '华中科技大学').execute(); 获取该用户最新的自定义数据。 List<UserDefinedData> list = authenticationClient.listUdv().execute(); 搜索用户Authing 支持通过邮箱、用户名、手机号、昵称等字段对用户进行模糊搜索，且同时支持控制台和 SDK 两种模式。 使用控制台搜索 你可以在 用户管理 - 用户列表 页面通过关键词搜索用户。 支持搜索的字段有邮箱、用户名、手机号、昵称等。 使用 SDK 搜索 Authing 同时支持了 Java、JavaScript/Node.js、Python、PHP、C#、Swift、Go、Ruby、微信小程序等多种语言的 SDK。 你可以使用各语言的用户管理模块（UsersManagementClient）的搜索用户方法。 使用 Authing 的 Cloud LDAP 用户目录 Authing 支持使用 LDAP 协议查看、修改、增加和删除用户信息。 版本说明基于 OpenLDAP 实现的 Authing LDAP 2.0 于 2023 年 4 月 12 日发布，推荐使用 Authing LDAP 2.0 版本；使用 LDAP 2.0，你需要先启用身份自动化；如果你还需要使用旧版 LDAP，仍可以参考 LDAP 1.0。要了解 LDAP 1.0 与 2.0 的区别，可以查看(LDAP 1.0 和 LDAP 2.0 的差异)。 迁移至 LDAP 2.0 LDAP 1.0 和 LDAP 2.0 的差异 DN 的区别：Authing LDAP 1.0 在目录结构上与 LDAP 2.0 存在一些差异，以下是 LDAP 1.0 的 DN 基本结构。 用户 DN uid=USER_ID,ou=DEPARTMENT_NAME,o=ORG_NAME,ou=users,o=USER_POOL_ID,dc=authing,dc=cn 部门 DN ou=DEPARTMENT_NAME,o=ORG_NAME,ou=users,o=USER_POOL_ID,dc=authing,dc=cn 用户 DNLDAP 2.0 的 DN 基本结构如下： 用户 DN cn=xxx,ou=DEPARTMENT_NAME,ou=DEPARTMENT_NAME,dc=DOMAIN1,dc=DOMAIN2,o=authing 部门 DN ou=DEPARTMENT_NAME,ou=DEPARTMENT_NAME,dc=DOMAIN1,dc=DOMAIN2,o=authing 用户 DN从上述两种 DN 可以看到以下区别： Base DN 会有所区别，LDAP 1.0 的 Base DN由 ou=users,o=USER_POOL_ID,dc=authing,dc=cn 组成，LDAP 2.0 的 Base DN 由 dc=DOMAIN1,dc=DOMAIN2,o=authing 组成，DOMAIN1 和 DOMAIN2 是由你初始化 LDAP 时输入的域名拆分得来的。 LDAP 1.0 的用户 DN 的 RDN 是 uid=USER_ID，LDAP 2.0 的用户 DN 的 RDN 是 cn=xxx，xxx 的值由你在身份自动化的字段映射决定。 用户属性的区别：在 LDAP 1.0 中搜索用户会返回 Authing 用户的所有基础属性和拓展字段，而 LDAP 2.0 中返回的用户属性完全由你在身份自动化的数据转换节点配置决定。配置 LDAP进入 组织机构 -> LDAP 菜单，点击「初始化 LDAP」。 在弹窗中输入你想设置的 LDAP 域名，并点击「初始化」，此域名最终会被用于生成你的 LDAP Base DN ，如输入的是 http://example.com，则最终生成的是 dc=example,dc=com,o=authing。 初始化完成后，LDAP 服务中还没有用户数据，Authing 会自动为你的 LDAP 服务创建工作流，用于将 Authing 的用户数据同步至 LDAP 服务中，你需要点击右上角的「自动化」按钮进入身份自动化界面进行配置。目前 Authing 为你自动创建的工作流有三个： LDAP 上游全量同步：用于将 LDAP 服务中的数据全量同步回 Authing 组织架构，若你不需要通过 LDAP 协议修改用户数据，建议关闭。 LDAP 下游全量同步：用于将 Authing 组织架构数据全量同步至 LDAP 服务，建议将其触发器设置为定时任务，首次初始化 LDAP 后，可以手动执行一次此工作流，以便将用户同步至 LDAP 服务。 LDAP 下游增量同步：用于将 Authing 组织架构数据增量同步至 LDAP 服务。 假如你想使用第三方的 LDAP 服务，可以修改 LDAP 配置节点中的账号连接。 使用 LDAP以下会介绍 LDAP 的简单使用，所有涉及到 LDAP 搜索相关命令都使用 ldapsearch 工具进行演示。连接信息Authing LDAP 的基本连接信息可以在 LDAP 的目录配置界面获取，配置信息如下： 域名：即你输入的 LDAP 域名。 LDAP 链接：LDAP 服务的域名、端口等信息。 LDAPS 链接：使用 LDAPS 连接服务的域名、端口等信息。 Bind DN：用于连接至 LDAP 服务的账号。 Bind DN 密码：用于连接至 LDAP 服务的密码，无法手动修改，若需要修改，可点击「自动生成密码」，并保存。 Base DN：搜索 LDAP 的基本 DN。 Search基于 Base DN 进行查找，返回结果包含用户数据，以及组织机构数据。-LLL 表示禁止输出与过滤条件不匹配的信息，如果不带此项，你将得到获取结果的条目数以及请求部分信息。 $ ldapsearch -H LDAP_SERVER_URL -x -D "LDAP_BASE_DN" -w "LDAP_BIND_DN_PASSWORD" -LLL -b "LDAP_BIND_DN" 查询过滤(Search Filter) 基于 Base DN 进行查找并过滤，返回结果包含用户数据，以及组织机构数据。有关过滤的所有功能，可以参考 RFC-2254。相等此项查找根据 cn 进行查找，因为组织机构不具有该属性，只有用户具有该属性，结果将会返回用户 cn 为 小白 的用户信息。 $ ldapsearch -H LDAP_SERVER_URL -x -D "LDAP_BASE_DN" -w "LDAP_BIND_DN_PASSWORD" -LLL -b "LDAP_BIND_DN" -s sub '(cn=小白)' 不等与不等类似，此项查找 LDAP 中具有 cn (用户名)属性，且属性值不为 U 的所有信息，因为组织机构不具有该属性，只有用户具有该属性，结果将会返回用户姓名不为 hahhaha 的条目信息（其实只有用户具有 cn 属性，所以结果全是用户信息）。 $ ldapsearch -H LDAP_SERVER_URL -x -D "LDAP_BASE_DN" -w "BIND_DN_PASSWORD" -LLL -b "$LDAP_BIND_DN" -s sub '(!(cn=hahhaha))' 查找模式base 模式(只查找 baseDN 信息) dn: LDAP_BASE_DN $ ldapsearch -H LDAP_SERVER_URL -x -D "LDAP_BASE_DN" -w "LDAP_BIND_DN_PASSWORD" -b "LDAP_BIND_DN" -s base one 模式(只查找 baseDN 信息下的子节点)以上图为例，one 模式会查找BaseDN 及 BaseDN 子节点 并返回相关信息。 dn: LDAP_BASE_DN...属性相关信息...dn: cn=xxx,LDAP_BASE_DN...属性相关信息...dn: ou=xxx,LDAP_BASE_DN...属性相关信息...$ ldapsearch -H LDAP_SERVER_URL -x -D "LDAP_BASE_DN" -w "LDAP_BIND_DN_PASSWORD" -b "LDAP_BIND_DN" -s one sub 模式(查找 baseDN 信息下的所有节点)以上图为例，sub 模式会查找BaseDN 和 BaseDN 下的所有节点 并返回相关信息。 dn: LDAP_BASE_DN...属性相关信息...dn: cn=xxx1,LDAP_BASE_DN...属性相关信息...dn: ou=xxx,LDAP_BASE_DN...属性相关信息...dn: cn=xxx2,o=develop,LDAP_BASE_DN...属性相关信息...$ ldapsearch -H LDAP_SERVER_URL -x -D "LDAP_BASE_DN" -w "LDAP_BIND_DN_PASSWORD" -b "LDAP_BIND_DN" -s sub 返回结果过滤(只返回指定属性)如果你使用过 SQL，此功能与 select 类似。不增加过滤结果可能是这样的： dn: LDAP_BASE_DN;cn: testcn; 增加相关过滤条件，则结果是这样的 $ ldapsearch -H LDAP_SERVER_URL -x -D "LDAP_BASE_DN" -w "BIND_DN_PASSWORD" -b "$LDAP_BIND_DN" -s sub dn cn Add 创建一个名为 user.ldif 的文件然后复制以下内容进去。 dn: (cn = username), LDAP_BASE_DN;objectClass: authingUser;cn: username; 然后执行以下命令：该操作会在 LDAP 服务 中新增一个 用户 $ ldapadd -H LDAP_SERVER_URL -x -D "LDAP_BASE_DN" -w "BIND_DN_PASSWORD" -f ./user.ldif 若你在工作流中开启了 LDAP 上游同步，则会将此数据同步回 Authing 用户池。 Modify创建一个名为 modify.ldif 的文件然后复制以下内容进去： dn: cn=username, ou=xxx, LDAP_BASE_DNchangetype: modify 然后执行以下命令：该操作会在 LDAP 服务 中根据 modify 中的 DN 查找相关用户信息，查找成功，则根据 changetype 选择操作 用户信息 ，信息 来自于 changetype 下面的信息。 $ ldapmodify -H LDAP_SERVER_URL -x -D "LDAP_BASE_DN" -w "BIND_DN_PASSWORD" -f ./modify.ldif 若你在工作流中开启了 LDAP 上游同步，则会将此数据同步回 Authing 用户池。 Delete 该操作会在 LDAP 服务 中根据 DN 查找相关用户信息，查找成功，则进行删除，这是一个敏感操作。 $ ldapdelete -H LDAP_SERVER_URL -x -D "LDAP_BASE_DN" -w "BIND_DN_PASSWORD" "cn=username, ou=xxx, LDAP_BASE_DN" 若你在工作流中开启了 LDAP 上游同步，则也会在 Authing 用户池中将此数据删除。 Othercompare该操作用于判断 LDAP Server 目录树中 DN 值和 指定条目值 是否属于同一个条目，是则返回 true，否则返回 false 。 $ ldapcompare -H LDAP_SERVER_URL -x -D "LDAP_BASE_DN" -w "BIND_DN_PASSWORD" "uid=uid,o=oid,LDAP_BASE_DN" "cn:xxx" modifyDN用于对 LDAP Server 中的 RDN 条目的修改， 可以从标准的条目信息输入， RDN 指 DN 的首项， 例如 "cn=oldUserName, o=Org_ID, LDAP_BASE_DN" "cn=newUserName" 中的 cn=oldUserName， 由于不管是 用户的 DN 还是 组织结构的 DN 相关信息多数都是 id 相关的值， 所以当你修改 cn=oldUserName 其实等同于修改用户名。 $ ldapmodrdn -H LDAP_SERVER_URL -x -D "LDAP_BASE_DN" -w "BIND_DN_PASSWORD" "cn=oldUserName,o=Org_ID,LDAP_BASE_DN" "cn=newUserName" whoami用于验证 LDAP 服务器 的身份，输入正确绑定 DN 以及密码，会返回指定的信息，否则会提示 ldap_bind: invalid credentials(49) 错误，这一般由于 密码错误 造成的，请检查 对应的密码 及 绑定 DN 信息 即可。 返回信息 test@example.com。 $ ldapwhoami -H LDAP_SERVER_URL -x -D "LDAP_BASE_DN" -w "BIND_DN_PASSWORD" LDAP 事件 如果你想在身份自动化中使用 LDAP 相关事件，可以在触发器中选择 LDAP 应用，之后即可选择事件。  

在日常工作和生活中，电子邮箱已经成为我们不可或缺的沟通工具，无论是使用常见的公共邮箱服务如 http://qq.com、http://163.com，还是公司专属的企业邮箱，都是一种快捷、高效的通讯方式。但对于现代企业来说，电子邮箱的作用远不止于此，它更是身份认证的一部分。当用户需要频繁登录多个系统或应用时，传统的身份验证方式可能显得繁琐，甚至会因复杂的操作流程影响用户体验。为了解决这个问题，Authing 全局登录框引入了全新的 IdP（身份提供商）邮箱域名匹配登录模式，并已全面兼容 SAML 和 OIDC 身份源，同时支持租户场景使用，帮助企业实现更加简洁高效且隐私保护的登录方式，优化用户体验的同时满足业务多样化的身份验证需求。 01.功能亮点 支持 SAML 和 OIDC 身份源连接的 IdP 邮箱域名配置 企业管理员可自行设置多个身份源连接的邮箱域名匹配规则，无需直接在登录框中向用户展示身份源列表。当用户在登录框输入邮箱地址时，系统将根据配置的邮箱域名规则，自动匹配到相应的身份源进行验证。例如，企业可将“@example.com”域名与 Azure AD 身份源绑定，同时将“@partner.com”域名与 Okta 身份源绑定。当用户在登录框中输入邮箱地址时，系统会根据邮箱域名规则，自动匹配到对应的身份源并完成验证，完全无需用户干预。 隐藏身份源列表，保护用户隐私 用户登录时无需面对复杂的身份源列表，而是通过邮箱域名或其他隐性规则直接匹配身份源。隐藏身份源列表后，用户登录过程中不会暴露可用的身份源信息，从根源上减少敏感信息泄露的风险，简化了登录流程，避免了多身份源情况下的操作繁琐，同时通过将身份源信息隐藏在后台，有效减少了敏感信息泄露的风险。尤其是在涉及敏感业务的行业或对隐私保护要求较高的场景中（如金融、医疗等），为企业提供了一个既安全又高效的登录解决方案，满足了隐私保护与安全合规的双重需求。 支持多租户场景，满足复杂业务需求 在多租户模式下，不同租户可能拥有各自独特的业务场景和身份认证需求。为满足这种复杂环境中的多样化需求，IdP 邮箱域名匹配登录模式为多租户企业提供了灵活的配置选项。租户管理员可以自行为租户创建身份源、绑定 IdP 域名列表使用，登录流程更加精准高效。无论是按业务部门划分的内部租户，还是跨地域运营的全球分支机构，企业都能轻松通过该功能实现差异化管理。例如，不同租户的用户可以通过输入其企业邮箱地址，系统自动匹配到对应的身份源进行验证，无需额外操作。 02.覆盖三大场景，打造丝滑的用户体验 提升用户登录体验 在数字化体验至关重要的时代，用户登录流程的便捷性直接影响整体使用感受。通过邮箱地址自动匹配身份源的功能，用户在登录时无需面对复杂的身份源选择界面，仅需输入邮箱地址，系统即可根据邮箱域名匹配规则，智能完成身份源的自动选择。当用户输入邮箱后，用户只需要点击一次“登录”，系统后台就会实时解析邮箱域名，并与预设的匹配规则进行校验，快速识别对应的身份源。整个过程对用户而言是完全无感知的，省略了传统登录方式中选择身份源的步骤。对于需要接入多个身份源的企业或组织，显著减少了因身份源列表过多可能引发的选择错误或登录失败的问题。 多身份源连接场景 在现代企业的数字化环境中，接入多个身份提供商（如 Azure AD、Okta、Ping Identity 等）已成为常态，以满足不同业务系统的多样化需求。但对于最终用户而言，频繁面对多个身份源的选择可能会增加理解负担，降低登录体验的流畅性。用户只需在登录框输入其邮箱地址，系统便可根据预设的匹配规则，自动定位到与邮箱域名关联的身份提供商进行认证，无需用户手动选择具体的身份源。 企业隐私信息保护需求 在当前的数字化环境中，企业和组织对数据隐私与安全的要求日益严格，尤其是涉及身份源敏感信息的场景。某些企业或组织需要特别关注身份源信息的保护，避免身份源列表在用户登录时的暴露，降低潜在的安全风险。通过邮箱域名匹配功能，用户登录时无需直接看到身份源列表。企业不仅能够为用户提供更加便捷且直观的登录体验，还在系统层面强化了隐私保护与安全性。 03.功能描述 配置登录模式在 品牌化 -> 全局登录框 菜单中，新增了对于登录模式的全局配置：「登录模式」。1、常规登录：默认选项，将常规登录方式与身份源登录方式分离，所有身份源需要用户在「其他登录方式」列表主动访问才可使用。 2、邮箱域名匹配登录模式：选择此模式后，可以根据为部分身份源连接开启「IdP 邮箱域名匹配登录」，开启后支持自主隐藏需要脱敏的身份源；为身份源设置域名后，用户输入邮箱格式账号时登录框将根据域名匹配相应的其他登录方式 / 常规登录方式。 点击「保存」按钮后，配置将立即对所有应用登录框及单点登录 SSO 生效。暂不支持应用独立配置。 配置身份源 IdP 邮箱域名 要使用 IdP 邮箱域名匹配身份源登录，需要先在身份源详情页为身份源连接配置 IdP 邮箱域名。每个身份源连接的 IdP 邮箱域名列表互相独立、不可重复。 启用身份源 IdP 邮箱匹配登录 为身份源连接配置 IdP 邮箱域名后，开启「根据邮箱域名匹配」开关，点击详情页「保存」按钮。保存成功后，如果用户在登录框输入的邮箱后缀与该身份源连接的 IdP 邮箱域名列表相符，就可以通过邮箱账号的域名匹配登录该身份源连接，不需要另行选择其他登录方式。   如果用户在登录框输入的邮箱后缀与所有启用「IdP 邮箱域名登录」的身份源连接 IdP 邮箱域名列表都不相符，则将继续账号密码登录流程。   在登录框隐藏启用 IdP 邮箱匹配登录的身份源 为身份源连接开启「根据邮箱域名匹配」开关后，默认在登录框隐藏该身份源连接。你仍然可以开启 作为「其他登录方式」展示 开关，对用户展示这个身份源连接。

在现代企业数字化进程中，IGA（身份治理与管理）产品将能够覆盖从用户帐号创建到终止的整个生命周期管理，包括管理员对用户的授权管理、用户自助服务与审批管理、用户与用户之间的权限流转管理。企业仅仅依靠基础功能，难以应对复杂业务环境中日益严苛的安全与合规需求。在权限流转的过程中，由于角色分配权限的多样性和业务场景的复杂性，可能会出现权限权限、冲突等安全隐患，引发合规性风险，企业需要通过事前探知的策略与事后审计活动进行维护。在此背景下，SoD（职权分离）与权限审计将组成预防授权违规和维护系统安全的重要能力。 01.什么是职权分离与权限审计？ 职权分离：事前预防违规授权 职权分离支持组织将内部的合规制度添加至系统中的授权行为之前，预防违规的授权、进而预防风险。通过阻止潜在的冲突权限组合，将企业内部的合规制度融入授权管理流程中，构建了事前预防机制。管理员可以配置职权分离策略，将可能导致合规风险的权限角色分配至冲突权限组中。例如，将“出纳权限”和“会计权限”分别设定为冲突组，确保同一用户无法同时拥有两种权限，预防财务违规行为的发生。当用户或用户池主体试图获取两个冲突组中的权限时，系统会实时触发策略运行日志，记录潜在的违规行为并发出警告，将违规风险控制在萌芽阶段，为企业内部控制提供了强有力的技术支撑。 权限审计：事后维护授权安全 权限审计功能支持组织对部分用户主体或权限实体进行授权的审计，在授权行为完成后进行定期维护。通过权限审计功能，支持企业对授权行为进行事后检查和维护。企业可以设定审计周期，例如按照部门或岗位，对用户权限进行季度审计，及时发现并撤销已停用或高风险的权限分配。权限审计生成的详细报告，可以帮助管理者全面了解授权现状，确保权限管理始终符合安全和合规要求。例如，一家企业在权限审计中发现某员工因岗位调整导致权限冗余，通过及时清理降低了潜在风险，同时优化了系统权限配置。 02.Authing 新增配置职权分离策略 Authing 支持管理员通过配置职权分离策略，将企业合规制度加入到授权行为监管中。作为用户池管理员，可以通过将可能引发合规风险的权限角色分别加入同一条职权分离策略中的两个冲突权限组，从而实现精准的权限隔离。例如，在一个权限敏感的业务环境中，“财务审批”权限与“资金支付”权限可能因角色交叉而带来高风险。管理员可将这两类权限分配到冲突权限组中，当用户试图同时获取两个组的权限时，系统会自动触发策略运行日志。不仅实时记录潜在违规行为，还能发出预警，为管理员提供及时干预的依据，确保权限管理的合规性和透明性。通过职权分离策略的实施，企业能够在授权行为中构建更加细致且符合安全要求的管控体系。管理员不再需要依赖人工检查，而是通过自动化工具高效管理复杂的权限组合情况，为企业的安全合规运营奠定技术基础。未来，随着数字化管理的深化，这种策略将进一步发挥作用，帮助企业在快速变化的业务环境中保持系统稳定与合规。 03.详细功能描述 创建职权分离策略 在授权中，职权分离策略是帮助企业构建合规权限管理体系的重要功能。Authing 已在「权限管理」模块中新增了「职权分离」Tab 页，为管理员提供更高效的权限配置和策略管理体验。需要注意的是，「职权分离」功能目前以灰度模式上线，为保证功能的稳定性和适用性，用户需提前申请开通白名单权限第三方可使用。在功能开通后，管理员即可进入职权分离菜单，通过系统化的步骤轻松创建和管理冲突权限组，有效预防潜在的权限冲突风险，助力企业在复杂业务环境中更从容地应对安全。 功能使用指南 1、在开始使用「职权分离」管理授权行为之前，你需要先在「角色管理」中创建不可同时授权给同一个主体的 2 组角色；2、完成「1.」并开通职权分离菜单后，你可以开始在 职权分离 -> 职权分离策略 创建职权分离策略，如下图所示： 3、创建职权分离策略的步骤 1 中，你需要选择一种冲突权限组的类型。当前仅支持角色权限，其他类型将在后续版本迭代。 4、点击「下一步」按钮，在步骤 2 中，你可以将「1.」中创建的角色分别加入两个冲突权限组中，下图示例为将角色「示例角色 A」加入「示例权限组 A」，将「示例角色 B」加入「示例权限组 B」： 5、如需修改某个权限组中的角色，可以点击双箭头图标按钮下拉冲突权限组，移除组中角色。 6、将角色分别加入 2 个冲突权限组后，点击「下一步」按钮，设置策略的名称、描述等基本信息，这将用于快速区分策略所包含的合规制度信息。完成后，点击「下一步」按钮： 7、在步骤 4 中你可以再次检查策略的名称、描述、冲突权限组及其所包含角色的信息。准确无误的情况下，请点击「创建策略」按钮，你将完成一条职权分离策略的创建。策略创建后将开始运行，如果需要停用，可以在「策略运行状态」列关闭开关。 编辑职权分离策略当创建完成职权分离策略后，管理员仍然可以对已创建的策略进行灵活编辑，企业在不同阶段的业务需求或响应环境变化快速。管理员可以调整策略的冲突权限组配置、更改名称策略与描述，甚至添加或删除特定角色。通过这些操作，企业能够及时对授权规则进行优化，确保权限管理始终满足业务需求和合规标准。 策略运行日志策略创建后将自动开始运行，在运行期间，管理员对用户授权的行为、用户通过自助申请获得的授权都将受到职权分离策略的监测。如果新的授权行为触发了策略中设置的冲突权限组规则，策略运行日志将记录授权主体相关的信息，用于判断授权行为是否有风险。 在每条职权分离策略详情中可分别查看触发过该策略的日志： 导出策略运行日志职权分离策略的运行日志是记录授权行为监测与冲突权限触发情况的重要数据来源。为了帮助管理员更实地分析和评估授权行为的高效合规性，Authing 支持将导出选定的时间范围 / 触发策略来源范围内的日志。通过导出日志，管理员可以从多维度对权限管理流程中的潜在风险和问题进行深入分析，进一步优化企业的合规策略。