Apache APISIX JWT插件优化：在上下文中存储已验证的JWT

在微服务架构中，JSON Web Token(JWT)已成为身份验证和授权的标准方式。Apache APISIX作为高性能API网关，提供了jwt-auth插件来处理JWT验证。然而，当前实现存在一些可以优化的地方。

当前实现的问题

目前APISIX的jwt-auth插件在验证JWT后，不会将验证结果存储在请求上下文中。这导致后续插件如果需要使用JWT信息，必须重新解析令牌，造成以下问题：

1. 性能损耗：重复解析JWT增加了不必要的CPU开销
2. 代码冗余：每个需要JWT信息的插件都要实现自己的解析逻辑
3. 安全限制：无法在隐藏凭证的同时让后续插件访问JWT

优化方案

通过在jwt-auth插件中将已验证的JWT对象存储在请求上下文(ctx)中，可以带来显著改进：

function _M.rewrite(conf, ctx)
    -- 原有验证逻辑...
    
    -- 存储已验证的JWT对象
    ctx.jwt_obj = jwt_obj
end

技术优势

1. 性能提升：避免重复解析JWT，减少CPU消耗
2. 代码简化：后续插件可直接使用预解析的JWT对象
3. 安全增强：即使启用hide_credentials，后续插件仍能访问JWT
4. 一致性：所有插件使用同一份已验证的JWT数据

实际应用示例

以下是一个自定义ACL插件的示例，展示如何利用存储在上下文中的JWT：

function _M.rewrite(conf, ctx)
    if not ctx.jwt_obj then
        core.log.warn("Token对象未找到")
        return 401, {message = "请求中缺少JWT"}
    end

    local authorized = false
    local roles = ctx.jwt_obj.payload.roles

    -- 基于角色的访问控制逻辑
    for _, role in ipairs(roles) do
        if role == "admin" then
            authorized = true
            break
        end
    end

    if not authorized then
        return 403, {message = "无权访问此资源"}
    end
end

实现考量

1. 向后兼容：不影响现有插件的正常运行
2. 命名规范：使用明确的字段名(jwt_obj)避免冲突
3. 文档完善：需要更新插件文档说明这一特性
4. 性能影响：存储整个JWT对象的内存开销可以忽略不计

总结

在APISIX的jwt-auth插件中存储已验证的JWT对象是一个简单但强大的改进。它不仅提高了性能，简化了插件开发，还增强了安全性。这一优化体现了API网关设计中"解析一次，多处使用"的最佳实践，值得在APISIX的未来版本中实现。