Go JWT 验证为什么不能只看 exp：签名算法、issuer 与时钟偏差核对

接口已经检查了 JWT 的 exp，却仍然出现“过期令牌能进业务”或“测试环境全部 401”的问题，通常不是时间字段本身出问题，而是大家误把“字段里有exp值”当成了“凭证完全可信”。exp 只表示有效期范围，完全不能证明签发者身份、签名算法合法性和接收方本身符合预期。

Go 服务验 JWT 时，先限制允许的签名算法白名单，再完成签名校验；随后核对 issuer、audience 和时间相关字段，最后把不同失败原因按安全分类记录下来。只看 exp，最多只完成了整套校验里的极小一部分。

先把 JWT 当成需要逐环节验真的实体凭证

JWT 是三段用点号连接的字符串：头部、Claims 和签名。前两段可以被任意方明文读取，能读出来完全不代表内容可信；整套校验的信任边界严格卡住在签名验证和服务端预设的硬约束环节。

这也是为什么“解析成功”不等于“鉴权成功”。解析器可能已经自动把 exp 转成了可读时间，但调用方还要额外确认签名确实来自预期密钥，并且令牌的 iss、aud 和当前运行的服务完全匹配。

第一关：绝对不要让令牌自己决定签名算法

在 github.com/golang-jwt/jwt/v5 中，解析回调要同时完成密钥选择和算法限制两个逻辑。下面的示例只接受HS256算法，并且不会把完整令牌写入日志产生泄露风险。

var verifyKey = []byte("replace-with-a-secret-from-kms")

func parseAccessToken(raw string) (*jwt.Token, error) {
    return jwt.Parse(raw, func(token *jwt.Token) (any, error) {
        if token.Method != jwt.SigningMethodHS256 {
            return nil, errors.New("unexpected signing algorithm")
        }
        return verifyKey, nil
    }, jwt.WithValidMethods([]string{"HS256"}))
}

这里有两层防护：回调里的类型比对逻辑让密钥选择不会接受意外的算法，WithValidMethods 又把允许的算法列表明确传入解析器做二次校验。如果项目使用RS256非对称签名，要改为只允许RS256算法，从预先配置的密钥集合按 kid 选择对应公钥；不要图省事写出支持所有算法、默认全放行的逻辑。

为什么不能直接读取Header里的alg字段直接用

alg 只是令牌携带的一段声明，服务端只能把它当成普通输入参数处理，绝对不能当成校验策略直接采信。服务端的允许算法列表、密钥来源和密钥用途必须完全来自配置或者提前写死的代码契约。算法不匹配的情况下，要在进入后续业务处理之前直接终止请求流程。

第二关：issuer、audience 和时间字段要一起校验

签名正确只说明“持有对应私钥的签发方确实签过这段内容”，完全不说明这枚令牌就是发给当前服务的。多环境、多租户或者多套API共用同一套身份中心的场景下，iss 和 aud 是防止不同业务之间令牌串用的核心约束。

type AccessClaims struct {
    Tenant string `json:"tenant"`
    jwt.RegisteredClaims
}

func parseClaims(raw string) (*AccessClaims, error) {
    claims := &AccessClaims{}
    token, err := jwt.ParseWithClaims(raw, claims, func(token *jwt.Token) (any, error) {
        if token.Method != jwt.SigningMethodHS256 {
            return nil, errors.New("unexpected signing algorithm")
        }
        return verifyKey, nil
    },
        jwt.WithValidMethods([]string{"HS256"}),
        jwt.WithIssuer("https://id.example.test"),
        jwt.WithAudience("orders-api"),
    )
    if err != nil || !token.Valid {
        return nil, errors.New("invalid access token")
    }
    return claims, nil
}

RegisteredClaims 包含 iss、aud、exp、nbf 等标准字段。服务端应该把预期的issuer和audience作为部署配置注入，绝对不能从请求参数或者令牌本身动态推导出来。

时钟偏差场景该怎么合理处理

