在数字化转型的浪潮中，身份不仅是技术生态中每个人与系统之间的关键纽带，它同时承担着所有人安全风险。据统计数据显示，超过 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 支持将导出选定的时间范围 / 触发策略来源范围内的日志。通过导出日志，管理员可以从多维度对权限管理流程中的潜在风险和问题进行深入分析，进一步优化企业的合规策略。  

在构建 AI 应用时，身份认证（Authentication）和授权（Authorization）是两个核心的安全概念。身份认证是确定用户是谁的过程，而授权是确定用户是否有权限执行特定操作的过程。简而言之，身份认证回答“你是谁”，并授权回答“你能做什么”。这两个概念看似简单，但在 Next.js 环境中实施远要复杂得多。Next.js 作为一款高性能、轻量化的服务端框架，为开发者提供了丰富的开发工具和灵活的架构，但并未内置身份认证和授权原语（auth-primitives），开发人员不得不自己想办法构建身份验证解决方案。如何选择合适的身份认证方案，成为开发者面临的一大难题。 01.什么是 Next.js ？ Next.js 是一个基于 React 功能丰富且优化良好的框架，用于构建高性能的 AI 应用。它为开发者提供了一些开箱即用的功能和工具，使得开发过程更加高效，尤其是在服务端渲染（SSR）、静态生成（SSG）和客户端渲染（CSR）之间的无缝切换方面。Next.js 具备以下优势： 高性能 Next.js 支持 SSR 和 SSG，大幅提升页面加载速度和 SEO 表现。通过 SSR，页面在服务器端渲染，用户可即时获取完整的 HTML 内容，减少浏览器端渲染负担。SSG 则在构建时预生成静态页面，降低服务器实时处理压力。对于需要处理大量数据或实时更新的 AI 应用，Next.js 的高性能渲染能够确保模型预测结果和数据分析实时呈现，提升用户体验。 灵活性 Next.js 的渲染模式（SSR、SSG、CSR）能够很好地适配不同的身份验证场景。每种渲染模式都可以根据业务需求和应用的特性选择，提升安全性、性能和用户体验。通过服务端渲染（SSR），可以在服务器端处理身份验证，确保每个请求都经过安全检查，有效降低未授权访问的风险；静态生成（SSG）则适用于内容较为固定的应用，通过预生成静态页面提升加载速度，并通过 API 路由处理身份验证；而客户端渲染（CSR）在高交互性的应用中，通过前端存储和 API 路由提供快速响应的用户体验。不同渲染模式使得 Next.js 能够在多种身份验证场景下提供合适的解决方案，确保系统既高效又安全。 开发效率高 Next.js 提供了一系列高效的开发特性，如自动代码拆分、文件系统路由、热重载、零配置的服务器端渲染（SSR）、API 路由以及 TypeScript 支持，能够将应用拆分成多个独立的模块，按需加载，减少了初始页面加载的资源量，避免了开发者手动拆分代码的复杂性。通过简化配置、提供高效的开发工具和优化的性能，Next.js 使开发者能够专注于业务逻辑的实现，减少了项目构建中的繁琐工作，高效、快速地构建出高性能、可靠的 AI 应用。 全栈开发 Next.js 提供内置的 API ，开发者可以在项目中实现身份验证和授权功能。对于需要支持社交登录、单点登录（SSO）、多因素认证（MFA）等高级功能的应用场景，开发者可以直接在 API 中编写逻辑，将前后端高效结合在一起，减少并发处理带来的开发负担。开发者能够更加灵活地设计应用的身份验证和授权逻辑，在满足高安全性需求的同时，也能够保证应用的高性能和良好的用户体验。 02.开发者为什么选择 Authing ？ 随着登录方式的多样化，无密码登录、邮件验证和多因素身份验证（MFA）已成为现代应用程序中的常见功能。虽然现有的一些身份验证库也能支持这些功能，但它们往往需要开发者在原本就复杂的设置基础上进行额外的配置和集成。随着应用的不断迭代和功能扩展，开发者不得不投入大量的时间和精力在身份维护和更新，无法将精力集中在核心功能的开发和业务创新上。许多开发者会选择身份服务供应商来解决这些问题，例如 Clerk 。但 Clerk 的数据存储和服务基础设施主要位于海外，对于那些需要低延迟、高实时性，以及严格合规的应用场景来说，可能不是最佳选择。相比之下，Authing 提供了一套本地化身份解决方案，专为中国开发者量身定制，能够高效助力 AI 应用快速构建完善的身份体系。通过 Authing，开发者无需面对复杂的配置流程，也无需担忧跨境数据传输可能引发的延迟、网络波动或合规性问题。Authing 提供从用户注册、无密码登录、MFA 到权限管理的一站式服务，简化了开发流程，大幅降低了开发人员在身份管理上的投入成本，让开发者能够将更多的时间和精力投入到 AI 模型的开发、算法优化以及核心功能的打磨上。 一站式聚合身份体系 Authing 是一个全场景身份云产品，它旨在为开发者和企业提供一套完善、安全的用户认证和访问管理服务。Authing 的主要功能包括单点登录（SSO）、身份自动化、用户分析、多因素认证、行为审计、风险控制、跨平台设备管理、IoT 身份认证等。并且 Authing 支持多种国际身份认证协议，如 OAuth2.0、OIDC、SAML、AD/LDAP、WS-Fed、CAS 等。无论是快速集成用户认证系统，还是实现复杂的身份管理策略，Authing 都能为开发者和企业提供灵活、安全且高效的解决方案。 开箱即用，快速集成 Authing 提供了 2000+ API 和 SDK 支持多种编程语言，包括 JavaScript、Python、Java 等，能够自由地集成和扩展身份认证功能，一站式聚合全场景身份体系。对于 AI 开发者而言，Authing 的开箱即用特性能够快速集成用户认证和权限管理，无需花费大量时间在身份验证的细节上，专注于 AI 模型的开发和优化。同时，Authing 支持云交付和私有化部署方式，满足不同企业的安全和合规需求。 数据安全合规 随着全球数据隐私保护和合规要求的不断提高，国内许多企业也面临严格的合规挑战，特别是涉及 AI 应用处理的大量用户数据和行为分析。Authing 具备国家密码管理局商用密码检测中心颁发的《商用密码产品认证证书》，支持使用国密 SM1、SM2、SM3、SM4 等加密方式，保护企业数据资产安全。并且 Authing “基于云原生架构的统一身份认证管理”解决方案入选金融信创实验室优秀解决方案。Authing 统一身份与权限管理平台能够灵活应用于各行业 IT 管理、权限管理、 IT 审计、安全风控、AD 替换等多种场景，不仅支持飞腾、鲲鹏、C86、兆芯、麒麟等多种芯片，还支持主流国产操作系统和浏览器客户端使用，支持 X86、ARM 等架构。 03.使用 Authing + Next.js 为你的 AI 应用快速构建身份体系 随着 AI 应用场景的不断扩展，身份管理已成为开发者需要重点关注的关键环节。无论是用户登录、权限管理，还是数据隐私保护，都对身份认证提出了更高的要求。通过 Next.js + Authing ，开发者能够快速为 AI 应用搭建安全、高效的身份体系，为应用提供可靠的用户认证和管理功能，为开发团队节省大量时间和精力。 完善登录系统 Authing 身份登录平台为企业和开发者提供的单点登录（SSO）、多因素认证（MFA） 以及无密码登录等功能，开发者可以为用户提供安全、便捷的身份认证体验，避免传统用户名和密码登录的安全隐患。无论是跨平台应用还是需要高安全性的敏感数据管理，Authing 都能提供一个可靠、安全、灵活的身份认证解决方案，确保用户数据的安全性和隐私性。同时 Authing 提供强大的跨平台身份管理能力，支持 Web、移动端、IoT 设备等多个平台的身份验证，确保用户在不同设备和平台上的身份认证和权限管理保持一致，大幅提升用户体验和运营效率。结合 Next.js 的响应式设计能力，你可以为不同设备上的用户提供优化的认证体验。Next.js 的灵活渲染模式（如 SSR、SSG 和 CSR）能够根据用户设备和浏览器的差异动态调整页面内容，确保在各种终端上都能提供流畅的身份验证过程。 动态权限管理无论是简单的角色管理还是复杂的权限控制，Authing 提供的动态权限管理系统都能帮助你为不同角色的用户分配不同的访问权限。系统将各类权限聚合起来组成「角色」，给后台管理员（员工）赋予不同的角色，就可以控制其在系统中可接触的空间范围，确保他们「权责分明」、「不越界」。从全局考虑数据资产，基于场景对业务流程不断进行切片细化，用数据优化、重构，推动整个系统架构，实现细粒度的权限管理，以用户为中心，实现全场景业务权限的集中化、可视化、个性化。 无缝前后端集成Authing 提供了易于集成的 API 接口，你可以将前端和后端逻辑高效地结合起来，使身份验证和用户管理功能更加紧密集成，用户身份管理和权限控制流程变得简化且高度模块化。与传统的分离式前后端架构不同，开发者可以直接通过 API 快速处理登录、注册、身份验证和授权等操作，无论你开发的是 iOS 或 Android 系统的软件， 使用 React、Vue、Angular 或 Javascript 前端框架， Authing 都能支持你快速为用户提供流畅的登录认证体验，避免了繁琐的后端服务配置，提高了系统的响应速度和开发效率，保证了用户的认证过程更加流畅。 04.具体接入流程 接入 Authing 认证 Authing 配置若你还没有 Authing 账号，可以前往 https://console.authing.cn 免费注册，然后创建一个用户池。 应用配置在 Authing 控制台找到创建自建应用，填入必要信息，点击创建。 将应用的回调地址和登出回调地址修改为 Next.js 项目地址。 如果你需要在 Next.js 中使用 Authing Guard 托管模式，还需要修改如下配置： 按需开启登录方式： 创建测试用户在成员列表创建一个测试用户 在用户详情允许访问上一步创建的应用 获取配置信息在应用详情和用户池配置中，获取到应用 ID、认证地址、用户池 ID 信息，后续需要配置到 Next.js 项目中： 在 Next.js 中接入 Authing Guard 安装 Guard npm install @authing/guard-react18 # or yarn add @authing/guard-react18 嵌入 Guard可以使用内嵌模式将 Authing Guard 直接嵌入到你的登录页。 // config.tsimport type { GuardOptions } from '@authing/guard-react18' export const AUTHING_APP_ID = 'YOUR_APP_ID' // 之前获取的应用 IDexport const AUTHING_USERPOOL_ID = 'YOUR_USERPOOL_ID' // 之前获取的用户池 IDexport const AUTHING_APP_HOST = 'YOUR_APP_HOST' // 之前获取的认证地址 export const guardOptions: GuardOptions = { appId: AUTHING_APP_ID, // 如果你使用的是私有化部署的 Authing 服务，需要传入自定义 host，如: host: AUTHING_APP_HOST, // 默认情况下，会使用你在 Authing 控制台中配置的第一个回调地址为此次认证使用的回调地址。 // 如果你配置了多个回调地址，也可以手动指定（此地址也需要加入到应用的「登录回调 URL」中）： // redirectUri: "YOUR_REDIRECT_URI",} // common/authing-guard.ts// 初始化 Guardimport { Guard } from '@authing/guard-react18'import { guardOptions } from '../config'export const guard = new Guard(guardOptions) // pages/Login.tsx import { useEffect } from 'react'import '@authing/guard-react18/dist/esm/guard.min.css'import { guard } from '../common/authing-guard'import { useRouter } from 'next/router' export default function Login() { const router = useRouter() const guardEffects = async () => { guard .start(document.querySelector('#authing-guard-container') as HTMLElement) .then(userInfo => { console.log('start userInfo: ', userInfo) }) guard.on('load', e => { console.log('加载啊', e) }) guard.on('login', userInfo => { console.log('userInfo: ', userInfo) // 登录成功，跳转到个人中心 router.push('/personal') }) } useEffect(() => { guardEffects() }, []) return ( <div> <div id="authing-guard-container"></div> </div> )} 检测登录态 登录后可以使用 Guard 检测登录态，并获取登录的用户信息。 // Personal.tsx // ... useEffect(() => { guard.trackSession().then(res => { console.log('trackSession res: ', res) if (!res) { // 跳转登录页 } }) }, []) // ... Authing 配置 创建 API 资源在 Authing 控制台权限空间中创建字符串类型的数据权限资源： 输入资源信息，点击创建 新建数据资源策略 授权 在 Next.js 中间件中接入 Authing 权限 // middleware.tsimport { NextRequest, NextResponse } from 'next/server'import { AUTHING_APP_HOST, AUTHING_APP_ID, AUTHING_USERPOOL_ID } from './config' // 限制 API 路由export const config = { matcher: ['/api/(.*)']} export async function middleware(request: NextRequest) { // 获取请求头中的 token const token = request.headers.get('authorization') ?? '' const pathname = request.nextUrl.pathname if (!token) { // 未登录 return NextResponse.json( { success: false, message: 'authentication failed' }, { status: 401 } ) } // 获取用户拥有的权限，生产环境可以缓存此值，无须每次请求都重新拉取 const res: { statusCode: number data: { userPermissionList: { resourceList: { strAuthorize: { value: string actions: string[] } }[] }[] } } = await fetch(`${AUTHING_APP_HOST}/api/v3/get-user-auth-resource-list`, { headers: { Authorization: token, 'x-authing-app-id': AUTHING_APP_ID } }).then(res => res.json()) if (res.statusCode !== 200) { return NextResponse.json( { success: false, message: 'Authorization check failed' }, { status: 401 } ) } // 是否具有 API 权限 const authorized = res.data.userPermissionList.some(up => { return up.resourceList.some(rl => { return rl.strAuthorize?.value === pathname }) }) if (!authorized) { return NextResponse.json( { success: false, message: 'No permission' }, { status: 401 } ) } return NextResponse.next()} 通过简单配置和几十行代码，完成了 Next.js 中接入 Authing 认证和授权的流程，实现了用户登录注册和 API 级别的鉴权，Authing 认证还支持各种社会化身份源的接入，数据权限方面也支持类似页面菜单、按钮类型资源的接入。以上 Demo 已上传 github：Guard/examples/Next.js-react18 at v4 · Authing/Guard

