向上游转发调用方 JWT

AISIX 默认把调用方认证和上游认证分开：先校验调用方凭证，再用网关自己的凭证访问上游。对模型服务提供方来说这是正确的默认值——它用不到你组织内部的身份。

但当上游是一个按终端用户 claim 做授权的内网服务时，这个默认值就不合适了。在每一跳本来就携带全组织 JWT 的环境中，插入一个不再转发该 Token 的网关会打断整条链路：上游看到的是网关，而不是发起请求的员工。

forward_jwt_header 用于填补这个缺口。在某个上游上设置该字段后，只要调用方是以 JWT 认证的，AISIX 就会把已校验的 Token 原样投递到你指定的请求头：不新增、不删除、不改写任何 claim。

认证过程不受影响。签名、过期时间、audience、scope 以及声明映射的行为与 JWT 认证中描述的完全一致。该设置只决定 Token 是否继续传递到网关之后。

适用范围

在指向上游的那个资源上设置该字段：

字段	适用于
`provider_key.request.forward_jwt_header`	通过标准端点（`/v1/chat/completions`、`/v1/messages`、`/v1/responses`、embeddings、rerank、音频、图片，以及 files/batches/fine-tuning 面）发往该 Provider Key 上游的请求
`passthrough_route.forward_jwt_header`	由该反向代理路由服务的请求
`mcp_server.forward_jwt_header`	发往该 MCP Server 的工具调用，`type: mcp` 与 `type: openapi` 均适用——因此以 OpenAPI 注册为工具的 REST API 也会在每次工具调用时收到该 Token

该字段在所有位置默认关闭。未设置该字段的上游不会收到任何调用方 Token，与该设置出现之前的行为一致。

请求头的选择规则

任何请求头名称都被接受，包括通常用于承载凭证的那些。这是有意为之：把 Token 投递到内网服务本来就在读取的那个请求头，正是让该服务在网关插入后无须改造的关键。

填 authorization 或 proxy-authorization 时发送 Bearer <token>，即这两个请求头按定义应当承载的形式。
填其他请求头时发送裸 Token。
请求头名称必须小写。

当你指定的请求头恰好也是 AISIX 用来放自身凭证的位置时，调用方的 Token 会取代它。 上游收到的是终端用户的 Token 而不是网关的，两者绝不会同时出现。如果上游既需要认证网关、又需要识别终端用户，请把该字段指向一个独立的请求头。

Bedrock 形态的 Provider Key 是例外：它的请求经过 SigV4 签名，签名器占用 authorization 以及 x-amz-* 和 x-amzn-bedrock-accept 这几个请求头。把 Token 投递到其中会破坏签名，因此网关会将其丢弃。AISIX Cloud 在保存 Provider Key 时就会拒绝这样的配置；resources.yaml 里没有任何东西会拦下它，所以在那里请指定一个独立的请求头。

以下名称会被拒绝，因为 Token 放在其中并不能标识发送方，只会破坏这次交互：

报文构成相关的请求头：host、content-length、content-type、content-encoding、transfer-encoding、connection、keep-alive、te、trailer、upgrade、expect、accept、accept-encoding。
anthropic-version，它决定 Anthropic 形态的上游以哪种协议格式应答。
MCP 协议头 mcp-session-id、mcp-protocol-version 和 last-event-id，MCP Server 的协议层会直接拒绝这些自定义值——填入其中会导致网关根本无法连接到该 Server。
网关自身的 x-aisix-* 命名空间，其中的值是网关做出的断言，例如 x-aisix-request-id 关联 ID。

不发送 Token 的情况

以下三种情况不会发送任何 Token，且都不是错误：

上游未设置 forward_jwt_header。
调用方使用调用方 API Key 而非 JWT 认证。此时没有可转发的已校验 Token，因此该请求头不会出现，而不是发送空值——并且调用方自己以该名称发送的值会被移除，因此上游可以确信：该请求头一旦存在，其中就是 AISIX 校验过的身份。
/v1/realtime WebSocket 请求，该路径单独构建上游握手，不适用此设置。

安全注意事项

不要对公网模型服务提供方启用此功能。 该设置面向你可控的内网上游。把员工身份 Token 转发给第三方 API，等于把组织的 claim 暴露给该厂商、它的日志，以及所有能读到这些日志的人。

确认上游如何处理 aud claim。 会校验 audience 的服务将拒绝一个签发给 AISIX 的 Token。该设置适用于读取「由其自身身份服务提供方签发的 Token」中 claim 的内网服务；它不是 Token 交换机制，不会重新签发任何 Token。

传输中的 Token 是一份活凭证。 AISIX 会将投递的请求头值标记为敏感，网关自身的日志和链路追踪因此会将其脱敏。例外是 Bedrock 形态的上游——AWS SDK 会重建该请求头，敏感标记无法穿过这个边界，所以启用本功能期间不要在那类上游上调高网关日志级别。无论哪种情况，上游自身的日志记录都需要你自行确认。

配置方式

AISIX Cloud

在控制台中打开对应资源的表单，展开高级，填写将调用方 JWT 转发到此请求头。对于 Provider Key，该字段位于同一区域的 Request 覆盖 JSON 块中。

通过 Admin API 配置时，将其写入 Provider Key 的 request 块：

curl -X PATCH "$ADMIN_ENDPOINT/api/provider_keys/$PROVIDER_KEY_ID" \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "request": {
      "forward_jwt_header": "authorization"
    }
  }'

备注

request 块是整块替换而非合并。请把你已经依赖的字段（例如 default_headers）与 forward_jwt_header 一并发送，否则它们会被丢弃。可先用 GET /api/provider_keys/$PROVIDER_KEY_ID 读取当前的块内容。

在 Passthrough 路由和 MCP Server 上，该字段位于顶层：

curl -X PATCH "$ADMIN_ENDPOINT/api/environments/$ENV_ID/passthrough_routes/$ROUTE_ID" \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"forward_jwt_header": "authorization"}'

开源 AISIX 网关

在 resources.yaml 中：

provider_keys:
  - display_name: internal-llm
    provider: openai
    api_base: https://llm.internal/v1
    api_key: ${INTERNAL_LLM_KEY}
    request:
      forward_jwt_header: x-user-jwt

passthrough_routes:
  - name: system-server
    path_prefix: /passthrough/system
    target_url: https://erp.internal
    provider_key: internal-llm
    forward_jwt_header: authorization

mcp_servers:
  - name: system-server-tools
    type: openapi
    url: https://erp.internal/api/v1
    forward_jwt_header: authorization

验证方式

用网关信任的 JWT 发起一次请求，然后检查上游实际收到了什么。在你可控的上游上，为其中一次请求打印入站请求头：

curl -X POST "$GATEWAY_ENDPOINT/v1/chat/completions" \
  -H "Authorization: Bearer $AGENT_JWT" \
  -H "Content-Type: application/json" \
  -d '{"model": "internal-llm", "messages": [{"role": "user", "content": "hello"}]}'

上游应当在你配置的请求头中看到客户端发送的那个 Token。再用调用方 API Key（而非 JWT）重复一次：该请求头必须不存在。

JWT 认证——如何校验入站 Token。
声明映射——如何把已校验身份解析到调用方 API Key。
MCP 上游认证——网关访问 MCP Server 时使用的自身凭证，与本设置相互独立。

适用范围​

请求头的选择规则​

不发送 Token 的情况​

安全注意事项​

配置方式​

AISIX Cloud​

开源 AISIX 网关​

验证方式​

延伸阅读​