如何使用JWT保障API安全，防范仿冒网站？

针对你提出的「仅用JWT确保只有授权客户端可调用API、拒绝未授权请求」的问题，核心解决思路是从JWT本身的设计、传输安全、后端校验逻辑三个维度入手，以下是具体落地方案：

1. 在JWT Payload中嵌入客户端专属标识 #

• 签发JWT时，在Payload中加入唯一的客户端身份字段（比如client_id），这个标识可以是前端应用的注册ID（如Web应用的域名哈希、原生APP的包名哈希），且仅对合法注册的客户端分发对应标识的JWT。
• 后端校验JWT时，除了常规的签名验证、过期时间检查，必须额外校验client_id是否在预设的授权客户端列表中，不匹配则直接拒绝请求。

2. 强化JWT的签名与加密机制 #

• 禁用无签名算法：绝对不能使用none算法，优先采用非对称加密签名（如RS256），私钥严格保存在后端服务中，公钥用于验证JWT签名。这样攻击者即便窃取到JWT，也无法篡改Payload中的client_id等关键字段。
• 敏感场景用JWE加密：如果JWT包含用户隐私数据，使用JWE（JSON Web Encryption）对整个令牌加密，确保只有后端能解密获取Payload内容，避免中间攻击者窃取客户端标识等信息。

3. 配合CORS策略限制跨域请求 #

• 后端配置严格的CORS规则，仅允许授权的前端域名发起跨域API请求（比如只放行https://your-official-app.com）。
• 注意：CORS是浏览器层面的限制，无法阻止非浏览器客户端的请求，但能有效拦截仿冒网站在浏览器环境中发起的跨域API调用。

4. 短时效JWT + 绑定客户端的刷新令牌 #

• 将JWT的有效期设置为15分钟以内的短时长，同时签发一个绑定client_id的长时效刷新令牌。客户端需要用刷新令牌向后端申请新的JWT。
• 后端校验刷新令牌时，除了验证令牌本身的有效性，还要检查其绑定的client_id是否合法，避免非法客户端利用窃取的刷新令牌获取新JWT。

5. 辅助校验请求来源上下文 #

• Web应用场景：后端可校验请求的Origin或Referer头，辅助判断请求是否来自授权域名（注意：这两个头可被篡改，仅作为补充校验手段）。
• 原生APP场景：在JWT Payload中加入设备指纹信息（如设备ID、系统版本的哈希值），后端校验时匹配设备信息，防止其他设备复用同一JWT。

6. 针对仿冒网站的额外防护 #

• 强制HTTPS传输：所有JWT的传输必须通过HTTPS，同时启用HSTS协议，防止浏览器降级到HTTP导致令牌被窃取。
• 安全存储JWT：前端将JWT存储在带有HttpOnly、Secure、SameSite=Strict属性的Cookie中，禁止通过JavaScript读取，防范XSS攻击窃取令牌。
• 启用CSRF防护：前端发起请求时在请求头中携带CSRF令牌，后端校验该令牌与Cookie中的CSRF令牌是否一致，防止仿冒网站通过CSRF发起带合法JWT的请求。

内容的提问来源于stack exchange，提问作者LevoDoe