HTTP 基本认证：Basic Auth 原理与实战

大家好。今天咱们聊聊 HTTP 基本认证，也就是 Basic Auth。说实话，这是最古老、最简单的身份认证方式了。我刚开始做 API 接口的时候，第一次接触的就是它。原理简单，实现也直白，但坑也不少。咱们这节课就把它的原理、编码、优缺点以及 Python 怎么实现，彻底讲清楚。

你想想看，一个客户端要向服务器发送请求，服务器怎么知道你是谁？最简单的办法就是：你每次请求都带上用户名和密码。Basic Auth 的核心思想就是这么朴素。

它是怎么工作的？

客户端在 HTTP 请求头里加一个字段：Authorization。这个字段的值是 Basic 加上一个 Base64 编码的字符串。字符串的内容是 username:password。就这么简单。

比如，用户名是 admin，密码是 123456。我拼接成 admin:123456，然后做 Base64 编码，得到 YWRtaW46MTIzNDU2。最终请求头就是：

Authorization: Basic YWRtaW46MTIzNDU2

服务器收到后，取出 Authorization 头的值，去掉前面的 Basic ，然后 Base64 解码，得到用户名和密码，再跟数据库里的一比对。一致就放行，不一致就返回 401 状态码。

小提示： 401 响应会带上 WWW-Authenticate: Basic realm="..." 头。这个 realm 是个提示信息，告诉客户端需要认证，并且属于哪个保护域。很多浏览器看到这个就会自动弹出登录框。

我记刚入行那会，写一个内部监控系统，用的就是 Basic Auth。后端没做任何加密，因为是内网，想着也没事。结果有一次安全审计，被运维同事狠狠批了一顿。嗯，这里要注意：Basic Auth 本身不提供加密。Base64 只是编码，不是加密。任何人只要截获你的 HTTP 请求，都能轻松解码出用户名和密码。

Base64 编码，到底是什么？

你可能听过 Base64，但它不是用来加密的。它只是把二进制数据转换成文本的一种编码方式。为什么用它？因为在 HTTP 协议里，很多字符是不能直接传输的。Base64 就用 64 个可打印字符（A-Z, a-z, 0-9, +, /）来表示任意二进制数据。

你想想看，admin:123456 这一串包含冒号，直接放在 HTTP 头里可能会被解析错。Base64 编码后，全是字母和数字，安全。但注意，我说的“安全”是指传输安全，不是加密安全。

Base64 的编码过程很简单，就是将原始数据每 3 个字节一组，转换成 4 个 Base64 字符。如果最后不够 3 个字节，就用 = 填充。比如，admin:123456 编码结果是 YWRtaW46MTIzNDU2，长度刚好是 16，没有填充符。但如果字符串是 a:b，编码后是 YTpi，你注意到结尾没有 =，因为它是 3 字节一组，刚刚好。

我之前有个项目，移动端传图片 Base64，结果图片太大，导致 HTTP 请求体特别臃肿。Base64 会让数据膨胀约 33%，这也是它的一个缺点。但在 Basic Auth 里，用户名字典串长度很小，这个缺点可以忽略。

优缺点分析，不吹不黑

任何技术都有适用场景。我个人的经验是：Basic Auth 适合用于临时测试、内部简单脚本或低安全性场景。生产环境，尤其是暴露在公网的服务，我建议慎用。

维度 优点 缺点
实现成本 极低。客户端和服务器只需几行代码。 无状态维护，每次请求都带凭证。
兼容性 几乎所有 HTTP 客户端、浏览器都支持。 无法细化权限，只能按用户整体认证。
安全性 配合 HTTPS 使用，可以保证传输加密。 明文传输风险大。即使 HTTPS，凭证也在服务器端明文存储（除非你额外做哈希）。
易用性 调试非常方便。用 curl 命令一行搞定。 客户端需持续保存用户凭证（如密码），容易泄漏。
关键结论： Basic Auth + HTTPS 是它的最佳实践。只用 Basic Auth 不加 HTTPS，等于裸奔。我建议任何时候都不要在非 HTTPS 的请求里使用 Basic Auth。

Python 实现示例，实战走一波

我个人习惯用 Python 的 requests 库。它内置了对 Basic Auth 的支持，用 auth 参数就行。咱们写一个最简单的客户端和服务端示例。

