Basic Auth Header 生成器 - Authorization 请求头在线生成

根据用户名和密码生成 HTTP Basic Authorization 请求头，帮助排查 Base64 编码、401 鉴权失败和 cURL 请求格式；敏感凭据请使用脱敏样本。

功能特点

  • 把 username:password 精确编码为 Basic Authorization 请求头
  • 按第一个冒号组合用户名和密码，保留密码中的后续字符
  • 展示可复制的 Header 形式，便于对照 cURL 与接口调试工具

使用方法

  1. 使用虚构用户名和密码生成 Header，并确认目标服务的 Basic Auth 解析规则
  2. 核对 Authorization 前缀和 Base64 输出，不把编码结果当作加密
  3. 只在 HTTPS 测试接口使用，并从终端历史和日志中移除真实凭据

示例输入

  • 接口调试请求头

    username: demo
password: s3cret

    输出 Authorization: Basic ...，可粘贴到 Postman、cURL 或 fetch headers。

  • 密码包含冒号

    username: alice
password: p@ss:word

    生成器会把完整的 username:password 编码；服务端是否把后续冒号保留在密码中，要按目标实现确认。

  • 非 ASCII 凭据

    username: 用户
password: 密码

    当前生成器先按 UTF-8 编码 username:password，再生成 Base64；服务端必须使用相同字符编码解释结果。

  • 空凭据边界

    username：空
password：空

    生成器不会阻止空字符串，会按 : 编码为 Basic Og==；真实接口是否允许空凭据必须由服务端策略拒绝。

示例输出

  • 接口调试请求头

    Authorization: Basic ZGVtbzpzM2NyZXQ=

  • 密码包含冒号

    Authorization: Basic YWxpY2U6cEBzczp3b3Jk

  • 非 ASCII 凭据

    Authorization: Basic 55So5oi3OuWvhueggQ==

  • 空凭据边界

    Authorization: Basic Og==（空 username:password；实际服务端应拒绝）

常见错误

  • Basic Auth 只是 Base64 编码，不是加密，必须配合 HTTPS 使用。
  • 用户名或密码里包含冒号时容易解析歧义，应确认服务端的处理规则。
  • 复制 Header 时漏掉 Basic 前缀，会导致服务端返回 401。

适用场景

  • HTTP 接口联调
  • 网关鉴权排查
  • 文档示例生成
  • cURL 请求补全

实操检查

  • 验证固定 Header 输出

    固定输入：username `tom`、password `secret`。步骤：打开 Basic Auth，填写两个输入框并点击“生成 Basic Auth”。预期结果：只读输出为 `Authorization: Basic dG9tOnNlY3JldA==`。失败判断：前缀缺失、Base64 值不同，或输出仍为空。

  • 验证空密码仍保留分隔符

    固定输入：username `tom`、password 为空。步骤：生成 Header，并将 Base64 部分按 UTF-8 解码核对。预期结果：Header 的编码内容对应 `tom:`，而不是只编码 `tom`。失败判断：解码后没有末尾冒号，或页面抛出不必要的空密码错误。

页面专属核验

使用前与操作中

  • 先明确页面生成的是 `Authorization: Basic` 请求头：实现将 `username:password` 做 Base64 编码，不是加密、哈希或签名，真实请求必须使用 HTTPS。
  • 用虚构凭据检查目标服务的字符集和代理转发规则；用户名与密码之间只由工具加入一个冒号，密码中后续冒号仍属于密码内容。
  • 页面本地生成并不等于凭据安全；不要粘贴生产密码，复制后检查终端历史、浏览器扩展、代理日志和请求记录不会保存完整 Header。

结果出来后

  • 把输出中的 Base64 部分解码后，是否精确得到预期的 `username:password`，且前缀确实是 `Authorization: Basic`？
  • 用户名或密码包含 Unicode、空格或密码内冒号时，接收端是否按同一字符集和第一个分隔冒号解析？
  • 请求是否通过 HTTPS 发送，并已在服务端、反向代理和 cURL 中分别确认认证失败是凭据问题而不是 Header 被丢弃？

相关工具

  • 文本编码转换：统一转换 Base64、Hex、Binary、Unicode Escape、UTF-8 Hex、ASCII、HTML Entity 和 Morse
  • HTTP Headers 解析：解析 HTTP Headers，并用 AI 分析认证方式、风险和 API 调试线索
  • HTTP Request / cURL Builder：从方法、URL、Headers 和 Body 生成 cURL，并用 AI 分析 API 请求和代码转换
  • HTTP 状态码：查询 HTTP 状态码含义、分类和常见排查方向

工具边界

  • 工具只负责生成 Header，不验证账号是否存在、权限是否正确或服务端是否接受该认证。
  • Base64 结果包含凭据结构，复制、分享和下载前必须脱敏；不要把真实密码放入公开链接或日志。

与相似工具的区别

  • 文本编码转换：Basic Auth 会按 username:password 组合凭据并添加 Authorization 前缀；通用 Base64 转换不会自动拼接 username:password，也不处理认证请求头语义。

安全与兼容性

  • Basic Auth 凭据只是可逆的 Base64 编码，只能通过 HTTPS 传输；HTTP 明文连接会暴露用户名和密码。
  • 不要把真实 Authorization Header 放进 URL、浏览器历史、日志或工单；排查时应替换凭据并在泄露后立即轮换密码。
  • 用户名包含冒号时无法按首个冒号无歧义解析；非 ASCII 凭据还要确认客户端与服务端采用相同字符编码。

下一步排查

  1. 用 Headers 工具核对 Authorization 是否完整，再用 cURL 或 API 客户端复现请求。
  2. 收到 401/403 时分别检查凭据有效性、权限范围、服务端策略和代理改写。
  3. 生产环境优先考虑短期 Token、密钥轮换和 HTTPS，不要长期复用静态密码。

常见问题

Basic Auth 是加密吗？

不是。它通常只是把用户名和密码拼接后进行 Base64 编码，必须通过 HTTPS 传输，并配合服务端认证和权限控制。

为什么服务端返回 401？

先确认 Authorization 前缀、Base64 内容、用户名密码、请求域名和代理是否正确，再查看服务端鉴权日志。