统一优化定时任务 token / credential 处理模型

[louis4li]

背景

在 origin/feature/integrate 中，定时任务触发 service invocation 的 token / credential 处理已经从历史上的 header/payload 透传，演进为 typed auth 模型，但当前仍存在多种并行路径。后续需要统一治理，避免 recurring schedule 中 token 过期、raw secret 持久化、入口能力不一致等问题。

当前主要方式

1. SenderNyxId：保存 subject + scope，每次 fire 重新签发短 token

• 模型：ScheduledServiceInvocationAuth(SenderNyxId: ...)
• HTTP 字段：serviceInvocation.auth.senderNyxId
• 运行时通过 NyxID broker IssueShortLivedAsync 按 subject/scope 重新换 token。
• token 注入到 ChatRequestEvent.LlmControl.SenderNyxIdAccessToken。
• Workflow schedule 还会投影为 ConnectorHttpAuthorization = Bearer ...。

问题：

• 创建/更新时没有像 ScopeOwnerNyxId 一样做 binding/scope 预检，错误会延迟到 fire/run-now。
• subject/platform 规范化在不同入口不完全一致。
• 依赖 host 正确注册 credential exchange port，否则运行时才失败。

2. DurableSenderBearerToken：把 bearer token 直接保存到 schedule

• 模型：ScheduledServiceInvocationAuth(DurableSenderBearerToken: ...)
• HTTP 字段：serviceInvocation.auth.durableSenderBearerToken
• Studio provisioning 会优先使用 minted durable run credential；如果只是 forwarded ephemeral token，仅允许非 recurring demo 使用。

问题：

• raw token 会进入 schedule actor state，属于 secret 持久化风险。
• 通用 HTTP API 无法证明传入 token 真的是 durable；调用方可能把短 session token 塞进去，recurring schedule 后续过期。
• Studio 有 durable/ephemeral 分类保护，但通用 schedules API 没有同等保护。
• Workflow schedule mapper 不支持 durable token，入口能力不一致。

3. ScopeOwnerNyxId：以当前 authenticated owner subject 重新签发 token

• 模型：ScheduledServiceInvocationAuth(ScopeOwnerNyxId: ...)
• HTTP 字段：serviceInvocation.auth.scopeOwnerNyxId
• 创建/更新时从当前 claims 解析 owner subject，并预检 binding/scope 是否可签发。
• fire 时重新签发 token，注入到 LlmControl.NyxIdAccessToken / NyxIdOrgToken，workflow 时也投影到 ConnectorHttpAuthorization。

问题：

• IssueScopeOwnerNyxIdAsync(source, serviceIdentity, ...) 当前实现基本只用 owner subject + scope，serviceIdentity 没形成真实授权约束。
• 创建/更新时实际 issue 一次 token 做预检，存在副作用；fire 时还会再次 issue。
• 如果通过内部 application service 构造 schedule，是否经过同等校验取决于调用方路径。

4. 无 auth

• ScheduledServiceInvocationAuth? 可为空，dispatch 会继续执行。

问题：

• 对 workflow/connector 类型调用，可能到下游才发现没有 caller credential。
• 缺少统一的“哪些 schedule target 必须带 credential”的 typed policy。

5. legacy header / metadata 路径

• 定时 headers 会写入 ChatRequestEvent.Metadata。
• connector.http.authorization 被精确字符串跳过，避免 legacy authorization header 继续注入。

问题：

• 只屏蔽精确 key，大小写/变体不一定覆盖。
• 说明目前仍有 typed auth 与 legacy metadata/header 兼容路径并存。

需要讨论的统一方向

A. 明确 schedule credential 的权威模型

建议统一为“credential source / reference”，而不是保存可直接使用的 raw token：

• SenderNyxIdCredentialSource(subject, scope)
• ScopeOwnerCredentialSource(ownerSubject, scope, serviceBinding?)
• DurableCredentialReference(id/handle)，由安全 credential store 或 NyxID 管理，而不是 actor state 保存 raw bearer token

待讨论：是否保留 DurableSenderBearerToken，如果保留，是否只允许内部 trusted provisioning 使用，不开放给通用 HTTP API。

B. 创建/更新阶段只做无副作用 validation

目标：

• 所有 auth source 都能在 create/update 阶段做一致校验。
• validation 不应靠实际 issue access token 完成；应优先使用 NyxID binding/scope introspection 或 capability check。
• fire/run-now 阶段才签发短 token。

C. 入口能力统一

需要对齐：

• /api/schedules HTTP entry
• workflow schedule application mapper
• Studio provisioning
• internal IScheduledDispatchApplicationService

目标：同一种 schedule auth policy 在所有入口含义一致，避免 Studio 有保护但通用 API 没有保护。

D. 消除 token 注入双轨

当前 token 最终可能进入：

• LlmControl.NyxIdAccessToken
• LlmControl.NyxIdOrgToken
• LlmControl.SenderNyxIdAccessToken
• ConnectorHttpAuthorization

需要决定：

• workflow caller credential 是否应该只通过 typed WorkflowCallerCredential/control context 表达；
• ConnectorHttpAuthorization 是否只是边界 adapter 兼容字段，是否能下沉到 workflow adapter 内部生成；
• NyxIdAccessToken 与 NyxIdOrgToken 同写是否仍有必要。

E. policy 化 required credential

不同 target/implementation 对 credential 的要求应显式表达：

• static service 是否允许 no-auth？
• workflow service 是否必须有 caller credential？
• connector/tool 调用是否按 endpoint contract 声明所需 credential role？

避免 auth 为空时运行到下游才失败。

候选落地步骤

1. 定义 schedule credential policy/contract：credential source、role、requiredness、validation semantics。
2. 把 create/update validation 从 HTTP endpoint 下沉到 application/domain 统一路径。
3. 为 SenderNyxId 补齐 binding/scope validation。
4. 将 raw durable bearer token 替换为 durable credential reference，或至少限制为 internal trusted path。
5. 收敛 workflow token 注入路径，明确 ConnectorHttpAuthorization 是否仅为 adapter 边界产物。
6. 补充 tests：create/update validation、run-now、recurring fire、revoked binding、scope mismatch、ephemeral token 不允许 recurring。

参考代码位置

• src/platform/Aevatar.GAgentService.Hosting/Endpoints/Schedules/ScheduledDispatchEndpoints.cs
• src/platform/Aevatar.GAgentService.Infrastructure/Schedules/ScheduledServiceInvocationDispatchPort.cs
• src/platform/Aevatar.GAgentService.Infrastructure/Schedules/NyxIdScheduledServiceInvocationCredentialExchangePort.cs
• src/platform/Aevatar.GAgentService.Core/Schedules/ScheduledDispatchGAgent.cs
• src/Aevatar.Studio.Application/Studio/Services/StudioWorkflowProvisioningService.cs
• src/workflow/Aevatar.Workflow.Application/Schedules/WorkflowScheduleConfigurationMapper.cs