客户端示例

用 requests 发起带 Basic Auth 的 GET 请求。代码很简单，也容易看懂。

import requests

# 直接用 auth 参数，requests 会自动帮你生成 Authorization 头
response = requests.get('https://httpbin.org/basic-auth/admin/123456',
                        auth=('admin', '123456'))

print(response.status_code)   # 200 表示成功
print(response.json())         # 返回 {"authenticated": true, "user": "admin"}

为什么我说它简单？因为 auth 参数可以接受一个元组。它会自动拼接、编码、设置请求头。你根本不需要手动调用 Base64。

手动实现 Base64 编码

如果你想看底层是怎么做的，我也可以拆开给你看。Python 标准库的 base64 模块可以直接用。

import base64

username = 'admin'
password = '123456'
credentials = f"{username}:{password}"
# 字符串转字节，然后编码
encoded_credentials = base64.b64encode(credentials.encode()).decode()
print(encoded_credentials)  # YWRtaW46MTIzNDU2

# 构造完整的 Authorization 头
auth_header = f"Basic {encoded_credentials}"
print(auth_header)          # Basic YWRtaW46MTIzNDU2

注意：b64encode 返回的是字节，需要 decode 成字符串才能拼接。我曾经踩过这个坑——直接拼接字节和字符串，导致报错。

服务端验证（Flask 示例）

虽然课程主代码会在后面统一展开，但这里我简单写一个 Flask 验证逻辑，帮你理解服务端是怎么做的。

from flask import Flask, request, jsonify
import base64

app = Flask(__name__)

# 假设数据库里就这一个用户
VALID_USER = 'admin'
VALID_PASS = '123456'

@app.route('/protected')
def protected():
    auth_header = request.headers.get('Authorization')
    if not auth_header or not auth_header.startswith('Basic '):
        return jsonify({"error": "Missing or invalid auth"}), 401

    # 去掉 "Basic " 前缀
    encoded = auth_header.split(' ')[-1]
    # Base64 解码
    decoded = base64.b64decode(encoded).decode()
    username, password = decoded.split(':', 1)

    if username == VALID_USER and password == VALID_PASS:
        return jsonify({"message": "Hello, admin!"})
    else:
        return jsonify({"error": "Invalid credentials"}), 401

if __name__ == '__main__':
    app.run(debug=True)
踩坑提醒： 生产环境里，密码不能像上面那样明文存储在变量里。我之前接手过一个遗留项目，密码写在配置文件里，还是明文，被安全组勒令整改。正确的做法是存密码的哈希值，比如 bcrypt。即便数据库泄露，攻击者也拿不到原始密码。

核心流程图：看懂 Basic Auth 全链路

下面的 SVG 图展示了客户端和服务端之间的完整交互过程。我把它分成三个主要阶段：发起请求、服务端验证、返回响应。你一看就明白。

HTTP Basic Auth 完整流程 客户端 服务端 GET /protected Authorization: Basic xxx 服务端处理阶段 1. 提取 Authorization 头 2. Base64 解码 3. 比对用户名+密码 验证失败 验证成功 401 Unauthorized WWW-Authenticate: Basic 200 OK + 响应数据 注意：整个过程必须配合 HTTPS，否则 Authorization 头会被明文窃取 Base64 只负责编码，不负责加密，任何人都能直接解码。

这张图把前面讲的内容串起来了。客户端带着编码后的凭证，服务端解码验证，最后返回成功或失败。记住，核心是 Base64 不是加密，安全要依赖 HTTPS。

几点避坑建议

  • 不要在 URL 里传凭证。 比如 https://admin:123456@example.com。虽然某些浏览器支持，但这种方式不安全，而且容易在日志里暴露。
  • 注意编码问题。 如果用户名或密码里有非 ASCII 字符（比如中文），必须先转成 UTF-8 字节，再做 Base64。很多老系统在这上面栽跟头。
  • 服务端不要存储明文密码。 即便是 Basic Auth，也要对密码做哈希（如 bcrypt）后再比对。我见过有人直接把密码原文存数据库，这是非常危险的行为。

好了，关于 HTTP Basic Auth 的内容就是这么多了。下面咱们进入更高级的认证方式——摘要认证和 认证。但那是后面的事了。今天先把基础打牢。

← 上一章 📖 返回目录 下一章 →