Nginx 不执行基于身份的权限控制，仅作为安全网关完成 HTTPS 终止、身份可信传递（如 Basic Auth/mTLS/JWT 透传）和粗粒度拦截，真正的权限决策必须由后端应用实现。
Nginx 本身不执行基于身份的权限控制（如角色判断、权限校验），但它可以作为安全网关，把用户身份信息可靠地传递给后端，并在前置环节完成基础认证和加密保障。真正的权限决策必须由后端应用完成。配置的关键是：HTTPS 终止 + 身份可信传递 + 可选的粗粒度拦截。
1. 配置 HTTPS 基础加密
这是所有身份相关控制的前提。确保流量在到达 Nginx 前已被加密，防止凭据泄露。
- 获取合法证书（如 Let’s Encrypt 的 fullchain.pem 和 privkey.pem），存放到安全路径（如
/etc/nginx/ssl/） - 在 server 块中监听 443 端口，启用 SSL，并指定证书路径：
server {
listen 443 ssl;
server_name example.com;
<pre class='brush:php;toolbar:false;'>ssl_certificate /etc/nginx/ssl/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/privkey.pem;
# 推荐启用现代 TLS 协议和强加密套件
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;}
同时建议添加 HTTP → HTTPS 强制跳转：
server {
listen 80;
server_name example.com;
return 301 https://$server_name$request_uri;
}
2. 支持并透传用户身份信息
Nginx 不解析 JWT 或校验 OIDC Token，但可配合以下方式将可信身份头转发给后端：
-
Basic Auth 前置认证：用
auth_basic+auth_basic_user_file做简单用户名密码校验，再通过auth_request模块调用内部认证服务（如 OAuth2 Proxy）生成用户头 -
客户端证书认证（mTLS）：启用
ssl_client_certificate和ssl_verify_client on，Nginx 解析证书中 CN 或 SAN 字段，用$ssl_client_s_dn或$ssl_client_i_dn提取标识，再通过proxy_set_header X-User-DN $ssl_client_s_dn透传 -
JWT 透传（推荐）：若前端已在请求头携带
Authorization: Bearer <token>，Nginx 默认原样转发；如需校验签名，需借助 lua-resty-jwt 或 OpenResty 扩展
3. 实现粗粒度访问控制（非 RBAC，但可辅助权限）
可在 Nginx 层做轻量级拦截，减少无效请求打到后端：
- 按请求路径限制访问人群，例如只允许特定用户访问管理接口：
location /admin/ {
auth_basic "Admin Area";
auth_basic_user_file /etc/nginx/.htpasswd-admin;
}
- 结合变量做条件路由或拒绝，例如根据透传的
X-User-Role头做简单分流（注意：该头必须由可信上游设置，不可由客户端伪造）：
if ($http_x_user_role != "admin") {
return 403;
}
⚠️ 注意：if 在 location 中有局限性，更稳妥的方式是用 map 指令预定义变量，再配合 deny/return 控制。
4. 后端才是权限控制的核心
Nginx 只负责“把人带到门口并说明他是谁”，进门后的操作全由后端决定：
- 后端收到
X-User-ID、X-User-Email、X-User-Roles等头后，应重新校验其完整性（如验证 JWT 签名、比对 session） - 基于角色（如 admin/student）、资源（如 /api/orders）、操作（如 GET/DELETE）执行 ABAC 或 RBAC 判断
- Nginx 不应信任任何客户端直接提交的角色字段；所有关键权限头必须由 Nginx 在认证成功后注入，或由可信认证服务注入
