Token主流认证方式及其应用场景

Ray.1998

于 2025-01-11 22:10:27 发布

阅读量951

点赞数 19

分类专栏：随便放吧文章标签： java

本文链接：https://blog.csdn.net/ray_paul1/article/details/145083392

版权

3 篇文章

订阅专栏

1. Basic Authentication（基础认证）

格式：Authorization: Basic <Base64(username:password)>
说明：
- 基础认证是一种简单的认证方式，客户端在请求头中直接发送用户名和密码（经过 Base64 编码）。
使用场景：
- 开发环境中快速测试。
- 低安全需求或内部服务的简单认证。
缺点：
- 用户名和密码容易被窃取（即使经过 Base64 编码，也很容易被解码）。
- 每次请求都发送用户名和密码，安全性较低。
示例：
```
Authorization: Basic YWRtaW46cGFzc3dvcmQ=
```
（YWRtaW46cGFzc3dvcmQ= 是 admin:password 的 Base64 编码）

格式：Authorization: Bearer <token>
说明：
- Bearer Token 是 OAuth 2.0 中常用的一种认证方式，强调 "持票者" 即可访问资源，无需其他凭据。
- Token 通常是由后端生成并颁发的，例如 JWT（JSON Web Token）。
使用场景：
- 前后端分离的 Web 应用。
- 需要较高安全性的系统。
优点：
- 不用每次发送用户名和密码。
- Token 可以设计为有有效期，增强安全性。

示例：

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

格式：Authorization: Digest <digest-string>
说明：
- Digest Authentication 是 HTTP 认证的一种方式，利用摘要算法（如 MD5）对用户名、密码和请求数据生成摘要信息，避免直接传输明文密码。
使用场景：
- 比 Basic Authentication 更安全的简单认证场景。
缺点：
- 实现较复杂。
- 安全性较现代 Token 方案（如 Bearer Token）低。

示例：

Authorization: Digest username="user",
              realm="example.com",
              uri="/protected",
              response="5e98362d1c..."

格式：
- 通常直接附加到 URL、请求头或请求体中：
  - URL 参数：https://api.example.com/resource?api_key=123456
  - HTTP 头：Authorization: Api-Key 123456
  - 请求体：{ "api_key": "123456" }
说明：
- API Key 是一种简单的身份验证方法，常用于访问公开的 API 服务。
- API Key 通常由服务提供方生成，分发给客户端。
使用场景：
- 第三方服务访问（如 Google Maps API）。
- 应用程序间通信。
优点：
- 实现简单。
缺点：
- 如果 API Key 泄露，就可能被滥用。
示例：
```
Authorization: Api-Key 123456
```

示例：

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

格式：
- 通常通过 Cookie 传递：
```
Cookie: session_id=abc123xyz
```
说明：
- 传统的身份验证方式，用户登录后，服务器生成一个唯一的会话 ID 并存储在服务器端。
- 客户端通过 Cookie 在后续请求中携带这个 Session ID。
使用场景：
- 传统 Web 应用（如 JSP、PHP）。
优点：
- 实现简单。
缺点：
- 需要服务器存储会话状态（占用内存）。
- 分布式系统中扩展性差。
示例：
```
Cookie: session_id=1234567890
```

认证方式	优点	缺点	场景
Bearer Token	安全、支持无状态认证	Token 泄露后可能被滥用	前后端分离、分布式系统
Basic Auth	简单易用	安全性差，每次请求都带用户名密码	开发测试
Digest Auth	密码不以明文传输	实现复杂、现代场景较少用	较低安全需求的服务
API Key	简单易用	Key 泄露后无法撤销	访问第三方服务（如 API）
JWT	支持无状态认证，包含用户信息	Token 长度较长，可能增加网络开销	前后端分离、移动应用
Session ID	传统 Web 应用的核心方案	需服务器存储会话状态，扩展性差	传统服务器端渲染