4、签名链路原理：数字签名在微服务中的必要性、JWT与mTLS对比、请求签名流程

4.1 数字签名在微服务中的必要性

在多租户签名链路中，数字签名是保障请求完整性、来源真实性和不可抵赖性的核心技术。微服务架构下，服务间通信频繁跨越网络边界，面临以下风险：

• 中间人篡改：请求在传输过程中可能被劫持并修改负载。
• 身份伪造：攻击者冒充合法服务发起恶意请求。
• 重放攻击：捕获有效请求后重复提交。
• 租户隔离失效：多租户场景下，一个租户的签名可能被另一个租户复用。

数字签名通过私钥签名 + 公钥验签机制，确保接收方能够验证请求是否由持有对应私钥的发送方生成，且内容未被修改。在 Istio 环境中，签名通常由 Sidecar 代理（Envoy）或应用层 SDK 完成，并与服务网格的认证策略协同工作。

4.2 JWT 与 mTLS 对比

JWT（JSON Web ）和 mTLS（双向 TLS）是微服务通信中两种主流的身份认证与签名机制。它们在实现原理、适用场景和运维复杂度上存在显著差异。

4.3 请求签名流程

一个完整的请求签名流程包含签名生成、传输和验签三个阶段。以下流程图展示了服务 A 向服务 B 发送签名请求的典型过程：

4.4 签名流程详细步骤

1. 构造请求负载：服务 A 确定 HTTP 方法、路径、租户 ID、请求体摘要（SHA-256）、时间戳（Unix 时间戳，精度到秒）。
2. 生成签名：使用服务 A 的私钥对负载进行签名（如 RS256 或 ES256），生成签名值。
3. 封装 JWT：将签名值、负载声明、签发者（iss）、租户 ID（sub）、过期时间（exp）封装为 JWT 令牌。
4. 附加到请求：将 JWT 放入 HTTP 请求的 Authorization: Bearer <> 头部。
5. 传输请求：通过 mTLS 加密通道将请求发送至服务 B。
6. 提取 JWT：服务 B 的 Sidecar 或应用层从请求头部提取 JWT。
7. 验签：使用服务 A 的公钥（从 JWKS 端点或本地缓存获取）验证 JWT 签名。
8. 校验声明：验证时间戳是否在允许偏差范围内（通常 ±5 分钟），租户 ID 是否匹配，请求体摘要是否一致。
9. 处理或拒绝：验签通过后，服务 B 处理请求；否则返回 401 Unauthorized。

4.5 签名链路关键设计点

4.6 Istio 中的签名集成

Istio 通过 RequestAuthentication 和 AuthorizationPolicy 资源，支持在 Sidecar 层面直接验证 JWT 签名，无需修改应用代码：

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: jwt-auth
  namespace: tenant-ns
spec:
  selector:
    matchLabels:
      app: backend-service
  jwtRules:
  - issuer: "service-a.tenant-cluster.local"
    jwksUri: "http://jwks.tenant-cluster.local/.well-known/jwks.json"
    forwardOriginalToken: true
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: tenant-ns
spec:
  selector:
    matchLabels:
      app: backend-service
  action: ALLOW
  rules:
  - from:
    - source:
        requestPrincipals: ["*"]
    when:
    - key: request.auth.claims[tenant_id]
      values: ["tenant-123"]

上述配置实现了：

• Sidecar 自动提取并验证 JWT 签名。
• 仅允许携带有效 JWT 且租户 ID 为 tenant-123 的请求通过。
• 原始 JWT 通过 forwardOriginalToken: true 转发给应用层。