什么是 HTTP 基本认证？
HTTP 基本认证是最简单的 HTTP 认证形式。客户端在每个请求中发送用户名和密码，这些凭据经过 Base64 编码后放在 Authorization 请求头中。尽管简单，它被广泛用于 API 访问、保护开发环境以及快速认证需求。
基本认证的工作原理
认证流程：
- 客户端发送不带凭据的请求
- 服务器响应
401 Unauthorized并附带WWW-Authenticate: Basic realm="Description" - 客户端发送带有
Authorization: Basic [base64(username:password)]的请求 - 服务器解码并验证凭据
- 如果有效，请求继续；如果无效，返回另一个 401
Base64 编码示例：
username: admin
password: secret123
组合: admin:secret123
Base64: YWRtaW46c2VjcmV0MTIz
请求头: Authorization: Basic YWRtaW46c2VjcmV0MTIz
Authorization 请求头格式
每个基本认证请求携带一个请求头，格式固定不变：
Authorization: Basic <base64(username:password)>
三个关键部分：请求头名称 Authorization，方案关键字 Basic（大写 B，后跟一个空格），以及 Base64 令牌。以用户名 admin 和密码 secret123 的完整示例：
GET /api/orders HTTP/1.1
Host: api.example.com
Authorization: Basic YWRtaW46c2VjcmV0MTIz
导致 401 响应的常见原因是请求头格式错误——缺少 Basic 前缀、在严格服务器上使用小写 basic，或令牌周围有多余空格。根据 RFC 7617，方案名称不区分大小写，但大多数客户端按所示发送 Basic。
凭据编码步骤
令牌通过三个确定性步骤构建：
- 用单个冒号连接用户名和密码：
admin:secret123。用户名不能包含冒号；密码可以。 - 将该字符串视为 UTF-8 字节。
- 对字节进行 Base64 编码 →
YWRtaW46c2VjcmV0MTIz。
在命令行上：
printf '%s' 'admin:secret123' | base64
# YWRtaW46c2VjcmV0MTIz
使用 printf（或 echo -n）而不是 echo——尾随换行符会改变令牌，产生服务器将拒绝的凭据。
如何解码基本认证请求头
解码是精确的逆过程：取出 Basic 之后的值，进行 Base64 解码，得到 username:password。
echo 'YWRtaW46c2VjcmV0MTIz' | base64 --decode
# admin:secret123
因为任何人都可以一步完成此操作，被截获的 Authorization 请求头会完全暴露凭据。解码用于调试——验证客户端发送的内容是否符合预期——绝不是安全边界。上面的生成器包含一个解码模式，用于粘贴现有请求头。
URL 中的基本认证
凭据可以直接嵌入 URL，使用 user:password@host 格式：
https://admin:secret123@api.example.com/data
客户端会拆分出凭据并将其转换为 Authorization: Basic 请求头。在依赖它之前需要注意三点：
- 现代浏览器会从地址栏中剥离凭据并警告嵌入密码，因为该模式在钓鱼攻击中被广泛滥用。
- 浏览器的
fetch()API 会忽略 URL 中的凭据——请显式设置请求头。 - URL 中的凭据会泄露到浏览器历史记录、服务器访问日志和
Referer请求头中。对于快速本地测试之外的任何场景，请改用请求头发送。
安全考虑
Base64 不是加密
Base64 编码是可逆的——它不提供任何安全性。任何截获 Authorization 请求头的人都可以立即解码。始终将 HTTPS 与基本认证一起使用，以防止凭据被截获。
没有 HTTPS，基本认证凭据会以明文形式通过网络发送。这就是为什么在本地开发之外的任何场景中，通过 HTTP 使用基本认证被认为是不安全的。
凭据暴露
Authorization 请求头经常被 Web 服务器、代理和 CDN 记录。确保您的日志配置排除敏感请求头或对凭据值进行脱敏处理。
无登出机制
基本认证没有内置登出功能。浏览器会在会话期间缓存凭据。清除浏览器缓存或关闭浏览器才能“登出”。
凭据管理
由于凭据随每个请求发送，必须小心存储和传输：
- 服务器端存储哈希版本（bcrypt）
- 定期轮换凭据
- 使用每个客户端凭据（每个 API 消费者使用不同密码）
何时使用基本认证
适当的使用场景：
- 受 VPN 或防火墙保护的内部工具
- 内部服务的简单 API 认证
- 开发和预发布环境访问控制
- 低敏感度资源的快速保护
- 机器对机器 API 访问（服务账户）
不适用于：
- 消费者应用程序中的最终用户认证
- 没有 HTTPS 可访问的资源
- 需要更复杂认证的高安全系统
- 需要会话管理或 SSO 的系统
基本认证实践
Nginx 配置
server {
auth_basic "Restricted Area";
auth_basic_user_file /etc/nginx/.htpasswd;
}
生成 htpasswd 文件：
htpasswd -c /etc/nginx/.htpasswd username
Apache 配置
<Directory "/var/www/html/admin">
AuthType Basic
AuthName "Admin Area"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user
</Directory>
使用 curl
curl -u username:password https://api.example.com/endpoint
# 或使用显式请求头
curl -H "Authorization: Basic $(echo -n 'user:pass' | base64)" https://api.example.com/endpoint
JavaScript Fetch API
const credentials = btoa('username:password');
fetch('https://api.example.com/data', {
headers: {
'Authorization': `Basic ${credentials}`
}
});
Python requests
import requests
response = requests.get(
'https://api.example.com/data',
auth=('username', 'password')
)
使用基本认证生成器
我们的工具：
- 输入用户名和密码
- 自动生成 Base64 凭据
- 显示完整的 Authorization 请求头，可直接复制
- 解码模式——粘贴现有基本认证请求头以查看凭据
- curl 命令——生成包含认证的完整 curl 命令
用于在 API 测试期间快速生成认证请求头、调试认证问题以及为文档示例生成凭据。
常见问题
基本认证请求头的格式是什么？
Authorization: Basic <token>，其中 <token> 是 username:password 的 Base64 编码。对于 admin:secret123，请求头为 Authorization: Basic YWRtaW46c2VjcmV0MTIz。
如何解码基本认证请求头？
移除 Basic 前缀，对剩余部分进行 Base64 解码。echo 'YWRtaW46c2VjcmV0MTIz' | base64 --decode 返回 admin:secret123。不需要密钥或密码——Base64 任何人都可以逆转。
基本认证安全吗？ 仅在 HTTPS 下安全。凭据是编码而非加密的，因此在普通 HTTP 下它们以明文形式传输。使用 TLS 时，请求头在传输中得到保护，这使得基本认证对于内部 API 和机器对机器调用是可接受的。
基本授权和 Bearer 授权有什么区别？
基本认证在每个请求中发送可重用的 username:password 凭据。Bearer 认证发送一个令牌（通常是 JWT 或 OAuth 访问令牌），该令牌可以过期并携带作用域。Bearer 适用于面向用户的应用程序；基本认证对于服务账户和内部工具最简单。
我可以在 URL 中放置基本认证凭据吗？
可以，格式为 https://user:pass@host，curl 等工具会将其转换为请求头。但浏览器会警告并经常忽略它，而且凭据会泄露到日志和历史记录中——因此请求头形式更安全。
为什么密码正确时基本认证仍然失败？
常见原因是使用 echo 而不是 echo -n/printf 导致的额外换行符、缺少 Basic 前缀，或用户名中包含冒号。使用 printf '%s' 'user:pass' | base64 重新编码并比较令牌。