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

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

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

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

微服务之间到底该怎么互相证明“我是谁、我能干什么”？本文借 AWS STS 的思路，拆开临时凭证的门道，对比 JWT+OIDC 与 AWS 式 AssumeRole 两条路线，并给出可以直接跑起来的最小实现。