用户会话管理已成为实现安全访问和优化用户体验的关键功能之一。在互联网快速发展的今天，用户对在线应用的需求不仅限于功能丰富，更关注应用的性能、安全性以及便捷性。但传统的 HTTP 通信是无状态的，这意味着每次请求都是独立的，服务器无法记住用户的身份和操作状态。为满足企业对身份管理日益复杂的需求，Authing 最新推出了 Session 管理功能，帮助企业在快速发展的数字化环境中更好地保障用户身份安全和优化用户访问体验。 01.什么是 Session？ Session 管理功能的价值TP 协议的一种会话管理机制。在传统的 HTTP 通信中，每次请求都是独立的，服务器无法记住之前的请求。而 Session 机制允许服务器保存关于客户端的状态信息，从而实现用户状态的跟踪。当用户请求访问网站时，服务器会为该用户创建一个 Session 对象，并将该 Session 对象的 ID 返回给客户端。客户端将此 Session ID 存储在 Cookie 中，以便在后续请求中使用。服务器通过检查 Cookie 中的 Session ID 来识别用户，并将其与相应的 Session 对象关联起来。 02.Session 管理功能的价值 增强安全性 通过实时监控和主动管理用户的登录状态，管理员能够随时掌握用户的会话动态。一旦发现异常或潜在风险，可以立即采取措施，减少安全事件的发生。管理员可以实时监控和主动管理用户的登录态，极大减少未授权访问的风险。例如，当用户在公共电脑上登录后忘记退出或者设备遗失时，管理员能够快速远程强制登出用户的会话，有效保护用户账户和敏感数据。尤其适用于企业对高敏感性数据的严格防护需求，减少数据泄露事件的发生。 实现单点退出（SLO） 在企业数字化应用环境中，用户通常需要访问多个相互关联的服务，例如企业门户、客户管理系统（CRM）、办公套件和其他内部或外部系统。但传统的会话管理方式往往无法在多个应用之间保持同步，尤其是在用户频繁切换服务或未主动退出会话的情况下，可能会导致身份冲突或数据泄露问题。单点退出（Single Logout, SLO）功能能够确保用户在某一应用登出后，其他相关联的会话也能够同步退出，保持全局一致性，避免了多端应用可能引发的身份冲突或数据泄露问题。 防止会话劫持 会话劫持是网络安全中的常见风险，攻击者通过窃取用户的会话信息（如 Session ID）来冒充合法用户，获取未授权的访问权限。Session 管理支持管理员主动结束用户的登录会话。一旦检测到可疑活动，管理员可以立即将用户强制退出登录状态，切断攻击者的访问路径，有效降低会话劫持的风险，帮助保护用户敏感数据免遭恶意利用，全面提升账户安全性。 遵守合规性要求 《通用数据保护条例》（GDPR）、《个人信息保护法》（PIPL）以及金融领域的多项安全合规标准都要求企业能够对用户的登录状态进行实时控制和详细记录，确保用户身份的真实性和数据的安全性。通过实时监控和管理用户会话，企业不仅可以快速响应潜在的安全风险，还能够根据合规需求强制注销用户的登录状态，有效避免因会话过期或被盗用导致的数据泄露。同时，Authing 提供详细的会话记录和日志支持，使企业能够在必要时提供完整的审计报告，为合规性审查提供可靠保障。 提高系统可靠性 Authing 新增 Session 管理，为用户身份管理带来更强大支持长时间不再访问系统，但会话仍然保持活跃状态时，可能会导致系统资源的浪费，增加服务器的负载，甚至影响其他用户的正常访问体验。Session 管理通过智能化的会话监控和清理机制，确保在用户退出或会话过期后，系统能够及时释放相关资源。在用户不再需要访问系统时，能够确保系统资源被正确释放，避免资源浪费，同时减少系统负载。 03.Authing 新增 Session 管理，为用户身份管理带来更强大支持 Session 管理（新增菜单） 默认视图 在 Session 管理默认视图中，管理员可以快速获取系统中所有活跃会话的全面概览，帮助精准识别和定位需要管理的会话。在面对大规模用户或复杂应用环境时，管理员可以通过搜索快速查找特定的 Session ID。并且 Session 管理支持停用或批量停用功能，管理员能够迅速终止存在风险或不再需要的会话状态，避免潜在的安全隐患，简化日常运维操作，进一步提高了会话管理的灵活性和安全性。 用户视图 管理员可以以用户为单位查看和管理所有与该用户关联的会话数据，帮助管理员轻松追踪某个特定用户在多个应用和设备中的登录状态。管理员可以通过搜索功能，根据用户的名称或用户 ID 精准找到该用户的所有活跃会话，确保及时了解和管理其访问情况。管理员能够停用和批量停用会话，迅速强制退出用户会话，增强对用户访问的掌控力，确保用户数据和系统安全。 在用户视图的详细信息页面中，管理员可以通过抽屉式界面查看选中用户的所有有效会话列表，提供了清晰、直观的会话数据展示。详细信息页面展示了该用户在不同应用和设备上的登录信息，帮助管理员全面了解用户的登录态和访问情况。 应用视图 在应用视图中，管理员可以按照应用为单位展示和管理所有关联的会话数据。每个应用下的会话信息都被整齐地集合在一起，方便管理员快速浏览和筛选特定应用的登录信息。通过搜索功能，管理员可以按应用名称或应用 ID 精确查找目标应用的会话数据，进一步提升管理效率，适用于多应用环境中需要高效监控和管理的场景。 管理员可以查看选中应用下的所有有效会话列表，确保全面掌握与该应用相关的用户活动和登录状态。通过抽屉式界面，管理员能够便捷地获取详细的会话信息，包括用户名称、设备信息以及会话 ID 等关键信息，帮助管理员快速识别和定位潜在的安全隐患。 设备视图 管理员通过设备视图，以设备为单位，展示与设备相关的所有会话数据。在企业内有大量设备的情况下，管理员可以通过搜索功能，快速定位特定设备的会话，能够全面掌握特定设备上的用户登录状态和活动信息，确保对各类设备的访问行为进行有效监控和管理。设备视图同样支持停用功能，管理员可以针对单一设备或多个设备上的会话进行停用操作，帮助管理员快速有效地处理设备上的会话，迅速减少潜在风险。 管理员可以查看选中设备的全部有效会话列表。每个会话都包含详细的会话信息，如 Session ID、用户名称、应用名称和设备信息等，帮助管理员迅速了解该设备上所有活跃用户的状态。通过抽屉式界面，管理员可以在不离开当前页面的情况下，轻松浏览设备相关的所有会话，并对其进行有效管理。 用户/应用/设备详情 - Session 管理（新增 Tab 页） 用户详情-session 管理 在成员管理页中新增 Session 管理，展示了与特定用户相关的所有有效会话信息。管理员可以快速查看该用户在不同设备和应用中的登录状态，帮助追踪用户的访问路径。每个用户会话条目都清晰地列出会话 ID、设备信息、应用名称、登录时间等详细内容，方便管理员快速识别可能的安全隐患。管理员可以根据需要执行针对单个会话的停用操作，或者通过批量停用功能一键处理多个会话，有效防止潜在的安全风险。 应用详情-登录控制-session 管理 应用管理页中新增 session 管理，主要展示与特定应用相关的所有会话信息。管理员可以看到使用该应用的所有用户的会话详情，包括各个用户的登录状态、设备信息、会话 ID 等。管理员能够根据应用名称或应用 ID 搜索并筛选出相关的会话数据，确保对每个应用的用户访问行为有全面了解。管理员可以及时发现潜在的非法登录行为，并采取相应的安全措施，如强制退出登录会话等。 设备详情-session 管理在设备管理页中新增 session 管理，为管理员提供了基于设备的会话数据展示。管理员可以查看与特定设备相关的所有会话信息，包括该设备上的所有活跃会话、设备名称、用户信息、会话 ID 等。在设备视图中，管理员可以精准地定位到某个设备上运行的所有会话，并可根据设备名称或设备 ID 进行筛选。若发现某个设备存在异常登录情况（例如，设备丢失或出现未经授权的登录行为），管理员可以及时采取强制登出等措施来切断对系统的非法访问，确保企业数据和用户隐私的安全。

  随着网络威胁的日益复杂，身份伪造事件频繁发生，曾经被认为万能的 MFA（多因素认证）已经难再应对。即使启用了 MFA ，员工的安全意识薄弱也可能导致身份认证被破坏。当前很多情况下 MFA 系统是无效且容易受到攻击的。英国国家网络安全中心（NCSC）指出，社会工程技术已被用于用来破坏 MFA，并观察到针对启用 MFA 账户的攻击在过去几年中呈上升趋势。随着网络威胁的不断演进，MFA 等传统身份认证方法已经难以应对日益复杂的网络威胁，企业需要采用更先进、多层次的认证手段。企业需要重新审视其 MFA 策略，不能将 MFA 视为一劳永逸的解决方案，而应根据组织的特点和风险状况，选择合适的身份认证方式。 01.企业遇到常见的攻击方式 中间人（MitM）攻击 中间人（MitM）攻击是一种常见的网络安全威胁，攻击者通过在通信双方之间进行插入或拦截，从而获取敏感信息或操纵信息传输。Uber 在 2022 年遭遇了一起针对 MFA 的严重网络安全事件。攻击者通过向员工发送虚假的 MFA 通知，结合社会工程学手段，诱骗其点击恶意链接并输入凭证，最终获得了内部系统的访问权限。可见，即使启用了 MFA ，员工的安全意识薄弱也可能导致身份认证被破坏。随着网络威胁的不断演进，MFA 等传统身份认证方法已经难以应对日益复杂的网络威胁。 SIM 卡交换攻击 通过 SMS 文本发送一次性密码是传统 MFA 技术最常用的身份验证方法之一。攻击者首先会冒充真正的用户，声称原始的 SIM 卡丢失或被盗，并通过伪造身份信息或其他方式促使电信服务商尽快补发新的 SIM 卡。一旦攻击者安装新的 SIM 卡，可以用新卡来完成 MFA 检查、重置账户凭据，从而非法访问公司资源。据统计，2023 年此类攻击造成的损失超过 6800 万美元，影响了大量个人和企业账户的安全。尤其是对于金融行业用户，SIM 卡交换攻击往往直接导致账户资金的损失。 Pass-the-cookie 攻击 在身份认证中，cookie 就像“驾驶执照”，它在未过期之前能够验证用户的合法身份，允许他们免去多次登录的麻烦，并且可以不受限制地访问资源。会话 cookie 是用户浏览网站时浏览器与服务器之间交换的重要凭证，一旦被窃取，攻击者就可以绕过了传统的身份认证步骤，直接获得了进入系统的“通行证”，使得他们能够随意访问目标账户内的所有内容。攻击者可能会利用这一权限中断业务，进行非法交易或窃取商业机密。由于许多企业依赖云服务进行日常运营，Pass-the-Cookie 攻击可能带来长期的业务中断和收入损失。MFA 疲劳MFA 疲劳攻击是近年来不断升级的网络攻击手段，攻击者利用用户的注意力和疲劳来绕过多因素认证（MFA）的防御措施。具体而言，攻击者会反复向用户发送大量的 MFA 推送通知，即所谓的“通知轰炸”。这些频繁的通知会让用户因疲于应对而产生混淆或厌烦心理，从而在不加细查的情况下“默认通过”验证请求。通过向他们发送大量伪造的MFA通知，增加出错几率，使攻击者得以成功绕过MFA验证并获得访问权限。 02.下一代三大身份认证方式，快速提升身份安全防护力 基于 AI 实现的 CAMFA 「持续自适应多因素认证（Continuous Adaptive Multi-Factor Authentication，CAMFA）」是一种安全身份验证方法，它在自适应多因素认证（基于上下文属性判断当前安全状况以增加因素认证）的基础上增加了实时风险评估技术对用户进行动态评估安全系数。 CAMFA 通过集成 AI 和机器学习算法，能够从用户的行为数据中识别潜在威胁，实时监测并评估用户风险。当系统从断层登录检测到用户时，或尝试访问其平时不常接触的的敏感资源时，AI 会标记这些异常行为并触发相应的安全响应步骤，如动态增加认证要求。基于 AI 的分析能够在短时间内完成风险评估，自动决定是否进行额外的验证步骤，确保对异常活动的快速反应。 基于区块链技术为身份管理提供了一种去中心化 基于区块链的身份认证系统允许用户对自己的身份信息进行掌控，选择性地与第三方共享必要的信息，而无需依赖中心化的身份提供商。这种自主身份( Self-Sovereign Identity， SSI )模型不仅增强了隐私保护，也使身份认证过程更加透明和安全。智能合约作为区块链的重要特性，可以自动化访问控制流程，消除人为错误，提高合规性。Authing 的去中心化数字身份（DID）解决方案为用户提供了一个安全、灵活且隐私保护的身份管理系统。通过分布式用户池，用户可以实现隔离管理，保障隐私，同时利用智能合约和区块链技术进行事务验证，确保身份的可信性和透明性。Authing 支持多协议的单点登录，为用户提供可验证的凭证及链上认证，简化身份验证过程。在 DID 管理 中，用户拥有对自己身份的完全控制，能够自主管理，减少数据泄露的风险。对于移动端用户，APP 身份柜提供了多身份（VC）的灵活切换功能，让用户可以轻松管理多个身份和账户。 后量子密码系统 随着量子计算的发展，传统加密算法面临被破解的风险。而后量子密码学致力于开发能够抵御量子计算攻击的密码算法，如格基密码和哈希签名等。抗量子密码（PQC），也称后量子密码，是能够抵抗量子计算对公钥密码算法攻击的新一代密码算法，旨在研究密码算法在量子环境下的安全性，并设计在经典和量子环境下均具有安全性的密码系统。其基于数学原理，以软件和算法为主，依赖计算复杂度，易于实现标准化、集成化、芯片化、小型化和低成本，能够提供完整的加密、身份认证和数字签名等解决方案。PQC 的出现，可有效地防止攻击者窃取和破解加密信息，为网络信息安全提供保障。除了抗量子密码外，将现有密码系统向能够抵御量子计算攻击的后量子密码系统迁移也是一项重要任务。后量子迁移过程需对现有的密码系统进行评估和分析，确定其在量子计算机攻击下的脆弱性，并设计出能够抵御量子攻击的替代方案。Authing 将 PQC 与身份认证相结合，在后量子迁移、后量子密码算法与标准化研究等领域拥有充足的技术储备，掌握后量子密码算法和协议及其性能特点等，及国内外相关标准化进展并研究了密码系统风险评估、迁移策略等制定了相关方案，为企业提供高质量密码系统。