网站安全API接口鉴权设计OAuth2与JWT安全存储

网站安全API接口鉴权的核心就是解决"谁能访问、访问什么、访问多久"这三个问题，而OAuth2协议配合JWT令牌机制是目前业界最主流的解决方案。具体来说，OAuth2负责授权流程——让第三方应用在不暴露用户密码的前提下获得访问权限，JWT负责令牌承载——把用户身份、权限、过期时间等信息打包成一个自包含的安全令牌。但很多团队在落地时犯的最大错误是：把JWT直接存localStorage，或者把refresh_token明文放前端，这等于把钥匙插在门上。真正安全的做法是JWT存HttpOnly Cookie，refresh_token走服务端轮换机制，密钥用非对称加密算法管理。

下面我从协议选型、令牌设计、存储策略、密钥管理、常见漏洞五个维度，把这套体系彻底讲透。

传统的Basic Auth和API Key方案有明显缺陷：Basic Auth每次请求都要传用户名密码，Key一旦泄露就无法撤销。OAuth2的优势在于引入了"授权码模式"和"令牌轮换"机制。授权码模式下，客户端先拿一个临时code，再用code换access_token和refresh_token，整个过程密码不经过前端。即使code被截获，没有client_secret也换不到令牌。对于单页应用（SPA）和移动端，推荐使用PKCE扩展，它用动态生成的code_verifier替代了固定的client_secret，进一步降低了泄露风险。

OAuth2有四种授权模式：授权码、隐式、密码、客户端凭证。对于Web应用和移动端，授权码+PKCE是最佳选择；对于机器对机器通信，客户端凭证模式更合适；隐式模式已经被官方废弃，不要再用。

JWT由三部分组成：Header、Payload、Signature，用点号连接。Header声明算法和类型，Payload存放声明信息，Signature用密钥签名防篡改。很多开发者只关注签名算法选HS256还是RS256，却忽略了Payload里放什么、不放什么。

安全的Payload应该只放必要信息：sub（用户ID）、iat（签发时间）、exp（过期时间）、scope（权限范围）、jti（唯一令牌ID）。绝对不要放密码、手机号、身份证号等敏感数据，因为Payload只是Base64编码，任何人都能解码看到内容。

{
  "alg": "RS256",
  "typ": "JWT"
}

{
  "sub": "user_12345",
  "iat": 1718000000,
  "exp": 1718003600,
  "scope": "read:profile write:order",
  "jti": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
}

签名算法强烈推荐RS256（非对称）而非HS256（对称）。HS256要求所有服务共享同一个密钥，一旦一个服务被攻破，全部服务的令牌都能伪造。RS256用私钥签名、公钥验签，授权服务器持私钥，资源服务器持公钥，即使资源服务器被入侵也无法伪造令牌。

这是最多人踩坑的环节。前端存储JWT有三种方式，安全性排序如下：HttpOnly Secure Cookie > 内存存储（变量） > localStorage/sessionStorage。

localStorage的问题是任何JavaScript代码都能读取，一旦页面存在XSS漏洞，攻击者直接拿走令牌。sessionStorage稍好但依然受XSS影响。最安全的方案是让后端通过Set-Cookie头把access_token写入HttpOnly Cookie，这样JavaScript完全无法访问，XSS也偷不走。但要注意CSRF风险，需要配合SameSite=Strict属性和CSRF Token双重防护。

后端存储refresh_token更关键。refresh_token的有效期长（通常7-30天），一旦泄露后果严重。正确做法是：refresh_token存数据库，与用户ID和设备指纹绑定，每次使用后立即轮换（生成新token、废弃旧token）。这样即使某个refresh_token被偷，攻击者用一次就失效了。

// 后端refresh_token轮换逻辑伪代码
function rotateRefreshToken(oldToken) {
  const record = db.findRefreshToken(oldToken);
  if (!record || record.revoked) throw new Error('Token invalid');
  
  // 标记旧token为已废弃
  db.revokeToken(oldToken);
  
  // 生成新token
  const newToken = generateSecureRandomToken();
  db.saveRefreshToken({
    userId: record.userId,
    token: newToken,
    deviceFingerprint: record.deviceFingerprint,
    createdAt: now(),
    expiresAt: now() + 30 * 24 * 3600
  });
  
  return newToken;
}

密钥管理是整个体系的根基。RS256的私钥必须离线生成，存储在硬件安全模块（HSM）或密钥管理服务（KMS）中，绝不能硬编码在代码里。密钥长度至少2048位，推荐4096位。定期轮换密钥是必须的，但要处理好旧密钥的过渡期——新旧公钥同时有效一段时间，避免正在使用的令牌突然验证失败。

还要警惕算法降级攻击。攻击者可能把Header里的alg改成HS256甚至none，如果后端不严格校验算法白名单，就会被绕过。后端验签时必须强制指定算法，拒绝任何非预期算法的令牌。

// Node.js验签安全示例
const jwt = require('jsonwebtoken');

function verifyToken(token) {
  const decoded = jwt.verify(token, publicKey, {
    algorithms: ['RS256'],  // 强制指定算法
    issuer: 'your-auth-server',
    audience: 'your-api',
    clockTolerance: 30      // 容忍30秒时钟偏差
  });
  return decoded;
}

另外，JWT本身无法主动失效——这是它的设计特性，不是bug。如果需要即时撤销某个令牌，必须维护一个黑名单（用Redis存jti），每次验签时额外查一次黑名单。对于高安全场景，可以缩短access_token有效期（比如15分钟），配合refresh_token轮换，把风险窗口压缩到最小。

第一，XSS导致令牌窃取。防御：Content Security Policy头、输入输出转义、不用innerHTML、HttpOnly Cookie存令牌。第二，CSRF攻击。防御：SameSite Cookie、双重提交Cookie模式、Origin头校验。第三，令牌重放攻击。防御：jti唯一ID+短期过期+黑名单机制。第四，敏感信息泄露。防御：Payload最小化原则，HTTPS全链路加密。第五，密钥泄露。防御：HSM存储、环境变量注入、代码仓库扫描排除密钥文件。

还有一个容易被忽视的点：OAuth2的scope权限设计要遵循最小权限原则。不要给客户端申请"全部权限"，而是按需申请。后端验签时必须校验scope，不能只看令牌是否有效就放行所有接口。比如一个只需要读用户信息的应用，不应该能调用写订单的接口。

一个生产级的安全鉴权架构应该是这样的：前端用授权码+PKCE获取令牌，access_token存HttpOnly Cookie（15分钟过期），refresh_token存后端数据库并绑定设备指纹；后端用RS256非对称签名，公钥分发到各微服务；所有API请求走HTTPS；引入API网关统一鉴权和限流；维护令牌黑名单处理即时撤销；定期审计和轮换密钥。这套组合拳下来，基本能覆盖绝大多数安全威胁。

最后说一句大实话：没有绝对安全的系统，只有不断提升攻击成本的系统。OAuth2+JWT不是银弹，但它是目前在安全性、扩展性、标准化之间平衡最好的方案。把每个环节的细节做到位，比追求某个"完美方案"重要得多。