支付鉴权方案介绍

前后端交互中的鉴权是确保请求来源合法、身份可信、权限合适的关键手段。不同系统架构和业务类型下，使用的鉴权方式略有不同，但主要可分为以下几类：

---

✅ 一、前后端交互常见的鉴权方式概览

鉴权方式	优点	缺点	适用场景
Cookie + Session	简单、成熟，服务端易控制	不适合跨域，状态保存在服务端	单体应用、同源系统
Token（如 JWT）	前后端分离，支持跨域、无状态	Token泄露风险高，无法主动注销	前后端分离、移动端、小程序等
OAuth2.0	第三方授权、通用性强	实现复杂，需要依赖认证中心	登录中心、SSO、平台类系统
HMAC 签名校验	防止参数被篡改、请求可验签	实现复杂，需要密钥管理	支付接口、开放 API、回调接口
mTLS 双向证书认证	安全等级高，基于证书机制	成本高、接入难度大	高安全场景：银行、政府 API 等

---

🔐 二、主流 Token 鉴权方案（JWT 为例）

🧩 步骤流程：

1. 前端用户登录，提交账号密码。

2. 后端校验成功后，生成一个签名的 JWT，返回给前端。

3. 前端将 JWT 存储在 localStorage 或 cookie 中。

4. 每次请求时，前端将 JWT 放入 Authorization 请求头中：

   Authorization: Bearer <token>
   

5. 后端中间件解析 JWT，验证签名、过期时间、权限等。

✅ JWT结构：

Header.Payload.Signature

• Header：令牌类型 & 签名算法
• Payload：用户信息、权限、过期时间
• Signature：基于密钥和算法签名，用于防篡改

JWT示例：

{"alg": "HS256","typ": "JWT"
}
.
{"userId": "123456","role": "admin","exp": 1722659999
}
.
[签名]

---

🛡️ 三、签名鉴权（HMAC，常用于开放接口）

适用于防止接口被非法调用（如支付网关、Webhook 回调、对接三方系统）。

签名参数设计（推荐）：

timestamp=1722640000
nonce=abc123
appKey=xxxxxx
sign=SHA256(appKey + timestamp + nonce + secret)

• timestamp：防止重放攻击
• nonce：随机字符串
• sign：前后用相同规则生成并比对，确保请求未被篡改

验签流程：

1. 后端校验时间戳是否超时（如 ±5分钟）
2. 校验签名是否匹配
3. 校验 appKey 是否合法

---

🔒 四、会话 Session 鉴权（适用于同源系统）

传统服务端鉴权方式，用户登录后后端创建一个 session：

1. 后端创建 session 并保存在内存/Redis 中；
2. 将 sessionId 写入 cookie；
3. 浏览器后续请求自动携带 cookie；
4. 服务端根据 sessionId 取出用户信息。

缺点：不适合多服务、前后端分离或跨域请求。

---

🧠 五、OAuth 2.0 鉴权（适用于登录中心）

适用于多个子系统共享登录状态、或者通过微信/支付宝/Google 登录等场景。

核心角色：

角色	描述
Resource Owner	资源拥有者（用户）
Client	第三方应用（前端系统）
Authorization Server	鉴权服务器，发放 access_token
Resource Server	接口服务器（API网关、后端）

流程简要：

1. Client 请求授权码（code）
2. Server 校验并返回 code
3. Client 使用 code 换取 access_token
4. 后续请求带上 access_token 调用资源服务器

---

🚨 六、安全建议

• Token 设置有效期（如 30分钟），支持刷新机制（Refresh Token）
• Https 全站启用，防止中间人劫持
• 前端避免将 Token 存 localStorage（防 XSS），可考虑 httpOnly Cookie
• 签名请求加入防重放机制（timestamp + nonce）
• 实现统一中间件处理鉴权逻辑，避免每个接口都重复

---

🏁 总结：推荐鉴权方式选型

场景	推荐鉴权方式
前后端分离 + 多端支持	JWT + Bearer Token
开放平台接口 + 安全要求高	HMAC签名或OAuth2.0
单体系统，部署在同一域名下	Session + Cookie
银行/支付类接口	mTLS + 签名校验
小程序/移动端 + 登录态	JWT + Refresh机制