Python怎么在Flask中实现前后端分离鉴权_基于PyJWT构建双Token验证机制

• access_token 仅用于API请求的即时鉴权，过期即失效，不进入数据库。
• refresh_token 必须存入数据库（例如Redis或通过SQLAlchemy管理的表），并关联user_id、fingerprint（设备指纹）、expires_at（过期时间）和is_revoked（是否已撤销）等关键字段。
• 前端每次请求API时，在请求头携带Authorization: Bearer ；当access_token过期后，则使用refresh_token去换取新的access_token，并且服务端必须严格验证此次请求的指纹与当初签发时绑定的指纹是否一致。

如何用 PyJWT 在 Flask 中签发双 Token 并校验

PyJWT库本身并不区分Token类型，它只是编码和解码的工具。实现双Token的隔离，主要依靠payload中的自定义字段和密钥管理策略。一个常见的做法是使用两个不同的密钥，或者使用同一密钥但配合不同的算法（algorithm）与严格的受众声明（aud claim）来避免混淆。

来看一个签发示例。这里有一个关键细节：refresh_token本身不建议再用JWT格式，而是使用secrets.token_urlsafe()生成一个高强度的随机字符串作为唯一标识符，这样更安全。JWT仅用于签发access_token。

立即学习“Python免费学习笔记（深入）”；

import jwt
from datetime import datetime, timedelta
from flask import current_app

def create_access_token(user_id: int, fingerprint: str) -> str:
    payload = {
        "user_id": user_id,
        "fingerprint": fingerprint,
        "exp": datetime.utcnow() + timedelta(minutes=15),
        "iat": datetime.utcnow(),
        "type": "access"
    }
    return jwt.encode(payload, current_app.config["ACCESS_SECRET"], algorithm="HS256")

def create_refresh_token(user_id: int, fingerprint: str) -> str:
    # refresh_token 不走 JWT，只作唯一标识符（更安全）
    return secrets.token_urlsafe(32)

在校验环节，有几个安全要点不容忽视：调用jwt.decode()时，必须显式传入允许的算法列表，例如algorithms=[“HS256”]，以防止潜在的算法降级攻击。对于payload中的exp（过期时间）和iat（签发时间）字段，必须进行校验。特别是iat，可以限制其必须在“当前时间的前60秒之内”，这能有效防御令牌重放攻击。

Flask 路由怎么统一拦截 access_token 并透传用户信息

不要在每一个视图函数里都重复编写jwt.decode()的代码——这既不优雅，也容易出错。更优的方案是利用@app.before_request钩子或者自定义装饰器，在请求进入业务逻辑之前，统一完成Token的提取、验证，并将解析出的用户信息挂载到Flask的全局g对象上。这里的关键原则是：装饰器或钩子只负责解析和验证，不执行业务逻辑；对于所有可能出现的异常（如令牌过期、无效），都必须被捕获并返回标准化的错误响应（例如401状态码和JSON格式的错误信息）。

下面是一个推荐的自定义装饰器写法，它额外支持了“可选鉴权”的灵活模式：

from functools import wraps
from flask import request, g, jsonify, current_app
import jwt

def require_auth(optional: bool = False):
    def decorator(f):
        @wraps(f)
        def decorated_function(*args, **kwargs):
            auth_header = request.headers.get("Authorization")
            if not auth_header or not auth_header.startswith("Bearer "):
                if optional:
                    g.current_user = None
                    return f(*args, **kwargs)
                return jsonify({"error": "Missing Authorization header"}), 401

            token = auth_header[7:]  # 去掉 “Bearer ” 前缀
            try:
                payload = jwt.decode(
                    token,
                    current_app.config["ACCESS_SECRET"],
                    algorithms=["HS256"],
                    options={"require": ["exp", "iat", "user_id"]}
                )
                # 额外校验 fingerprint 是否匹配（可从 request 中计算，如 UA + IP 的哈希值）
                if payload.get("fingerprint") != get_fingerprint(request):
                    raise jwt.InvalidTokenError("Fingerprint mismatch")
                g.current_user = payload["user_id"]
            except jwt.ExpiredSignatureError:
                return jsonify({"error": "Token expired"}), 401
            except jwt.InvalidTokenError as e:
                return jsonify({"error": "Invalid token"}), 401
            return f(*args, **kwargs)
        return decorated_function
    return decorator

使用时，在需要强制鉴权的路由上使用@require_auth()；而在像登录、刷新令牌这类本身不需要access_token的接口上，则可以使用@require_auth(optional=True)。

refresh_token 刷新接口容易忽略的三个细节

这个用于刷新access_token的接口，看似逻辑简单，却往往是线上安全问题的重灾区。主要风险集中在：令牌被盗用、并发刷新导致冲突、以及旧令牌未能及时失效。

• 存在性与状态校验：必须校验客户端提交的refresh_token是否真实存在于数据库中，并且同时满足is_revoked == False（未撤销）和expires_at > now（未过期）两个条件。
• 立即作废旧令牌：在签发新的refresh_token之前，必须立即将数据库中旧的refresh_token标记为作废（设置is_revoked = True）。这一步至关重要，否则一旦refresh_token泄露，攻击者就可以永久使用它来获取新的访问令牌。
• 防范并发刷新：如果前端因为网络等原因并发调用刷新接口，需要使用数据库的行锁或Redis的SETNX命令等机制，来保证“一个旧令牌只能换一个新令牌”，避免因并发操作生成多个有效的refresh_token。

最后特别提醒一点：不要把refresh_token本身作为JWT的payload进行签发。它本质上只是数据库中的一个主键或索引值。它的安全性依赖于存储层的保护（例如Redis的TTL和认证机制）和传输层的保护（仅通过HTTPS传输，并考虑存放在HttpOnly的Cookie中或对请求体进行加密）。