容器节点、虚拟机和身份服务的系统时间偶尔会出现毫秒到秒级的小偏差。可以在解析器配置中给出很小的leeway时间窗口，但是不要设置几分钟甚至更长的宽窗口来掩盖底层时间同步没做好的问题。测试用例要覆盖刚过期、还没到生效时间 nbf、以及允许偏差内外的所有边界场景。

失败日志只留下排查需要的最小证据

鉴权失败的时候，建议把返回结果分成算法不允许、签名无效、issuer不匹配、audience不匹配、令牌已过期和令牌尚未生效几个类别。对外接口可以统一返回401状态码，对内通过request_id和失败分类快速定位具体问题。

func auditTokenFailure(ctx context.Context, reason string) {
    slog.WarnContext(ctx, "access token rejected", "reason", reason)
}

// 不记录 raw token、Authorization 请求头和完整 claims。
func authorize(raw string) error {
    _, err := parseClaims(raw)
    if err != nil {
        auditTokenFailure(context.Background(), "claims_or_signature_check")
        return errors.New("unauthorized")
    }
    return nil
}

日志脱敏不是把所有信息都删掉不留痕迹。保留失败类别、服务名、运行环境、request_id和请求时间，足够支撑大部分排查场景；把完整Token、用户隐私字段和密钥标识的敏感部分留在日志里，反而会扩大数据泄露的事故影响面。

用四组边界测试确认校验顺序完全符合预期

单元测试至少要覆盖四类输入场景：合法正常令牌、头部算法被替换的恶意令牌、issuer或者audience配置错误的令牌、刚好卡在时间边界的令牌。测试的重点不是重复测第三方JWT库本身的功能，而是确认你在服务里写的配置确实正确传入了解析器。

func TestParseClaimsRejectsWrongAudience(t *testing.T) {
    raw := issueTestToken(t, "other-api", time.Now().Add(5*time.Minute))
    _, err := parseClaims(raw)
    if err == nil {
        t.Fatal("expected audience mismatch")
    }
}

联调阶段还要额外验证密钥轮换逻辑：旧密钥在过渡窗口内是否仍然可以正常验签，新密钥发布之后是否能直接校验新生成的令牌，未知的 kid 是否能快速失败拒绝请求。如果使用RS256非对称签名，公钥缓存也要配套做好刷新和降级回退的策略。

常见问题

exp字段缺失时，JWT 还能正常接受吗？

是否接受完全取决于提前约定的服务契约。对于普通访问令牌通常建议强制要求exp字段；如果业务确实需要长期有效的凭证，也应该单独使用不同的令牌类型和独立的校验规则，不能默默把exp缺失当成永不过期默认放行。

issuer 和 audience 哪个更重要？

两者解决的是完全不同的问题：issuer约束令牌的签发者身份，audience约束令牌的合法使用对象。服务边界清晰的场景下应该同时校验两者，不能因为当前身份中心只有一个固定issuer就省掉audience的校验逻辑。

只用 HTTPS 还需要验证签名吗？

需要。HTTPS保护的是整条传输链路的安全，JWT签名保护的是令牌内容本身和签发者身份约束；两者处在不同的协议层，完全不能互相替代。

测试环境总是报 token not valid 该怎么排查？

先把返回的失败类别拆分出来，再逐一核对issuer、audience、节点系统时间和允许的算法列表。不要直接把校验的时间窗口随便放大，先确认容器时钟和部署配置和预期值是否一致。

把鉴权检查收口成一条可复查的固定规则

一套实用的校验顺序是：固定允许的算法列表和密钥来源，先验证签名合法性；核对issuer与audience是否符合预期；校验exp、nbf等所有时间字段；最后只提取业务侧真正需要用到的Claims字段。这样哪怕后续某个Claims被意外篡改，前面设置的信任边界也不会被直接跳过。

上线前可以把允许的算法、issuer、audience、允许的时间偏差、密钥轮换规则和日志落盘字段统一整理进配置检查表，用错误输入批量跑一次回归测试。鉴权相关的代码逻辑不需要写很长，但每个默认值都值得明确显式写出来，避免后续默认逻辑变更带来安全漏洞。