系列收官。身份有了、路线选了 L7,这一篇把协议落到能动手的程度:WIMSE 用两个 JWT——WIT(身份令牌,含公钥,像证书一样可公开)和 WPT(证明令牌,极短命的 bearer)——加上两个 HTTP 头和一套五步校验,让任何服务都能确切知道“在跟谁说话”。附中性化令牌示例、请求协议、授权取舍,以及“对现有 JWT 库改动其实不大”的落地评估。

服务有了身份证之后,拿它做服务间认证有两条路:走 TLS 层的 mTLS(证书),还是走应用层的 JWT?这不是技术优劣题,是架构取舍题。本文把 mTLS 与 JWT、L4 与 L7 的权衡摊开讲透,重点拆解一个容易被忽略的“非线性 rollout 陷阱”:为什么 mTLS 明明更“正统”,很多工程主导的团队却先选了 JWT。

一个后端服务半夜要去连数据库、调另一个内部服务,它凭什么证明“我就是那个有权限的服务”?很多团队的答案是:把身份隐式绑在云厂商的 IAM 角色和一大坨长期密钥上。这套做法能跑,但把身份、密钥、云、权限死死焊在一起,越长越重。本文是“工作负载身份”系列第一篇,讲清楚问题出在哪,以及业界标准解法 SPIFFE / SVID 到底给了我们什么。

mTLS + 证书绑定令牌很安全,但浏览器和 App 里没法优雅地管客户端证书。DPoP(RFC 9449)就是为公网客户端准备的那把锁:客户端自己生成一对公私钥,每次请求都附上一个用私钥签名的 DPoP proof。本文把 DPoP 的每个字段、两段流程、防重放机制和常见坑一次讲透,并回答“服务间调用要不要用 DPoP”,顺带讲清 SPIFFE JWT-SVID 的定位。

Bearer Token 最大的毛病是“谁捡到谁能用”。本文用大白话讲清两个专治盗用的概念——PoP（证明我是令牌的主人）和 Certificate-Bound Token（令牌只认这张证书），顺带把它们跟 mTLS、DPoP、Kubernetes、SPIFFE 之间的关系理顺。

微服务各管一套权限，最后往往没人说得清谁能调用谁。本文给出统一授权中心的分层架构、协议选择、典型实例与演进路线，重点讲清身份、决策和执行如何分工。

SPIRE 系列第四篇：用一个迷你 Python 实验把 Workload Identity 落地，用 JWT-SVID 替代应用侧数据库密码分发，并串起 SPIFFE、SPIRE、Zero Trust 的完整链路。

SPIRE 系列第三篇：从信任链、攻击面、JWT-SVID 风险、Server/Agent 加固和事件响应角度，分析如何把 SPIFFE/SPIRE 用成真正的 Zero Trust 身份层。

SPIRE 系列第二篇：在理解 Workload Identity 与 Zero Trust 目标之后，拆开 SPIRE Server、Agent、Registration Entry、Workload API、部署模式与插件体系。

SPIRE 系列第一篇：从为什么需要 Workload Identity 开始，解释 SPIFFE/SPIRE 的核心概念、落地路径、部署模式和资源成本，为后续架构、安全与实战 Lab 打基础。