HTTP请求头中的Authorization

当使用HTTP请求中的Authorization头时，表示传入的是认证信息。具体的认证类型由凭证前缀指明。以下是Authorization头中常见的几种认证机制：

基本认证（Basic Authentication）:
bash 复制代码
```
Authorization: Basic base64(用户名:密码)
```
这是最常见的一种，涉及将用户名和密码以base64格式编码并与请求一起发送。需要注意，Basic 后面有空格, 未使用HTTPS时基本认证不够安全。实际使用例子，比如：
bash 复制代码
```
curl -u "admin:P@88w0rd" -H "Accept: application/json" http://localhost:8090/api/v1alpha1/users
```
curl -u "username:password" 就相当于在请求的请求头中添加key为Authorization，value为 admin:P@88w0rd，这是一种认证方式。对账号密码进行base64编码之后
bash 复制代码
```
echo -n "admin:P@88w0rd" | base64
```
得到：YWRtaW46UEA4OHcwcmQ= ，上方的curl也可以写成：
bash 复制代码
```
curl -H "Authorization: Basic YWRtaW46UEA4OHcwcmQ=" -H "Accept:  application/json" http://localhost:8090/api/v1alpha1/users
```
Bearer令牌（Bearer Token）:
makefile 复制代码
```
Authorization: Bearer <令牌>
```
这通常与OAuth 2.0一起使用。<令牌>通常是通过单独的认证过程获取的长寿命访问令牌。
摘要认证（Digest Authentication）:
ini 复制代码
```
Authorization: Digest username="用户名", realm="领域", nonce="随机数", uri="URI", response="响应", opaque="opaque", qop=auth, nc=00000001, cnonce="cnonce"
```
摘要认证比基本认证更安全，涉及挑战-响应机制来验证客户端。挑战-响应机制（Challenge-Response Mechanism，在这种机制中，服务器通过向客户端发送一个随机的挑战（challenge），并期望客户端使用其凭据（通常是密码）生成一个对应的响应（response）来证明其身份，服务端收到响应后验证身份）
API密钥（API Key）:
makefile 复制代码
```
Authorization: ApiKey <API密钥>
```
API密钥通常用于API请求中的身份验证。密钥包含在Authorization头中。
Bearer令牌（JWT）:
makefile 复制代码
```
Authorization: Bearer eyJhbGciOiJIUzI1NiIsIn...
```
JSON Web Tokens（JWT）通常在现代身份验证系统中使用。令牌包含在Bearer方案中。
自定义方案（Custom Schemes）: 一些应用程序或服务可能定义了自己的自定义认证方案。例如：
makefile 复制代码
```
Authorization: CustomScheme 自定义数据
```

以上的使用的scheme，如Basic，Bearer,Digest,ApiKey是约定俗成的，大家都这样使用，具体认证类型取决于服务器的要求和实现的协议，针对自己的业务也可以自定义scheme。也可以参考正在与之交互的服务或API的文档，以确定Authorization头的正确格式。