PASETO是替代JWT的更安全无状态凭证，通过强制版本与用途（如v2.local/v2.public）、禁用算法协商、杜绝alg=none攻击、要求显式时效校验等设计，解决JWT的密钥混淆、签名误判、时间漂移等问题。
Paseto 在 Go 云原生多层微服务中不是“穿透 Token”，而是替代 JWT 的更安全、语义更清晰的无状态凭证载体；它不解决网络穿透，但能避免 JWT 常见的 alg=none、密钥混淆、时间漂移误判等问题。
为什么不用 JWT 而选 Paseto
Paseto（Platform-Agnostic SEcurity TOkens）明确区分本地（v2.local）和公钥（v2.public）两种模式，强制约定加密/签名语义，不支持可协商算法——这直接堵死了 alg: none 攻击、HS256 密钥被当公钥用等 JWT 实际线上事故高发点。
在多层微服务间传递身份时，常见错误是：上游服务用 HS256 签发 JWT，下游服务错误地用 RS256 公钥验签，或因时钟未同步导致 exp 拒绝合法请求。Paseto 的 v2.local（对称加密+认证）天然规避跨服务密钥复用风险，v2.public 则要求显式指定公钥，无算法协商环节。
- 不兼容 JWT 库（如
github.com/golang-jwt/jwt/v5）——必须换用github.com/paseto-standard/paseto -
v2.local需共享密钥，适合可信内网微服务链路（如 Service Mesh 内部） -
v2.public适合边界网关（API Gateway）签发，后端服务只持公钥验签，无需密钥分发 - Paseto 默认不带
iat/nbf/exp字段，需手动添加并校验——这是约束，不是缺陷；防止开发者依赖默认行为而忽略时效逻辑
Go 中生成与解析 v2.local Paseto（内网服务间透传）
适用于 Istio/Linkerd 等 service mesh 已保障传输安全的场景，Token 仅用于服务间身份声明，不暴露给终端用户。
立即学习“go语言免费学习笔记（深入）”；
生成示例：
package main
import (
"time"
"github.com/paseto-standard/paseto"
"golang.org/x/crypto/chacha20poly1305"
)
func issueLocalToken(userID string, issuer string) (string, error) {
token := paseto.NewToken()
token.Set("user_id", userID)
token.Set("iss", issuer)
token.Set("exp", time.Now().Add(2*time.Hour).Unix()) // 必须显式设 exp 并后续校验
bKey, _ := chacha20poly1305.GenerateKey() // 实际应从环境变量或 KMS 获取
return token.Encrypt(bKey, nil) // v2.local 加密结果
}
解析与校验关键点：
- 必须调用
token.ExpireTime()并比对系统时间，Paseto 不自动拒绝过期 token - 解密密钥必须与加密时完全一致，且不能复用为其他用途（如数据库加密密钥）
- 不建议在
v2.local中嵌入敏感字段（如权限列表），因为对称加密密钥一旦泄露，所有 token 可被解密
Go 中使用 v2.public Paseto（网关签发 + 多服务验签）
典型结构：API Gateway（签发）→ Auth Service（可选）→ Order Service / User Service（只验签）。
签发侧（网关）：
privKey, _ := paseto.GenerateV2AsymmetricKey()
token := paseto.NewToken()
token.Set("user_id", "u_123")
token.Set("scope", []string{"order:read", "user:profile"})
token.Set("exp", time.Now().Add(1*time.Hour).Unix())
signed, _ := token.Sign(privKey, nil) // v2.public 签名
验签侧（任意下游服务）：
- 只持有公钥副本（
pubKey := privKey.Public()），永不接触私钥 - 必须检查
token.ExpireTime()和token.Issuer()，Paseto 不做任何隐式校验 - 若需验证 scope，应提取
token.String("scope")后自行做字符串切片匹配，不要依赖库自动授权 - 公钥应通过 ConfigMap 或 Vault 注入，禁止硬编码或从文件读取未校验的 PEM
多层透传时最容易漏掉的三个校验点
Token 在 API Gateway → AuthZ Middleware → Business Service 多层流转时，每层都可能成为校验盲区：
- 中间层（如 AuthZ 中间件）只做基础验签，却把原始 token 原样透传给业务层，导致业务层误以为“已校验完毕”而跳过
exp检查 - 服务间通过 HTTP Header 透传时，未统一约定 header 名（如混用
X-Auth-Token/Authorization: Bearer ...），下游解析失败静默降级为匿名用户 - 日志打点时直接打印完整 token（尤其
v2.local），密钥泄露后所有历史 token 可被批量解密——应只记录 token ID（如token.ID()）或哈希摘要
真正麻烦的不是生成或解析，而是每一层都得主动、显式、独立地完成时间校验和字段白名单检查。Paseto 把“安全责任”推给了开发者，而不是藏在库的默认行为里。
