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

Flask前后端分离鉴权实战：Python如何用PyJWT实现双Token安全验证

单一JWT Token在Flask鉴权中的安全隐患与局限

在前后端分离的Flask应用开发中，如果仅依赖单一的JWT Token（例如仅使用access_token）进行身份验证，会引入显著的安全风险与管理难题。核心问题在于刷新机制的暴露：前端若持有一个能够自我续期的令牌，极易被恶意利用或长期占用，导致用户无法安全登出、令牌难以主动吊销。这相当于将房屋钥匙与配锁模具一并交给了访客。

双Token验证机制正是为此类安全痛点设计的解决方案。它将短期访问凭证与长期刷新凭证彻底分离：让access_token充当一张有时效的临时门禁卡（例如15分钟过期），且不持久化存储；而refresh_token则像一把需要登记管理的长期钥匙（例如7天过期），必须存储在服务端（如Redis或数据库），并与用户ID、设备指纹、过期时间及撤销状态等关键信息绑定。唯有如此，才能实现对用户会话生命周期的精细化管控。

需要明确的是，Flask框架本身并未内置Token刷新流程，也不会自动校验refresh_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格式，而是使用Python标准库的secrets.token_urlsafe()生成一个高强度的随机字符串作为唯一标识符，这样更为安全。JWT仅用于签发access_token。

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

import jwt
import secrets
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()的验证代码——这既不优雅，也容易产生疏漏。更优的方案是利用Flask的@app.before_request钩子或自定义装饰器，在请求进入核心业务逻辑之前，统一完成Token的提取、验证，并将解析出的用户信息（如user_id）挂载到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": "缺少Authorization请求头"}), 401

            token = auth_header[7:]  # 去除 “Bearer ” 前缀
            try:
                payload = jwt.decode(
                    token,
                    current_app.config["ACCESS_SECRET"],
                    algorithms=["HS256"],
                    options={"require": ["exp", "iat", "user_id"]}
                )
                # 额外校验设备指纹是否匹配（可从 request 中计算，如 UA + IP 的哈希值）
                if payload.get("fingerprint") != get_fingerprint(request):
                    raise jwt.InvalidTokenError("设备指纹不匹配")
                g.current_user = payload["user_id"]
            except jwt.ExpiredSignatureError:
                return jsonify({"error": "访问令牌已过期"}), 401
            except jwt.InvalidTokenError as e:
                return jsonify({"error": "无效的访问令牌"}), 401
            return f(*args, **kwargs)
        return decorated_function
    return decorator

在实际使用中，在需要强制鉴权的路由上使用@require_auth()；而在登录、刷新令牌等本身无需access_token的接口上，则可以使用@require_auth(optional=True)来提供灵活性。

Flask刷新接口安全要点：refresh_token易被忽略的三个关键细节

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

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

最后特别强调一点：refresh_token本身不应作为JWT的payload进行签发。它本质上只是服务端存储的一个主键或唯一索引值。其安全性依赖于存储层的保护（例如Redis的TTL和访问控制）和传输层的保护（必须通过HTTPS传输，可考虑存放在HttpOnly的Cookie中或对请求体进行额外加密）。