· 全部指南
HTTP Basic 认证
HTTP Basic 认证在每次请求的 Authorization 头中携带凭据，格式为对 username:password 做 Base64 编码。Base64 是编码而非加密——拦截到该头的任何人都能立刻解码。因此 Basic 仅适用于 HTTPS，且应视为轻量门禁，而非完整身份体系。
开发者常在 OAuth 尚未接入前，用 Basic 保护预发仪表盘、内部 Swagger UI 或临时演示。basic-auth-generator 可生成正确的 Authorization: Basic ... 头与示例 curl，无需手算 Base64 即可验证 Nginx 或 Apache 配置。示例：用户名 dev、密码 staging-2024 会产出可粘贴到 Postman 或 curl 的头，用于确认 401 与 200 行为。
预发保护推荐流程：用 password-generator 生成凭据 → 为服务器配置生成哈希（见 htpasswd 节）→ 部署 Nginx auth_basic → 用 basic-auth-generator 的 curl 输出测试 → 把共享密码记入团队 vault 而非 Slack。承包商离职或预发 URL 泄露时轮换凭据。常见错误：在明文 HTTP 上使用 Basic、预发复用生产密码、在前端 JavaScript 中硬编码凭据。
面向用户的生产应用应优先 OAuth 2.0、OpenID Connect 或带 secure 标志的 session cookie。Basic 缺少细粒度 scope、刷新令牌与集中吊销——只能改密码或不能。
htpasswd 与 Nginx/Apache
Nginx 与 Apache 将 Basic 用户存放在 htpasswd 文件：每行 username:hashed_password。服务端比对哈希登录，文件中绝不应出现明文密码。htpasswd-generator 可生成适用于 Nginx auth_basic_user_file 或 Apache AuthUserFile 的 Apache 兼容行。
选用强算法：bcrypt（$2y$...）或 apr1（$apr1$...）。避免 legacy crypt()，切勿使用可逆加密。Nginx 片段示例：
auth_basic "Staging Area";
auth_basic_user_file /etc/nginx/.htpasswd;
流程：打开 htpasswd-generator，输入用户名及经 password-strength 校验的强密码 → 复制生成行到 .htpasswd → nginx -s reload → 用 basic-auth-generator 验证。轮换密码时先追加新行、reload、确认可访问，再删旧行，避免过渡期全员锁死。
常见错误：把 .htpasswd 提交进 Git（哈希可离线破解）；文件权限过宽（chmod 644 导致全局可读）；混用当前 server 构建不支持的 htpasswd 格式。
与 JWT 的区别
Basic 与 JWT 解决不同问题。Basic 在密码变更前每次请求发送相同凭据，无过期、无 audience、无法单独吊销某次会话而不影响所有用户。
JWT 访问令牌短效、可签名，可携带 scope（read:reports、admin:users）。OAuth 流程中刷新令牌可轮换。集群内服务间调用时，mTLS 或服务网格身份往往优于经日志传播的 Basic 或 bearer JWT。
静态预发站需要五分钟围栏时用 Basic；移动客户端、SPA 与第三方集成需要可吊销、可审计的程序化访问时用 JWT。basic-auth-generator 适合调试前者；Towalles 的 JWT 工具适合检视后者——勿把二者当成可互换的「认证头」。
安全清单
把 Basic 当作分层防御的一环，而非唯一一层。强制 TLS 1.2+ 并禁用弱 cipher。结合 IP 白名单或 VPN，使公网仅凭凭据不足以进入。用 password-generator 生成十六字符以上随机密码，并经 password-strength 拒绝字典词。
切勿记录 Authorization 头——访问日志、APM 与错误上报常误采头部。在日志流水线中脱敏。在 Towalles 本地生成 htpasswd 行与测试头；勿把生产密码粘贴到不可信网站或工单。凭据泄露即视为 compromized：立即轮换、查访问日志，并反思预发数据是否本应脱敏。