版本说明

Basic Auth 是 Nginx 内置模块，任意版本可用；nginx-ldap-auth 与 OIDC 反代方案需要额外组件，版本要求见对应小节。

给一个内部服务（监控面板、管理后台）加访问控制，常见诉求是"不想让服务本身实现登录逻辑，交给反向代理层统一挡一道"。Nginx 层面能做到的方案有三档，复杂度和适用场景依次递进：

1. 档位一：HTTP Basic Auth（最简单，几分钟搞定）

生成密码文件：

printf "admin:$(openssl passwd -apr1)" > /etc/nginx/conf.d/htpasswd
# 命令会提示交互式输入密码

openssl passwd -apr1 生成 Apache MD5 变体的密码哈希，Nginx 的 auth_basic_user_file 兼容这种格式；admin 换成你要用的用户名，文件里每行一个"用户名:密码哈希"。

配置 Nginx：

location /internal-monitor/ {
    auth_basic "Restricted Access";
    auth_basic_user_file /etc/nginx/conf.d/htpasswd;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_pass http://backend:19999/;
}

auth_basic 的字符串会显示在浏览器弹出的登录框标题上，auth_basic_user_file 指向刚才生成的密码文件。

验证：访问该路径应弹出浏览器原生认证框；curl -u admin:密码 http://host/internal-monitor/ 能正常拿到响应，不带认证信息则返回 401。

坑：Basic Auth 是明文（Base64 编码不是加密）在 HTTP 头里传输密码，必须配合 HTTPS 使用，纯 HTTP 下等于裸奔；而且它是"一份密码文件对应若干共享账号"，没有细粒度的用户管理、审计日志、密码策略，只适合团队规模小、临时挡一道的场景。

2. 档位二：LDAP 认证（对接企业统一账号）

团队规模大了之后，共享密码文件很快就管不过来——离职要删账号、新人要开账号，Basic Auth 的密码文件没有任何自动化空间。这时候把认证对接到企业已有的 LDAP/AD 账号体系更合理：让员工用平时登录邮箱/OA 的同一套账号访问内部服务，权限统一由 LDAP 侧管理。

Nginx 原生不支持 LDAP，需要借助 nginx-ldap-auth 这类第三方认证子请求模块（auth_request 指令 + 一个独立的 LDAP 认证代理进程）：

location /internal-monitor/ {
    auth_request /auth-proxy;
    error_page 401 = @error401;
    proxy_pass http://backend:19999/;
}

location = /auth-proxy {
    internal;
    proxy_pass http://ldap-auth-daemon:8888;
    proxy_set_header Content-Length "";
    proxy_pass_request_body off;
}

location @error401 {
    return 302 /login;
}

auth_request 指令会先向 /auth-proxy 发一个子请求，只关心它返回的状态码——2xx 放行原请求，401/403 则按 error_page 的配置处理（通常跳转到登录页）。真正跟 LDAP 服务器交互（BIND 认证）的逻辑在 ldap-auth-daemon 这个独立进程里完成，Nginx 本身不直接说 LDAP 协议。

坑：auth_request 子请求走的是独立的一次 HTTP 请求，不会自动带上原请求的 body，proxy_pass_request_body off + 清空 Content-Length 是标准写法，忘记这两行可能导致认证代理收到异常请求。

3. 档位三：OIDC/SSO（统一单点登录，最重的方案）

组织内已经有统一身份提供商（如 Okta、Keycloak、企业自建 IdP）时，最终形态是把 Nginx 前面的所有内部服务都接入同一个 OIDC 单点登录，用户登录一次，所有内部服务免登录跳转。这一档通常不是纯 Nginx 配置能搞定的，而是引入专门的反向代理网关（如 oauth2-proxy）：

location /internal-monitor/ {
    auth_request /oauth2/auth;
    error_page 401 = /oauth2/sign_in;
    proxy_pass http://backend:19999/;
}

location /oauth2/ {
    proxy_pass http://oauth2-proxy:4180;
}

oauth2-proxy 独立部署，负责跟 OIDC IdP 完成标准的 OAuth2/OIDC 授权码流程，Nginx 这一层依然是熟悉的 auth_request 套路，只是认证代理换成了理解 OIDC 协议的组件。

适用场景：需要统一审计、多因素认证（MFA）、跟公司现有 SSO 体系集成时选这一档；小团队、单一内部服务没有必要上这一整套。

4. 三档怎么选

	Basic Auth	LDAP	OIDC/SSO
搭建复杂度	一条命令+几行配置	需要额外部署认证代理进程	需要独立网关组件+对接 IdP
账号管理	手动维护密码文件	复用企业已有目录	复用企业已有 IdP
适合场景	临时/小团队挡一道	团队有 LDAP/AD	组织级统一 SSO
前提要求	必须配 HTTPS	需要可访问的 LDAP 服务	需要 OIDC IdP

5. 可复用要点

1. 认证方案的复杂度应该匹配团队规模和已有基础设施，不要为一个内部小工具直接上 SSO。
2. Basic Auth 必须搭配 HTTPS，否则密码等于明文传输。
3. LDAP/OIDC 这两档在 Nginx 层的共同套路都是 auth_request 子请求 + 独立认证代理进程，Nginx 本身不直接实现认证协议。