尧图网页设计 
Univer Workspace如何保护AI代理登录安全浏览器批准登录与OAuth PKCE认证原理解析【免费下载链接】univer-workspaceAn open-source Office workspace where people and AI agents create, collaborate, and review together.项目地址: https://gitcode.com/gh_mirrors/un/univer-workspaceUniver Workspace 是一个开源的协作式 Office 工作区让人类与 AI 代理Agent共同创建、编辑和评审文档。当 AI 代理需要登录用户的工作区时登录安全就成了关键问题——它不能像网站那样依赖 Cookie也不能把密码交给代理保管。Univer Workspace 采用「浏览器批准登录 OAuth 授权码 PKCE 认证」的组合方案让敏感凭据始终留在用户浏览器和受保护的本地进程中AI 代理拿到的只是短期、一次性的授权票据。本文将用尽量少的代码讲清楚这套登录安全机制的工作原理。为什么 AI 代理登录需要特殊的安全设计传统 Web 应用登录依赖浏览器 Cookie而 Univer Workspace 的 AI 代理运行在本地 Harness 进程中桌面客户端或 CLI它有自己的浏览器环境直接复用用户浏览器的会话是不安全的。核心难题有三个公共客户端没有密钥本地代理无法像服务端那样安全保存client_secret任何人都可以反编译它。授权码会暴露在浏览器中外部浏览器完成授权后回调 URL 上的授权码可能被恶意页面截获。需要用户明确同意AI 代理代表用户操作必须让用户在浏览器里亲眼确认谁在请求、请求什么范围。Univer Workspace 的答案就是 OAuth 授权码流程加上 PKCEProof Key for Code Exchange扩展并配合本地回环端点与自定义协议做最后一公里的安全传递。浏览器批准登录一次完整登录流程拆解整个登录流程在 apps/agent/src/oauth-authorization.ts 中实现可以拆成 4 步1️⃣ 本地生成 state 与 code_verifier本地代理调用beginOAuth时见 oauth-authorization.ts会用密码学安全随机数生成两样东西state32 字节随机值防 CSRF 的对暗号回调时必须原样带回code_verifier48 字节随机值PKCE 的私钥只保存在本地内存中永不上网传输。同时计算code_challenge SHA256(code_verifier)随授权请求一起发出去。注意挑战值可以公开但无法从挑战值反推出验证值——这正是 S256 方法的数学基础。2️⃣ 打开外部浏览器完成身份认证本地代理把用户重定向到工作区服务端的/api/auth/authorize端点。用户在自己的浏览器里正常登录如果客户端配置了requiresConsent还会看到一个授权同意页consent page。这个同意页是登录安全的第一道人工防线它清楚展示哪个客户端client_id、以谁的身份、请求哪些权限范围scope并提供 Allow / Deny 按钮。其实现见 oauth-authorization-router.ts有几个值得注意的细节同意页携带一次性consent_token5 分钟过期、只能用一次、且绑定当前登录用户——重放攻击和跨用户伪造都会直接失败用户选择 Deny 时服务端回传erroraccess_denied代理侧不会创建任何会话页面启用了严格的 CSP 头与X-Frame-Options: DENY防止被嵌入钓鱼页面。3️⃣ 授权码的安全回传自定义协议而非直接落盘工作区服务端验证身份后签发一个60 秒有效、一次性使用的授权码见 oauth-clients.ts并重定向回本地代理的回调地址。这里有个精巧设计外部浏览器里没有桌面客户端的会话 Cookie见 desktop-oauth.ts 中对 Origin/Cookie 围栏的说明。因此回调页不直接完成登录而是把code state通过自定义协议univer-workspace://login#...交还给桌面应用页面文案为请打开应用以完成登录你可以关闭此页面见 desktop-oauth-page.ts。这样即使有人截获了浏览器中的授权码攻击者也没有本地验证进程持有的code_verifier无法完成令牌交换。4️⃣ 本地 PKCE 交换完成登录桌面客户端收到授权码后调用/auth/device/complete之类的本地端点端点契约定义在 contract.ts把code state code_verifier一起提交。服务端在 oauth-authorization-router.ts 的令牌端点中依次验证校验项防的是什么code_challenge与code_verifier的 S256 匹配授权码被截获后的重放攻击state与本地记录一致跨站请求伪造CSRFredirect_uri精确匹配注册表开放重定向攻击授权码 60 秒过期 用后即删长时重放公共客户端禁止携带client_secret凭据混淆与误用全部通过后才签发会话令牌sessionscope 才会返回access_token代理进程通过 workspace-auth.ts 中的WorkspaceAuthService把身份与令牌绑定到本地进程——一个 Harness 进程只绑定一个远端身份且切换身份时带有版本校验防止登录过程中并发竞态。没有密钥的客户端PKCE 如何补上信任缺口PKCE 的本质是一句话把只有本地进程知道的秘密变成一次不可逆的数学承诺。发起时只公开code_challenge S256(code_verifier)见 oauth-authorization.ts 中randomBytes(48)生成 verifier、createHash(sha256)生成 challenge 的过程兑换时服务端用SHA256(收到的 verifier) 存储的 challenge来证明你就是发起请求的那个本地进程。由于 SHA-256 不可逆公开 challenge 不会泄露 verifier而没有 verifier即使拿到授权码也换不到令牌。服务端验证逻辑见 validateOAuthCodeVerifier。命令行CLI用户还有另一条路设备授权流如果 AI 代理以 CLI 形式运行没有图形界面Univer Workspace 还提供标准 OAuth 设备授权协议本地进程请求一个短码user_code和验证 URL用户在自己的浏览器打开该 URL 批准CLI 则按固定间隔轮询交换结果成功后才拿到workspace_session会话令牌。整个流程见 device-authorization.ts其中有两个安全细节值得称道验证 URL 必须与请求的 origin 完全同源否则直接判定为跨域攻击并抛错device-authorization.ts设备流程不创建本地用户、Cookie 或浏览器会话只做远端身份交换职责边界清晰。相关源码与模块路径速查模块说明apps/agent/src/oauth-authorization.ts本地代理侧 OAuth 发起与 PKCE 令牌交换apps/agent/src/desktop-oauth.ts桌面端登录端点与 Origin/Cookie 围栏apps/agent/src/desktop-oauth-page.ts外部浏览器回调页与自定义协议回传apps/agent/src/device-authorization.ts设备授权流CLI 登录apps/agent/src/workspace-auth.ts本地进程级身份与令牌绑定服务apps/workspace/server/src/modules/identity/oauth-authorization-router.ts服务端授权端点、同意页与令牌端点apps/workspace/server/src/modules/identity/oauth-clients.ts客户端注册、PKCE 校验与一次性授权码签发apps/workspace/contracts/http/paths/auth.yaml认证相关 HTTP 接口的 OpenAPI 契约总结三层防线让 AI 代理登录只可验证不可窃取回顾整个设计Univer Workspace 用三层防线回答了AI 代理如何安全登录人工批准层浏览器中的同意页 一次性 consent token让用户对每次 AI 代理登录拥有知情权与否决权传输隔离层授权码经自定义协议仅回传给本地应用外部浏览器拿不到会话 Cookie也拿不到令牌密码学验证层OAuth PKCES256确保只有持有code_verifier的原始本地进程才能兑换令牌配合 60 秒一次性授权码、redirect_uri 白名单与 CSP 等纵深防御。对于希望在自己的产品中集成 AI 代理登录的开发者这套无密钥公共客户端 浏览器批准 PKCE的模式是目前 OAuth 生态中最稳妥的参考实现之一也值得直接参考 apps/agent/src/ 下的开源代码。【免费下载链接】univer-workspaceAn open-source Office workspace where people and AI agents create, collaborate, and review together.项目地址: https://gitcode.com/gh_mirrors/un/univer-workspace创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Univer Workspace如何保护AI代理登录安全：浏览器批准登录与OAuth PKCE认证原理解析
Univer Workspace如何保护AI代理登录安全浏览器批准登录与OAuth PKCE认证原理解析【免费下载链接】univer-workspaceAn open-source Office workspace where people and AI agents create, collaborate, and review together.项目地址: https://gitcode.com/gh_mirrors/un/univer-workspaceUniver Workspace 是一个开源的协作式 Office 工作区让人类与 AI 代理Agent共同创建、编辑和评审文档。当 AI 代理需要登录用户的工作区时登录安全就成了关键问题——它不能像网站那样依赖 Cookie也不能把密码交给代理保管。Univer Workspace 采用「浏览器批准登录 OAuth 授权码 PKCE 认证」的组合方案让敏感凭据始终留在用户浏览器和受保护的本地进程中AI 代理拿到的只是短期、一次性的授权票据。本文将用尽量少的代码讲清楚这套登录安全机制的工作原理。为什么 AI 代理登录需要特殊的安全设计传统 Web 应用登录依赖浏览器 Cookie而 Univer Workspace 的 AI 代理运行在本地 Harness 进程中桌面客户端或 CLI它有自己的浏览器环境直接复用用户浏览器的会话是不安全的。核心难题有三个公共客户端没有密钥本地代理无法像服务端那样安全保存client_secret任何人都可以反编译它。授权码会暴露在浏览器中外部浏览器完成授权后回调 URL 上的授权码可能被恶意页面截获。需要用户明确同意AI 代理代表用户操作必须让用户在浏览器里亲眼确认谁在请求、请求什么范围。Univer Workspace 的答案就是 OAuth 授权码流程加上 PKCEProof Key for Code Exchange扩展并配合本地回环端点与自定义协议做最后一公里的安全传递。浏览器批准登录一次完整登录流程拆解整个登录流程在 apps/agent/src/oauth-authorization.ts 中实现可以拆成 4 步1️⃣ 本地生成 state 与 code_verifier本地代理调用beginOAuth时见 oauth-authorization.ts会用密码学安全随机数生成两样东西state32 字节随机值防 CSRF 的对暗号回调时必须原样带回code_verifier48 字节随机值PKCE 的私钥只保存在本地内存中永不上网传输。同时计算code_challenge SHA256(code_verifier)随授权请求一起发出去。注意挑战值可以公开但无法从挑战值反推出验证值——这正是 S256 方法的数学基础。2️⃣ 打开外部浏览器完成身份认证本地代理把用户重定向到工作区服务端的/api/auth/authorize端点。用户在自己的浏览器里正常登录如果客户端配置了requiresConsent还会看到一个授权同意页consent page。这个同意页是登录安全的第一道人工防线它清楚展示哪个客户端client_id、以谁的身份、请求哪些权限范围scope并提供 Allow / Deny 按钮。其实现见 oauth-authorization-router.ts有几个值得注意的细节同意页携带一次性consent_token5 分钟过期、只能用一次、且绑定当前登录用户——重放攻击和跨用户伪造都会直接失败用户选择 Deny 时服务端回传erroraccess_denied代理侧不会创建任何会话页面启用了严格的 CSP 头与X-Frame-Options: DENY防止被嵌入钓鱼页面。3️⃣ 授权码的安全回传自定义协议而非直接落盘工作区服务端验证身份后签发一个60 秒有效、一次性使用的授权码见 oauth-clients.ts并重定向回本地代理的回调地址。这里有个精巧设计外部浏览器里没有桌面客户端的会话 Cookie见 desktop-oauth.ts 中对 Origin/Cookie 围栏的说明。因此回调页不直接完成登录而是把code state通过自定义协议univer-workspace://login#...交还给桌面应用页面文案为请打开应用以完成登录你可以关闭此页面见 desktop-oauth-page.ts。这样即使有人截获了浏览器中的授权码攻击者也没有本地验证进程持有的code_verifier无法完成令牌交换。4️⃣ 本地 PKCE 交换完成登录桌面客户端收到授权码后调用/auth/device/complete之类的本地端点端点契约定义在 contract.ts把code state code_verifier一起提交。服务端在 oauth-authorization-router.ts 的令牌端点中依次验证校验项防的是什么code_challenge与code_verifier的 S256 匹配授权码被截获后的重放攻击state与本地记录一致跨站请求伪造CSRFredirect_uri精确匹配注册表开放重定向攻击授权码 60 秒过期 用后即删长时重放公共客户端禁止携带client_secret凭据混淆与误用全部通过后才签发会话令牌sessionscope 才会返回access_token代理进程通过 workspace-auth.ts 中的WorkspaceAuthService把身份与令牌绑定到本地进程——一个 Harness 进程只绑定一个远端身份且切换身份时带有版本校验防止登录过程中并发竞态。没有密钥的客户端PKCE 如何补上信任缺口PKCE 的本质是一句话把只有本地进程知道的秘密变成一次不可逆的数学承诺。发起时只公开code_challenge S256(code_verifier)见 oauth-authorization.ts 中randomBytes(48)生成 verifier、createHash(sha256)生成 challenge 的过程兑换时服务端用SHA256(收到的 verifier) 存储的 challenge来证明你就是发起请求的那个本地进程。由于 SHA-256 不可逆公开 challenge 不会泄露 verifier而没有 verifier即使拿到授权码也换不到令牌。服务端验证逻辑见 validateOAuthCodeVerifier。命令行CLI用户还有另一条路设备授权流如果 AI 代理以 CLI 形式运行没有图形界面Univer Workspace 还提供标准 OAuth 设备授权协议本地进程请求一个短码user_code和验证 URL用户在自己的浏览器打开该 URL 批准CLI 则按固定间隔轮询交换结果成功后才拿到workspace_session会话令牌。整个流程见 device-authorization.ts其中有两个安全细节值得称道验证 URL 必须与请求的 origin 完全同源否则直接判定为跨域攻击并抛错device-authorization.ts设备流程不创建本地用户、Cookie 或浏览器会话只做远端身份交换职责边界清晰。相关源码与模块路径速查模块说明apps/agent/src/oauth-authorization.ts本地代理侧 OAuth 发起与 PKCE 令牌交换apps/agent/src/desktop-oauth.ts桌面端登录端点与 Origin/Cookie 围栏apps/agent/src/desktop-oauth-page.ts外部浏览器回调页与自定义协议回传apps/agent/src/device-authorization.ts设备授权流CLI 登录apps/agent/src/workspace-auth.ts本地进程级身份与令牌绑定服务apps/workspace/server/src/modules/identity/oauth-authorization-router.ts服务端授权端点、同意页与令牌端点apps/workspace/server/src/modules/identity/oauth-clients.ts客户端注册、PKCE 校验与一次性授权码签发apps/workspace/contracts/http/paths/auth.yaml认证相关 HTTP 接口的 OpenAPI 契约总结三层防线让 AI 代理登录只可验证不可窃取回顾整个设计Univer Workspace 用三层防线回答了AI 代理如何安全登录人工批准层浏览器中的同意页 一次性 consent token让用户对每次 AI 代理登录拥有知情权与否决权传输隔离层授权码经自定义协议仅回传给本地应用外部浏览器拿不到会话 Cookie也拿不到令牌密码学验证层OAuth PKCES256确保只有持有code_verifier的原始本地进程才能兑换令牌配合 60 秒一次性授权码、redirect_uri 白名单与 CSP 等纵深防御。对于希望在自己的产品中集成 AI 代理登录的开发者这套无密钥公共客户端 浏览器批准 PKCE的模式是目前 OAuth 生态中最稳妥的参考实现之一也值得直接参考 apps/agent/src/ 下的开源代码。【免费下载链接】univer-workspaceAn open-source Office workspace where people and AI agents create, collaborate, and review together.项目地址: https://gitcode.com/gh_mirrors/un/univer-workspace创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考