常见认证信息的传递方式

常见认证信息的传递方式

在 HTTP 请求中，认证信息（如 Token、API Key、用户名密码等）的传递位置由接口的设计规范决定，但常见的传递方式有以下几类。调试时需严格按照接口文档的要求放置，否则会导致认证失败（如 401 错误）。以下是最常见的位置和示例：

HTTP 头部（Request Headers）是传递认证信息的最推荐位置，尤其是敏感信息（如 Token）。优点是：

Bearer Token（最常用）

用于 OAuth2、JWT 等场景，格式为：
复制代码
```
Authorization: Bearer <你的Token>
```
示例：
复制代码
```
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.ABC...
```
Basic 认证（用户名+密码）

用于基础身份验证，格式为：
复制代码
```
Authorization: Basic <Base64编码的"用户名:密码">
```
示例：

用户名 admin，密码 123456，则编码后为 Basic YWRtaW46MTIzNDU2（YWRtaW46MTIzNDU2 是 admin:123456 的 Base64 结果）。
自定义头部（非标准，但常见）

部分接口会自定义头部传递认证信息，例如：
复制代码
```
X-API-Key: <你的API Key>
```
或
复制代码
```
Token: <你的Token>
```

将认证信息直接拼接在 URL 的查询参数中（即 ?key=value 部分）。缺点是参数会暴露在 URL 中，可能被日志、代理服务器记录，安全性较差，仅适用于非敏感场景或临时测试。

API Key 直接传参

接口要求通过 key 或 api_key 参数传递：
复制代码
```
POST /api/endpoint?api_key=your_api_key_here
```
Token 直接传参

部分简单接口可能允许通过 token 参数传递：
复制代码
```
POST /api/submit?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
```

POST 请求的请求体（Body）通常用于传递业务数据（如表单、JSON），但少数接口可能要求将认证信息放在 Body 中（需接口文档明确说明）。

表单数据（Form Data）

认证信息与业务数据一起以 application/x-www-form-urlencoded 格式传递：
复制代码
```
Content-Type: application/x-www-form-urlencoded

username=admin&password=123456&action=submit
```

JSON 数据

认证信息嵌入 JSON 体中（需接口文档指定字段名）：

复制代码

Content-Type: application/json

{
  "auth": {
    "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
  },
  "data": { "key": "value" }
}

对于传统的 Session-Cookie 认证 （如 Web 应用的登录状态），服务器会在用户登录后通过 Set-Cookie 头返回一个 session_id，后续请求会自动携带该 Cookie（由浏览器或 HTTP 客户端管理）。

极少数接口可能使用非标准方式传递认证信息，例如：

认证信息的传递位置完全由接口设计决定，以上只是常见方式。调试前务必查阅接口文档，明确以下几点：

总结 ：认证信息最标准的位置是 Authorization 请求头（如 Bearer Token、Basic Auth），其次是 URL 查询参数（需注意安全），少数情况在请求体或 Cookie 中。调试时优先核对接口文档，再检查实际请求的位置是否匹配。