Skip to content

系统全景与信任边界

十分钟,读懂 GenAuth 在你架构里的位置:五个参与方、三个信任域、每一条跨边界调用凭什么被信任。这一页不讲时序(那在 端到端业务时序),只讲静态结构——评审架构时,先看这张图。

一张图:五方关系与信任域

你的信任域GenAuth 信任域(SaaS 托管,或私有化部署进你的环境)既有身份信任域交办任务(业务入口)授权确认(Consent)企业账号登录(既有信任关系)AK/SK:发起委托签发委托令牌(Delegate Token)令牌兑换(Token Exchange,RFC 8693)携访问令牌调用 API权限评估(只读)User(员工/终端用户)App你的应用与资源服务AgentGenAuthHuman IAM

三个虚线框是三个信任域:

  • 你的信任域:你的应用、你的资源服务、你运行的 Agent。业务数据在这里产生、在这里消费。
  • GenAuth 信任域:授权平面。SaaS 形态托管在 api.eak.eazo.ai;私有化形态整体部署进你的 Kubernetes 环境,与 Human IAM 同域(两种形态的差异见 部署形态)。
  • 既有身份信任域:你已经在用的企业身份系统(Human IAM)。人的身份与真实权限,权威源在这里,GenAuth 不取代它。

一句先说透的架构立场:GenAuth 是授权平面,不是数据平面。 Agent 访问资源的流量是 Agent → 你的 API 直连,业务数据从不经过 GenAuth——它只负责回答"这次访问,凭什么被允许"。

五个参与方各自管什么

参与方角色一句话职责
User(员工/终端用户)权限的源头Agent 行使的每一分权力,都由人显式让渡
App(你的应用与资源服务)业务入口 + 资源侧守门员发起委托;在资源侧对访问令牌做最终校验
Agent行动者只持短时、缩权的令牌,从不持有人的原始凭证
GenAuth授权平面注册、授权确认(Consent)、签发、兑换、审计、吊销
Human IAM身份与权限的权威源回答"这个人是谁、他真实拥有什么权限"

信任假设逐条过

架构评审最关心的不是"有哪些组件",而是"谁凭什么信任谁"。逐条过一遍。

资源服务信任的是令牌,不是 Agent

你的资源服务从不需要认识某个 Agent,也不需要与它共享密钥。它信任的是令牌本身,凭三件事:

  • 签名:令牌是 GenAuth 签发的 JWT,用 GenAuth 公钥验签,伪造不了;
  • audience 绑定:兑换出的访问令牌 aud 绑定到具体目标资源,拿去别处无效——一枚令牌被窃,波及面被钉死在单一资源;
  • scope 交集:令牌里的 scope 是缩权(attenuation)后的结果,每一跳只收窄、不放大。

边界这一侧的义务:资源侧必须显式校验 sub(以谁的身份)、act(哪个行动者)、scope(允许做什么)三件套。只认 sub 不看 act,缩权就形同虚设。校验清单见 保护你的 API:资源侧集成,字段契约见 Token 与 Claim 参考

GenAuth 信任你的服务端,凭 AK/SK

发起委托是服务端行为:你的应用持租户级 AK/SK 向 GenAuth 认证。这是整个体系里唯一的长期凭证,所以约束也最重——只放服务端、不进浏览器、不进 Agent,支持轮换与即时吊销。

边界这一侧的义务:AK/SK 按你的 Secret 管理规范保管;一旦怀疑泄露,先轮换再排查。

没有人信任 Agent 的自我声明

Agent 说"我可以读客户报表"——不算数。它的权限不由它自己声明,而由三个外部集合决定:人的真实权限 ∩ 显式委托范围 ∩ 企业批准边界。Agent 拿到的委托令牌记录的是这个交集的结果,之后每次令牌兑换还只能在其中继续收窄。

这条假设的推论很关键:Agent 侧不需要保管任何长期凭证。令牌短时、缩权、可回收,Agent 被攻破时,攻击者拿到的最多是一个快过期的授权切片。原理见 Delegate Token 与缩权

GenAuth 不替用户做决定。授权确认(Consent)页明示三件事——哪个 Agent、什么范围、多长时间——用户确认后授权才成立。"人说了算"有两种出场方式:

  • 用户级 consent:终端用户在授权确认页亲自同意(interactive 主线);
  • 组织级 consent:管理员以组织名义预先同意,走受信服务端路径。

两种都留审计、都可撤回,世界观不变:权限的源头永远是人。细节见 Consent 与审批

GenAuth 对 Human IAM:只读、不写

权限之源在你既有的 Human IAM。GenAuth 只做评估性读取——"张三真实拥有哪些权限"——从不写入、从不迁移你的用户目录。私有化形态下这条约束落成三条硬规矩:专用只读账号、固定只读视图、每次读取入审计(见 部署形态 的认证矩阵)。

每个 Agent 背后必须有人:责任人假设

匿名的 Agent 不允许存在。注册即绑定两个责任人:**技术负责人(Owner)**管开发、配置与凭证轮换;**业务归属人(Sponsor)**回答"这个 Agent 算谁的账"。出事时,审计链的终点不是一个服务账号,而是一个能被问责的人。模型见 Agent 的身份模型

这套边界在防什么

  • 凭证外泄的爆炸半径:Agent 不持长期凭证,令牌短时 + audience 绑定——被窃令牌无法横向移动,等它过期就是等它失效。
  • 混淆代理人(confused deputy):访问令牌用 act 明示真实行动者,资源侧显式校验,Agent 无法冒充"就是用户本人"骗过下游。
  • 越权委托:三方交集保证"不能委托你没有的权限"——用户委托不出自己没有的权限,企业边界外的范围一律裁掉。

完整威胁模型(含令牌窃取、双轨兼容期入口等)见 安全考量

下一步

  • 部署形态:SaaS 还是私有化同域旁挂,数据边界怎么划 → 部署形态
  • 五方在时间轴上怎么互动:7 跳 / 8 跳全时序 → 端到端业务时序
  • 威胁模型与安全硬约束全量 → 安全考量