如何在Nginx上配置认证拦截器，基于认证服务响应管控微服务访问？

这个需求刚好可以用Nginx内置的auth_request模块来解决——它的核心作用就是在放行用户的原请求前，先自动发送一个子请求到你的认证服务，根据认证服务的响应状态来决定是否允许访问目标服务。下面是完整的配置方案和关键细节：

完整Nginx配置示例 #

http {
    # 定义后端服务的集群（如果是单实例也可以直接写地址）
    upstream user_service {
        server localhost:3000; # 你的用户服务地址
    }

    upstream auth_service {
        server localhost:4000; # 你的认证服务地址
    }

    server {
        listen 80;
        server_name your-domain.com;

        # 对需要认证的路径（比如所有/user开头的请求）配置拦截
        location /user {
            # 触发认证检查，指定内部调用的认证路径
            auth_request /auth_check;

            # 认证通过后，转发原请求到用户服务
            proxy_pass http://user_service;
            # 传递原请求的关键头信息给后端服务
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;

            # 把认证服务返回的用户信息（比如用户ID）传递给后端服务
            auth_request_set $user_id $upstream_http_x_user_id;
            proxy_set_header X-User-ID $user_id;
        }

        # 内部专用的认证转发路径（外部无法直接访问）
        location = /auth_check {
            internal;
            proxy_pass http://auth_service/auth;
            # 认证一般不需要原请求的body，关掉减少开销
            proxy_pass_request_body off;
            proxy_set_header Content-Length "";
            # 把原请求的关键信息传给认证服务，用于权限判断
            proxy_set_header X-Original-URI $request_uri;
            proxy_set_header X-Original-Method $request_method;
            proxy_set_header Authorization $http_authorization; # 传递用户的token
        }

        # 认证失败的自定义响应
        error_page 401 403 /error_unauthorized;
        location = /error_unauthorized {
            return 401 '{"code":401,"msg":"未授权访问，请先登录"}';
            add_header Content-Type application/json;
        }
    }
}

关键配置解释 #

• auth_request /auth_check：这是核心指令，告诉Nginx所有匹配当前location的请求，必须先执行/auth_check这个内部请求做认证。
• internal：标记/auth_check只能被Nginx内部调用，避免外部直接访问你的认证接口，保证安全性。
• auth_request_set：用来捕获认证服务返回的响应头（比如X-User-ID），赋值给Nginx变量后，再传递给后端业务服务，这样业务服务就不用重复做认证，直接用这个用户ID即可。
• proxy_pass_request_body off：因为认证逻辑通常不需要原请求的body内容，关掉这个可以减少不必要的网络传输，提升整体性能。如果你的认证确实需要body，可以去掉这行。

你的认证服务需要实现的逻辑 #

Node.js认证服务需要处理/auth路径的请求，并基于Nginx传递的信息做判断：

1. 从请求头X-Original-URI拿到用户原本要访问的路径（比如/user/id/edit）
2. 从Authorization头获取用户的认证凭证（比如Bearer token）
3. 验证凭证有效性，确认用户身份（比如解析token、查询用户信息）
4. 检查用户是否有权限访问目标路径（比如编辑用户信息需要是本人或管理员）
5. 根据验证结果返回状态码：
   • 返回200：认证通过，Nginx会自动放行原请求
   • 返回401：用户未登录/凭证无效，Nginx返回401错误
   • 返回403：用户无权限访问该路径，Nginx返回403错误
6. 可选：返回自定义响应头（比如X-User-ID: 123），让Nginx传递给后端业务服务

注意事项 #

• 确认Nginx支持auth_request模块：执行nginx -V查看编译参数，确保包含--with-http_auth_request_module。如果没有，需要重新编译Nginx添加这个模块。
• 优化认证服务性能：因为每个请求都要经过认证服务，建议对token验证结果做缓存（比如Redis），减少数据库查询，避免认证服务成为性能瓶颈。
• 自定义错误响应：可以通过error_page指令调整401/403的返回内容，比如返回JSON格式的错误信息，方便前端统一处理。

内容的提问来源于stack exchange，提问作者Meto