verify_ssl 与 Token 验证的区别详解

verify_ssl 与 Token 验证的区别详解

在开发或调用 API 接口时，我们经常会遇到两个看似相关但实际上作用完全不同的安全参数：

• 传输层的 verify_ssl
• 应用层的 Authorization（最常见是 Bearer Token）

虽然它们都与"安全"有关，但它们所处的层级、验证对象、目的完全不同。本文通过对比、代码示例以及生活化类比，带你一次搞懂它们之间的差异与联系。

---

概念对比

项目	主体	作用	目的
verify_ssl=True/False	客户端验证服务器	校验 SSL 证书是否有效（是否过期、是否受信任、是否匹配域名）	确保服务器是"真正的"服务器，防止中间人攻击
Authorization: Bearer	服务器验证客户端	检查请求方是否携带合法凭证（OAuth Token、API-Key、JWT 等）	确保调用方有权限访问资源，防止未授权访问

🔍 更深入一点的对比

verify_ssl 的本质（客户端验证）

• TLS/SSL 层的验证
• 验证的是服务端证书
• 目的是 防止连接到伪造服务器
• 默认行为：开启验证（即 verify_ssl=True)

# 类似于 curl -k 的效果（关闭验证）
verify_ssl=False

Authorization Token 的本质（服务器验证）

• 应用层的认证机制（HTTP Header）
• 验证的是客户端的身份
• 一般用于 API 鉴权、用户身份验证
• 常见类型：
  • Bearer （OAuth 2.0 / JWT）
  • Basic （用户名密码）
  • ApiKey （自定义）

---

什么是 verify_ssl？

verify_ssl 是客户端在使用 HTTPS 协议时，是否校验服务器 SSL 证书 的开关。

• ✅ verify_ssl=True（默认）：严格校验证书合法性
• ❌ verify_ssl=False：跳过证书验证（⚠️ 不安全，仅限本地测试）

示例（aiohttp）：

async with aiohttp.ClientSession() as session:
    async with session.post(
        url,
        headers=headers,
        json=xxxx,
        verify_ssl=False      # 跳过验证，容易被中间人攻击
    ) as resp:
        data = await resp.json()

三、结论

✅ verify_ssl：客户端验证服务器身份（是否可信）

✅ Authorization Token：服务器验证客户端身份（是否有权限）