Nginx网关统一校验JWT Token需依托OpenResty+lua-resty-jwt实现签名、exp/nbf及自定义声明校验，透传可信用户信息至后端，并安全管理密钥、禁用下游重复鉴权。

通过Nginx网关统一校验JWT Token，核心在于利用nginx-jwt模块或Lua脚本（如lua-resty-jwt）在请求入口层完成解析、签名验证和声明检查，避免每个后端服务重复实现鉴权逻辑。

选择合适的技术方案

Nginx原生不支持JWT解析，需借助扩展能力：

• 推荐使用OpenResty + lua-resty-jwt：功能完整、社区活跃、可灵活校验iss、exp、aud、scope等字段，支持RSA/ECDSA/HMAC等多种签名算法；
• 轻量场景可用nginx-jwt模块（C模块），但仅支持HMAC-SHA256且维护较弱，适合固定密钥、简单校验的内部系统；
• 避免用纯Nginx变量+map匹配token字段——无法验证签名，存在严重安全风险。

配置JWT校验逻辑（以OpenResty为例）

在nginx.conf的http块中加载Lua库，并在需要保护的location中嵌入校验代码：

• 从Authorization: Bearer 头提取token，空或格式错误直接返回401；
• 调用jwt:verify_jwt_obj()验证签名、过期时间（exp）、生效时间（nbf）；
• 可选检查自定义claim，例如require_role == "admin"，不满足则返回403；
• 校验通过后，将用户ID、角色等信息通过ngx.var注入到请求变量，供后端服务读取（如$jwt_uid）。

密钥与公钥的安全管理

签名密钥不能硬编码在配置中：

• HMAC密钥建议通过环境变量注入，或由Consul/Vault动态拉取；
• RSA/ECDSA使用公钥验签，Nginx只需持有公钥文件（PEM格式），私钥严格保留在认证服务端；
• 公钥更新时，配合lua_code_cache off（开发）或热重载机制（生产），避免重启Nginx。

与后端服务协同的关键细节

网关层完成鉴权后，需确保下游服务信任并复用结果：

• 透传可信字段：将解析出的sub、roles等写入Proxy-Header（如X-User-ID、X-Roles），后端直接使用，不再解析token；
• 禁用后端JWT中间件：避免重复校验导致性能浪费和逻辑冲突；
• 错误响应标准化：Nginx统一返回401 Unauthorized（token缺失/无效）或403 Forbidden（权限不足），便于前端统一处理。

不复杂但容易忽略：务必开启proxy_set_header X-Forwarded-For $remote_addr等基础头，确保后端日志和限流能识别真实客户端。整个链路中，Nginx是可信边界，其后的服务应默认信任它传递的用户身份。