服务网格mTLS与应用层OAuth2认证的能力与迁移平滑性差异

同一个服务认证需求，Fenix’s Bookstore给出了两种截然不同的实现路径， 差异正好体现了[[单向TLS与双向TLS的保护对象差异]]背后”有没有基础设施 支持”这个分水岭。Istio版本靠基础设施解决：整个集群受Istio管理时，只需 一份PeerAuthentication配置就能对某个命名空间下全部流量启用mTLS，不需要 写任何认证代码，也不需要自己部署PKI/CA。更巧妙的是”宽容模式”（Permissive Mode）——受管理的服务同时接受纯文本和mTLS流量，纯文本流量留给还没接入 服务网格的节点、mTLS流量走服务网格内部——这让mTLS可以按服务逐个迁移， 迁移中的服务甚至不会中断已建立的纯文本连接，最终全部迁移完才切到严格 模式（STRICT）。Spring Cloud版本靠应用层实现：借用OAuth 2的客户端模式， 每个内部微服务预先和认证服务器约定ClientSecret，调用前先拿ClientSecret 换JWT令牌，再拿令牌访问服务——这套流程本质上是”用授权流程顺带完成了 认证”。但这个应用层方案有一个致命局限：它只解决”谁在调用”，无法解决 传输链路本身可能被中间人窃听、篡改，也无法阻止攻击者截获JWT令牌后拿去 冒充调用者——这意味着它只能在”默认内网节点间彼此信任”的边界安全模型下 可靠工作，不满足零信任模型的前提。

结构图：

flowchart LR
    A[Istio+mTLS路径] -->|PeerAuthentication配置, 无须代码| B[全流量mTLS加密+双向验证]
    A -->|宽容模式Permissive| C[同时接受纯文本+mTLS, 逐服务平滑迁移]
    D[Spring Cloud+OAuth2路径] -->|ClientSecret换JWT令牌| E[应用层验证调用者身份]
    E -.无法防御.-> F[传输被窃听篡改/令牌被截获冒用]
    F --> G[只能在边界安全模型下可靠工作, 不满足零信任]