Flask-Login不能直接用于前后端分离鉴权，因其依赖服务端Session和Cookie，而跨域场景下浏览器受同源策略限制，无法可靠发送或校验Cookie，易受CSRF、多端冲突等问题影响；无状态鉴权需客户端自持完整认证信息并由服务端验证，JWT是更适配方案。
为什么不能直接用 Flask-Login 做前后端分离鉴权
Flask-Login 依赖 session（即服务端存储 + Cookie），而前后端分离场景下，前端通常运行在 http://localhost:3000 或独立域名，浏览器会因同源策略拒绝发送 Set-Cookie，或后端无法校验跨域 Cookie。即使配了 supports_credentials=True，也容易因 CSRF、多端登录冲突、移动端不支持等问题失效。
无状态鉴权必须把认证信息全放在客户端，并由服务端验证其完整性与时效性——JWT 是最常用选择，但要注意它不是银弹。
- JWT 必须用 HS256 或 RS256 签名，绝不能用
none算法 - 敏感字段（如权限列表）不应塞进 payload，而应查库动态生成；否则权限变更后 token 不失效
-
exp字段建议设为 15–60 分钟，配合 refresh token 机制延长会话
如何用 PyJWT 实现登录接口并返回 token
不要自己拼 JSON 再 base64，用 jwt.encode() 生成 token，用 datetime.utcnow() 控制过期时间。密钥必须从环境变量读取，不可硬编码。
import jwt
from datetime import datetime, timedelta
from flask import Flask, request, jsonify
<p>app = Flask(<strong>name</strong>)
SECRET_KEY = os.environ.get("JWT_SECRET", "dev-secret-change-in-prod")</p><p>@app.route("/api/login", methods=["POST"])
def login():
data = request.get_json()
username = data.get("username")
password = data.get("password")</p><h1>此处应查数据库校验用户（示例略）</h1><pre class="brush:php;toolbar:false;">if username == "admin" and password == "123":
payload = {
"sub": username,
"exp": datetime.utcnow() + timedelta(minutes=30),
"iat": datetime.utcnow(),
}
token = jwt.encode(payload, SECRET_KEY, algorithm="HS256")
return jsonify({"token": token})
return jsonify({"error": "Invalid credentials"}), 401
注意：jwt.encode() 在 PyJWT ≥ 2.0 返回 str，在 1.x 返回 bytes，务必检查版本；生产环境建议用 RS256 配合私钥签名、公钥验签，避免密钥泄露导致全部 token 可伪造。
如何在请求中校验 JWT 并注入用户信息
前端必须在每个受保护请求的 Authorization header 中传 Bearer <token></token>，后端用 jwt.decode() 验签并捕获异常。不要在视图里重复写校验逻辑，用装饰器或 before_request 统一处理。
- 必须指定
algorithms=["HS256"]，否则可能被降级攻击 - 捕获
jwt.ExpiredSignatureError、jwt.InvalidTokenError、jwt.DecodeError三类异常，分别返回 401 - 解码后应校验
sub是否存在、是否为空字符串，防止空用户绕过
from functools import wraps
from flask import g
<p>def require_auth(f):
@wraps(f)
def decorated(*args, *<em>kwargs):
auth_header = request.headers.get("Authorization")
if not auth_header or not auth_header.startswith("Bearer "):
return jsonify({"error": "Missing or invalid Authorization header"}), 401
token = auth_header[7:]
try:
payload = jwt.decode(token, SECRET_KEY, algorithms=["HS256"])
g.user = payload["sub"]
except jwt.ExpiredSignatureError:
return jsonify({"error": "Token expired"}), 401
except (jwt.InvalidTokenError, jwt.DecodeError, KeyError):
return jsonify({"error": "Invalid token"}), 401
return f(</em>args, **kwargs)
return decorated</p><p>@app.route("/api/profile")
@require_auth
def profile():
return jsonify({"user": g.user})
</p>
为什么 refresh token 不能只存前端 localStorage
JWT 自身无法主动作废，所以短期 token（access token）过期后，需要一个长期有效的 refresh token 换新 access token。但若把 refresh token 存在 localStorage，XSS 攻击可直接窃取并无限续期——这比泄露 access token 更危险。
更安全的做法是：refresh token 存 HttpOnly Cookie（secure + SameSite=Strict），且每次使用后服务端立即失效旧 token 并生成新 token。后端需维护 refresh token 的白名单或哈希值（如 sha256(refresh_token + salt)），避免数据库膨胀。
这个环节最容易被跳过：没有 refresh token 失效机制，等于把长期凭证暴露在前端；没有服务端绑定设备/IP/UA，等于允许任意设备无限续期。真正的无状态，只针对 access token；refresh token 必须有状态管理。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
