直接用 jwt.encode() 和 jwt.decode() 易出错，因 pyjwt 不处理存储、刷新等逻辑，常见错误包括密钥类型混淆、未显式声明算法、忽略过期校验；正确做法是密钥转 bytes、encode 时指定 algorithm 和 exp、decode 时传 algorithms 和 verify_exp=true。
为什么直接用 jwt.encode() 和 jwt.decode() 容易出错
PyJWT 库本身不处理 token 存储、刷新、黑名单或自动注入用户上下文，裸调用 jwt.encode() 很容易忽略密钥类型（str vs bytes）、算法显式声明、过期时间校验逻辑，导致 token 永不过期或解码时抛 InvalidSignatureError。更常见的是忘记在 jwt.decode() 中传 algorithms=['HS256']，Python 3.10+ 默认禁用弱算法后直接报 InvalidAlgorithmError。
实操建议：
- 密钥统一用
os.environ.get('SECRET_KEY').encode()转为bytes，避免UnicodeEncodeError -
jwt.encode()必须显式传algorithm='HS256'，且 payload 中至少含exp（用datetime.utcnow() + timedelta(hours=1)） -
jwt.decode()必须带algorithms=['HS256']和options={'verify_exp': True}，否则过期 token 仍能解码成功
如何写一个真正可用的 @auth_required 装饰器
Flask 的装饰器要兼容函数视图和类视图方法，还要能区分 token 来源（Authorization: Bearer xxx 或 query 参数），同时不能污染原函数的 __name__ 和 __doc__。
实操建议：
- 从
request.headers.get('Authorization')提取 token，按空格分割后取第二项；没 header 就 fallback 到request.args.get('token') - 解码失败时统一返回
401 {'error': 'Invalid or expired token'}，不要暴露是签名错还是过期 - 用
functools.wraps(f)包裹内层函数，否则 Flask 路由注册会丢掉函数元信息 - 把解码后的
user_id注入g.user_id，后续视图可直接用，别塞进request对象（它不是线程安全的）
示例片段：
from functools import wraps
from flask import g, request, jsonify
import jwt
from datetime import datetime
<p>def auth_required(f):
@wraps(f)
def decorated_function(*args, *<em>kwargs):
token = None
if 'Authorization' in request.headers:
auth_header = request.headers['Authorization']
if auth_header.startswith('Bearer '):
token = auth_header[7:]
if not token:
token = request.args.get('token')
if not token:
return jsonify({'error': 'Token missing'}), 401
try:
data = jwt.decode(token, current_app.config['SECRET_KEY'],
algorithms=['HS256'], options={'verify_exp': True})
g.user_id = data['user_id']
except jwt.ExpiredSignatureError:
return jsonify({'error': 'Token expired'}), 401
except (jwt.InvalidTokenError, KeyError):
return jsonify({'error': 'Invalid token'}), 401
return f(</em>args, **kwargs)
return decorated_function
</p>
为什么不能把 JWT 存在 Cookie 里还设 HttpOnly=False
前端 JavaScript 能读取的 Cookie（即 HttpOnly=False）和 localStorage 一样面临 XSS 攻击风险——恶意脚本可直接窃取 token 并转发给攻击者服务器。而 HttpOnly=True 又导致前端无法读取 token 做自动续期或显示用户名。
实操建议：
- 登录成功后，后端只通过
set_cookie(..., httponly=True, secure=True, samesite='Lax')写一个短期 session cookie（如 15 分钟），仅用于 CSRF 防护 - JWT 本身走响应 body 返回 JSON，前端存 localStorage 或内存变量，配合
Authorizationheader 发送 - 必须配
secure=True（HTTPS only）和samesite='Lax'，否则开发环境测试时 Chrome 会静默丢弃 Cookie
刷新 Token 的关键点：为什么不能只延长 exp
单纯对旧 token 调用 jwt.encode() 并改 exp 是危险的——攻击者若截获旧 token，可无限次“续期”，等于变相永不过期。真正的刷新必须绑定设备指纹或单次使用机制。
实操建议：
- 刷新接口（如
/auth/refresh）要求客户端提交当前 token + 用户 agent + IP（服务端比对是否与登录时一致） - 签发新 token 时，在 payload 中加入
jti（JWT ID）字段，服务端维护一个 Redis 黑名单，记录已刷新的旧jti，有效期设为原 token 过期时间 + 5 分钟 - 刷新成功后，旧 token 的
jti立即加入黑名单，新 token 的jti不加入（否则无法连续刷新） - 不要在刷新逻辑里验证旧 token 的
exp——它本就该过期了，重点是验证签名和黑名单
复杂点在于黑名单清理和 jti 生成：用 secrets.token_urlsafe(16) 生成 jti，Redis key 设为 blacklist:{jti}，TTL 设为 original_exp - now + 300 秒。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
