ATH 支持两种部署模型。两者都执行相同的可信握手——区别在于执行逻辑所在的位置。

​
设计原则

  1. 可信握手：应用侧授权和用户侧授权都是必需的。两者都不可绕过。
  2. 去中心化：任何代理都可以连接到任何服务，无需中央权威机构。
  3. 开放：不绑定单一平台、供应商或技术栈。
  4. 轻量级：专注于信任握手和授权。
  5. 渐进式采用：服务可以分阶段采用 ATH，从零变更的网关模式到完整的原生实现。

​
网关模式

一个 ATH 兼容的网关位于代理和服务之间。服务提供商无需任何更改——网关代替它们执行可信握手。 
┌──────────────────────────────────────────────────┐
│  Agent                                           │
│  （例如：旅行规划师、编程助手）                  │
└──────────────────┬───────────────────────────────┘
                   │  ATH Client
┌──────────────────▼───────────────────────────────┐
│  ATH Gateway                                     │
│                                                  │
│  ┌─────────────────────────────────────────────┐ │
│  │ Agent Registry（代理注册表）                │ │
│  │ - 代理身份验证                              │ │
│  │ - 每个代理的能力策略                        │ │
│  │ - 应用侧授权决策                            │ │
│  └─────────────────────────────────────────────┘ │
│                                                  │
│  ┌─────────────────────────────────────────────┐ │
│  │ Authorization Engine（授权引擎）            │ │
│  │ - 范围交集执行                              │ │
│  │ - 令牌到代理的绑定                          │ │
│  │ - 审计日志                                  │ │
│  └─────────────────────────────────────────────┘ │
│                                                  │
│  ┌─────────────────────────────────────────────┐ │
│  │ OAuth Bridge（OAuth 桥接）                  │ │
│  │ - OAuth 流程委托                            │ │
│  │ - 令牌管理与刷新                            │ │
│  │ - API 代理                                  │ │
│  └─────────────────────────────────────────────┘ │
└──────────────────┬───────────────────────────────┘
                   │  标准 OAuth 2.0 / HTTPS
┌──────────────────▼───────────────────────────────┐
│  Service Provider                                │
│  （无需任何更改）                                │
└──────────────────────────────────────────────────┘
OAuth 桥接是一个实现细节。实现方可以使用任何 OAuth 2.0 客户端库或自定义集成。桥接必须支持：
  • 授权码授予（RFC 6749 §4.1），使用表单编码的令牌请求
  • PKCE（RFC 7636），使用 S256 质询方法
  • 资源指示器（RFC 8707）——可选，存在时直接传递
连接到网关的每个提供商都需要各自的 OAuth 2.0 客户端注册（授权端点、令牌端点、客户端凭证）。 最适合：立即部署、概念验证、无需修改即可保护现有服务。

​
原生模式

服务直接实现 ATH 端点，在自己的基础设施内同时执行应用侧授权和用户侧授权。 
┌──────────────────────────────────────────────────┐
│  Agent                                           │
└──────────────────┬───────────────────────────────┘
                   │  ATH Client
┌──────────────────▼───────────────────────────────┐
│  Service Provider（ATH 原生支持）                │
│                                                  │
│  ┌─────────────────────────────────────────────┐ │
│  │ Agent Registry + Authorization Engine       │ │
│  │ - 代理身份验证                              │ │
│  │ - 可信握手执行                              │ │
│  │ - 范围交集                                  │ │
│  └─────────────────────────────────────────────┘ │
│                                                  │
│  ┌─────────────────────────────────────────────┐ │
│  │ Service Business Logic（服务业务逻辑）      │ │
│  └─────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────┘
最适合：希望完全控制代理访问的服务、长期生产环境部署。

​
核心组件

​
代理注册表（Agent Registry）

存储已注册的代理及其批准的能力。处理：
  • 代理身份验证（验证证明 JWT）
  • 每个代理的能力策略（每个代理被批准的范围）
  • 应用侧授权决策（批准/拒绝/部分批准）

​
授权引擎（Authorization Engine）

编排 OAuth 流程并执行范围交集：
  • 发起 OAuth 同意流程
  • 计算 Effective Scope = Agent Approved ∩ User Consented ∩ Requested
  • 将令牌绑定到特定的 (agent_id, user_id, provider_id, scopes) 元组

​
OAuth 桥接（网关模式）

处理与服务提供商的实际 OAuth 2.0 通信。所有 OAuth 流程使用 PKCE（RFC 7636）和 S256 质询方法。参考实现支持：
  • 直接 OAuth — 连接到任何 OAuth2 提供商
  • 模拟模式 — 内置模拟，无需外部依赖即可测试

​
API 代理（网关模式）

验证 ATH 令牌并将请求转发到上游服务，确保代理只能访问其授权范围内的资源。