如何使用Python的PyJWT库安全地生成与校验Web访问令牌？

先给个核心判断：PyJWT的使用，成败往往不在你会不会调用API，而在那些容易被忽略的边界场景和异常处理。很多线上事故，都是因为生成时少传了一个参数、校验时少抓了一个异常导致的。

生成JWT这事儿，核心就一句话：必须把algorithm显式写上，而且绝不能碰none算法。

PyJWT默认并不强制校验签名算法。如果你生成时传了algorithm="none"，或者干脆没传algorithm却用key=None，那出来的就是一个没有签名的JWT——攻击者可以随意篡改payload内容，跟裸奔没什么区别。生产环境必须指定HS256、RS256这类安全的算法，而且密钥要跟算法配对使用。具体操作上，注意这几条：

• jwt.encode(payload, secret_key, algorithm="HS256") —— algorithm参数每次都得传，别偷懒
• 绝不要碰algorithm="none"。这玩意儿只适合调试，或者应付那些老掉牙的系统
• 如果用RSA签名，私钥留作encode()，公钥给decode()。密钥格式必须是PEM字符串，就是带-----BEGIN PRIVATE KEY-----头尾的那种
• secret_key不能硬编码在代码里，要从环境变量或密钥管理服务加载。长度方面，HS256建议至少32字节

校验环节更要注意了。很多开发者只抓InvalidTokenError，结果漏掉了ExpiredSignatureError和InvalidAudienceError——这就等于让过期令牌绕过了校验，安全防线形同虚设。必须警惕的是，异常要分门别类地捕获，而不是笼统地except Exception了事。

• 分别处理ExpiredSignatureError、InvalidSignatureError、InvalidAudienceError、InvalidIssuerError这些具体异常，每个都有不同的业务含义
• audience参数一定要传，比如audience="my-api"。同时payload里要预置"aud": "my-api"，两边对得上才有效
• 通过options={"require_exp": True, "verify_exp": True}强制校验exp字段存在且未过期
• algorithms=["HS256"]也要传，明确限定允许的算法，防止算法混淆攻击

话说回来，有些开发者为了应付服务器时钟偏差，盲目给leeway设个60秒，结果让过期1分钟内的令牌都能通过校验——这等于主动扩大了有效窗口，exp的安全价值被严重削弱。其实leeway只应补偿NTP同步误差，值≤5秒就够了。如果时钟偏差持续超过这个范围，应该去修服务器的时间同步机制，而不是调高leeway。

还有一点：leeway只在decode()时生效，在encode()里设没有任何意义。如果需要“刷新令牌”的逻辑，应该单独设计refresh_token流程，别指望靠leeway延长访问令牌的生命周期。

如果你的项目还在用PyJWT 1.x，尽快升级吧。PyJWT 2.0+版本已经废弃了verify=True/False这个参数，旧代码里常见的jwt.decode(token, key, verify=False)在2.0以上会直接报错。而且直接跳过签名校验，等于放弃了JWT最核心的安全机制。升级后必须改用options来精细控制校验行为，比如options={"verify_signature": True, "verify_exp": True, ...}。当然，options={"verify_signature": False}在单元测试或调试时可以用，但生产环境千万别开——1.x版本还存在已知漏洞（CVE-2022-29038），风险不小。

这正好带出最容易被忽略的一点：aud和iss字段的双向校验。很多人只在生成时写了aud，校验时却不传audience参数；或者把iss写成了固定字符串，却没配issuer。结果这些字段形同虚设，等于白写。记住：生成时写入的字段，校验时必须显式比对，缺一不可。