auth_request|access|auth_basic比较
无论是通过access模块限制IP还是通过auth_basic模块限制用户名密码，这些都是非常简单的用户验证方式。
在生产环境当中很可能会有动态web服务器，它们通过更加复杂的用户名密码权限验证。这个时候可以通过访问nginx资源时候，先将用户的去请求传递给这样的应用服务器，根据应用服务器返回的结果再判断请求资源能不能继续执行。在access阶段有一个auth_request模块，该模块就可以完成这样的功能。
可以通过合理配置Nginx的auth_request模块来实现对敏感路径下的内容进行访问限制（通过auth_request来进行的权限限制）。该模块默认是不会编译到Nginx中的需要手动添加--with-http_auth_request_module
auth_request原理语法
原理：收到请求后，先将该请求hold住，生成子请求，子请求和该请求内容是相同的。通过反向代理技术把子请求传递给上游服务，根据上游服务的响应再来决定是否处理当前的请求。
功能：向上游的服务器转发请求，若上游服务器返回的响应码是2XX，则继续执行，若上游服务器返回的是401或者403，则将响应返回给客户端。
Syntax: auth_request uri | off; --加上url会生成一个子请求，这个子请求会访问该url，根据该url返回的结果来决定是否允许该请求向下继续执行
Default: auth_request off;
Context: http, server, location
Syntax: auth_request_set $variable value; --根据返回的结果设置变量来做进一步处理
Default: —
Context: http, server, location
举个例子如下
服务器A(192.168.179.99)，其路径/上存有敏感信息，其他路径可公开访问。
服务器B(192.168.179.100)，为认证服务器，其上部署了本项目代码。
服务器A(server1)的Nginx配置文件：
location / {
auth_request /test_auth; --生成子请求会去访问/test_auth
}
location = /test_auth{
proxy_pass http://192.168.179.100/auth_upstream; --反向代理到后端auth_upstream
proxy_pass_request_body off;
proxy_set_header X-Original-URI $request_uri;
}
[root@localhost ~]# echo "proxy back this is 192.168.179.99" > /usr/local/nginx/html/index.html --该条记录用来验证用户在后端192.168.179.100返回状态
（1）服务器B(server2)的Nginx配置文件：
server{
listen 80;
access_log logs/host.log main;
charset utf-8;
location /auth_upstream{
return 200 'auth success';
}
如果用户为合法用户：
那么服务器B将会生成session，并通过Set-cookie命令告知用户浏览器。用户通过此Cookie即可获得服务器B的认可授权。当用户通过此Cookie访问服务器B中的/auth_upstream目录时，会返回200的状态码。
（2）服务器B(server2)的Nginx配置文件：
server{
listen 80;
access_log logs/host.log main;
charset utf-8;
location /auth_upstream{
return 403 'auth success';
}
}
如果用户为非法用户：
那么服务器B将不会session，由于用户无法获得认可的Cookie，那么当用户再次访问/auth_upstream的路径时，服务器会返回403错误。
总结
以上，通过auth_request模块以及相关配置就实现了对敏感内容的访问限制。而且通过第三方的机制，也无需自己手工实现登录功能。同时，此方案可以对同一域名下的不同子域名中的内容进行访问限制。可以重复利用一个登录系统，服务于多个其他系统。（auth_request模块对于我们拥有一个统一的用户健全系统是非常有用的）