OAuth2 是一种授权框架，用于让用户在不暴露密码的前提下授权第三方应用访问其在某服务上的资源。JWT（JSON Web Token）是自包含的 Token 格式，常用于 API 鉴权：服务端签发后，客户端在请求中携带，服务端验证签名即可识别身份。本文介绍 OAuth2 授权码模式、JWT 结构与实践、刷新 Token 机制及安全要点。
一、OAuth2 与 JWT 为何常用
OAuth2 被广泛用于「用某某账号登录」；JWT 无状态、易水平扩展，适合 API 与微服务。二者常结合：OAuth2 完成授权后颁发 JWT 作为访问凭证。
| 概念 | 说明 |
|---|---|
| OAuth2 | 授权框架：谁在什么范围授权给谁 |
| JWT | Token 格式：Header.Payload.Signature，自包含声明 |
| OpenID Connect | 在 OAuth2 上扩展的身份层，提供用户信息 |
数据来源：IETF OAuth 2.0、JWT RFC（综合整理）。
二、OAuth2 授权码模式
授权码模式是 Web 应用最推荐的 OAuth2 流程：用户被重定向到授权服务器登录并授权，授权服务器重定向回应用并带上一次性 code，应用后端用 code 换 access_token 与可选 refresh_token。code 仅用一次、不暴露给浏览器直接使用，安全性高。
2.1 四类角色
Resource Owner 即用户；Client 即第三方应用；Authorization Server 签发 Token；Resource Server 为受保护 API，校验 Token 后返回资源。
| 角色 | 说明 |
|---|---|
| Resource Owner | 用户 |
| Client | 应用 |
| Authorization Server | 发 Token |
| Resource Server | 受保护 API，验证 Token |
三、JWT 结构与实践
JWT 由三部分 Base64URL 编码后用点连接：Header（算法等）、Payload（声明，如 sub、exp、iat）、Signature（签名防篡改）。签名算法常用 HS256（对称）或 RS256（非对称）。Payload 不应放敏感信息。建议：access_token 短期（如 15 分钟），refresh_token 长期且单次使用后轮换。
3.1 常用声明
sub 为主体（如用户 ID）；exp 为过期时间；iat 为签发时间；iss 为签发者；aud 为受众。
四、安全实践
Token 存储：Web 前端建议 HttpOnly Cookie 或内存，避免 localStorage 以减少 XSS 窃取风险。传输：全程 HTTPS。校验：验证签名、exp、iss、aud。刷新：refresh_token 单次使用、轮换。可参考《API 安全设计最佳实践》。
五、落地要素权重
基于实际认证项目经验，以下要素的影响程度（相对权重，满分 100）：
说明：权重基于 OAuth2/JWT 项目实践归纳，仅供参考。
六、小结
OAuth2 负责授权流程，JWT 负责 Token 格式与校验。落地时注重 Token 存储、传输、签名校验与刷新策略。若需 Serverless API 鉴权，可阅读《Serverless 架构实践指南》；若需 API 整体安全设计，可参考《API 安全设计最佳实践》。