学习笔记 常用鉴权方式总结

前言

在渗透测试的过程中，遇到各种系统，通常都有各自的鉴权方式，经过网上搜索整理以及AI，大体上分为这么几个方面，总结成一篇文章以便随时查看。

OAuth 2.0

原理概述

OAuth 2.0 是一种开放标准的授权协议，主要用于为第三方应用提供有限的访问权限。它基于令牌（Token）机制，允许用户在不向第三方应用提供自己的用户名和密码的情况下，授权第三方应用访问其受保护的资源。整个流程涉及四个角色：资源所有者（通常是用户）、客户端（第三方应用）、授权服务器和资源服务器。主要流程包括用户授权、客户端获取访问令牌、客户端使用令牌访问资源。

适用场景

• 第三方应用集成：当需要让第三方应用访问用户在另一个服务上的资源时，OAuth 2.0 是理想的选择。例如，许多网站允许用户使用 Google、Facebook 等账号登录，这些网站通过 OAuth 2.0 协议获取用户的基本信息。第三方应用无需知道用户在 Google 或 Facebook 的账号密码，只需获得用户授权的访问令牌，就可以访问用户授权的资源。
• 多平台应用：适用于具有多个客户端平台（如 Web、移动应用、桌面应用）的服务。不同平台的客户端可以通过统一的 OAuth 2.0 协议与授权服务器进行交互，获取访问令牌，从而访问受保护的资源。例如，一个社交网络服务，其 Web 端、iOS 端和 Android 端的应用都可以使用 OAuth 2.0 来实现用户授权和资源访问。

API Key

原理概述

API Key 是一种简单的鉴权方式，通常是一个由字母、数字组成的字符串。客户端在调用 API 接口时，需要在请求中携带这个 API Key，服务器通过验证 API Key 的有效性来判断请求是否合法。API Key 可以作为请求头、请求参数或者 URL 的一部分进行传递。

适用场景

• 内部系统调用：在企业内部的不同系统之间进行 API 调用时，API Key 是一种简单有效的鉴权方式。由于内部系统通常处于相对安全的网络环境中，对鉴权的复杂度要求不高。例如，企业的财务系统需要调用库存系统的 API 来获取商品库存信息，通过分配一个 API Key 给财务系统，库存系统可以验证请求的合法性。
• 公开 API 服务：对于一些公开的 API 服务，如天气查询 API、新闻资讯 API 等，API Key 可以用于统计和限制 API 的使用。服务提供商可以为不同的开发者分配不同的 API Key，并根据 API Key 来统计每个开发者的调用次数和流量，同时设置一定的使用限制，防止恶意调用。

HMAC（Hash-based Message Authentication Code）

原理概述

HMAC 是一种基于哈希算法的消息认证码，它结合了一个密钥和一个消息，通过哈希函数生成一个固定长度的认证码。客户端在发送请求时，除了携带请求数据外，还会计算一个 HMAC 值并发送给服务器。服务器使用相同的密钥和请求数据重新计算 HMAC 值，并与客户端发送的 HMAC 值进行比较。如果两个值相同，则说明请求数据在传输过程中没有被篡改，并且请求是由合法的客户端发送的。

适用场景

• 对数据完整性和安全性要求高的场景：在金融交易、敏感数据传输等场景中，需要确保数据在传输过程中不被篡改，并且能够验证请求的来源。例如，银行的支付系统在处理用户的转账请求时，使用 HMAC 来验证请求的合法性和数据的完整性。只有当服务器计算的 HMAC 值与客户端发送的 HMAC 值一致时，才会处理该转账请求。
• 防止重放攻击：HMAC 可以结合时间戳或序列号来防止重放攻击。客户端在请求中包含一个时间戳或序列号，并将其包含在 HMAC 的计算中。服务器在验证请求时，会检查时间戳是否在有效范围内或序列号是否已经使用过，从而避免攻击者重复使用之前的请求。

JWT-Token（JSON Web Token）

原理概述

JWT 是一种基于 JSON 的开放标准（RFC 7519），用于在双方之间安全传递声明信息。它由三部分组成：

1. Header：描述令牌类型（如 JWT）和签名算法（如 HMAC-SHA256 或 RSA）。
2. Payload：包含需要传递的声明信息（如用户身份、权限、有效期等）。
3. Signature：对 Header 和 Payload 的签名，通过密钥和指定算法生成，用于验证令牌的完整性和来源。

客户端在登录后，服务器生成一个 JWT 并返回给客户端。客户端在后续请求中携带此 Token（通常通过 HTTP Header Authorization: Bearer <token>）。服务器收到请求后，验证 Signature 的合法性：

• 若签名有效且令牌未过期，则信任 Payload 中的声明信息，无需查询数据库或会话状态（无状态特性）。
• 若签名无效或令牌过期，则拒绝请求。

适用场景

• 分布式系统或微服务间的身份认证：
  JWT 的无状态特性非常适合跨服务传递用户身份信息。例如，用户登录后，网关服务生成 JWT，下游服务（如订单服务、支付服务）可直接解析 Token 获取用户身份，无需频繁查询认证中心。
• 前端分离架构的权限控制：
  在单页应用（SPA）或移动端应用中，JWT 可存储用户角色和权限信息。前端可根据 Payload 中的声明动态控制界面权限（如隐藏管理员功能），后端则通过验证 Token 实现接口鉴权。
• 短期有效且需携带额外信息的场景：
  JWT 的 Payload 可自定义字段（如用户 ID、角色、权限列表），适合需要轻量级传递业务参数的场景。例如，用户发起支付请求时，JWT 中可包含用户账户和支付限额，供服务端快速验证。