跳转到主内容
新派编程网 - 新潮编程理念,全新技术课堂!

Python怎么做身份验证_JWT Token生成机制与后端接口校验全流程

JWT生成必须显式指定algorithm(如HS256),禁用none算法;密钥须从环境变量读取;payload勿含敏感信息,设exp过期时间;校验需区分ExpiredSignatureError、InvalidSignatureError、DecodeError;Authorization头格式须为“Bearer ”;刷新Token需双Token机制+服务端状态管理。 JWT生成时
pyjwt
的
encode()
必须传
algorithm
参数 不指定
algorithm
会导致默认用
none
算法(即无签名),Token可被任意篡改,后端校验形同虚设。这是新手最常踩的坑,错误示例:
jwt.encode(payload, secret)
在新版
PyJWT
(2.0+)中会直接报
TypeError: encode() missing 1 required argument: 'algorithm'
。 正确做法是显式声明签名算法:
algorithm='HS256'
最常用,适合对称密钥场景 密钥
secret
不能硬编码在代码里,应从环境变量读取,如
os.getenv('JWT_SECRET_KEY')
payload中避免放敏感字段(如密码、身份证号),
sub
建议用用户ID而非用户名,防止重名或变更导致Token失效 务必设置
exp
(过期时间),否则Token永不过期;推荐用
datetime.utcnow() + timedelta(hours=24)
生成
exp
值 Django/Flask里校验JWT要捕获
ExpiredSignatureError
和
InvalidTokenError
只用
try/except Exception
会掩盖具体问题,导致调试困难。真实请求中常见错误不是“Token错”,而是“过期了”或“签名不匹配”,这两类必须分开处理。 以
PyJWT
为例,校验逻辑应明确区分: 立即学习 “ Python免费学习笔记(深入) ”;
ExpiredSignatureError
:返回
401 Unauthorized
+
{"error": "token expired"}
InvalidSignatureError
:可能是密钥不一致或Token被篡改,按非法请求处理(
401
但不暴露原因)
DecodeError
:Token格式错误(比如base64缺位),通常是前端传参异常,返回
400 Bad Request
别忘了检查
payload.get('exp')
是否为数值类型——某些手动构造的Token可能把
exp
写成字符串,
pyjwt
不会自动转换 前端传Token时Header字段名必须是
Authorization: Bearer
后端框架(如Django REST Framework的
JWTAuthentication
、Flask-JWT-Extended)默认只认这个格式。写成
Token xxx
、
Bearerxxx
(少空格)、
authorization
(小写)都会失败,且错误提示往往模糊,比如
Authentication credentials were not provided.
。 Python 3.14.3 微软官方的 Python 扩展,是 VS Code 安装量最高的扩展(209M+)。集成 IntelliSense(通过 Pylance)、调试(通过 Python Debugger)、代码检查、格式化、重构和单元测试等功能。支持 Jupyter Notebook、虚拟环境管理和多 Python 版本切换。 下载 实操注意点: axios请求需显式设置:
headers: { Authorization: `Bearer ${token}` }
fetch中不要漏掉
Bearerspace
,写成
`Bearer${token}`
会导致401 如果用Nginx反向代理,确认没过滤
Authorization
头(需配置
proxy_set_header Authorization $http_authorization;
) 移动端WebView或旧版iOS Safari可能截断长Token,建议限制
payload
大小,避免塞太多字段 刷新Token不能只靠延长
exp
,得用独立
refresh_token
机制 单纯在每次请求时用原密钥重新签发一个新
access_token
,等于没解决安全问题——只要
access_token
泄露,攻击者就能无限续期。真正的刷新逻辑需要双Token配合。 关键设计点:
access_token
短时效(如15分钟),只用于API调用,不存数据库
refresh_token
长时效(如7天),带
jti
唯一标识,服务端需存入Redis并绑定用户ID和设备指纹 刷新接口(如
POST /auth/refresh
)必须验证
refresh_token
有效性,并在成功后立即让原
refresh_token
失效(Redis
DEL
) 别把
refresh_token
存在localStorage——XSS可直接盗取;应设为
httpOnly
Cookie(且
SameSite=Strict
) Token本身是自包含凭证,但“刷新”这件事必须依赖服务端状态管理。漏掉失效机制,等于给攻击者开了永久后门。

相关文章