调第三方的短信接口，文档第一行写着先调授权接口拿 token，后面每次请求带在 Header 里。很多人照着抄能跑通，但说不清这东西到底解决了什么问题，出了 401 就只会重新拿一次。

它替代的是反复传密码

最直接的作用是不让账号密码出现在每次请求里。客户端拿 appid 和 secret 换一个字符串，服务端记住这个字符串对应哪个应用、有哪些权限、什么时候过期。之后只带 token，即使被截获，影响范围和时间都有限，改密码也不用通知所有调用方。

能把权限切细

token 里通常带 scope，比如只读、只能查订单、只能发短信。发给外包的凭证只开必要权限，出事立刻吊销，不用动主账号。JWT 还会把过期时间 exp、签发时间 iat 写进载荷，服务端验签就能判断，不必每次都查会话表。

无状态和可撤销的矛盾

JWT 自带签名，服务端不存会话，横向扩容很方便，但签发后到期前没法作废。要支持强制下线，就得维护黑名单，或者用短时效的 access token 配 refresh token。access token 给 30 分钟，refresh token 给 7 天，刷新时再校验一次用户状态，这是目前比较常见的折中。

存放位置别图省事

  • 别放 URL：会进浏览器历史、nginx 的 access.log 和 Referer，等于公开。
  • 别只放 localStorage：任何 XSS 都能读走，Web 端优先 HttpOnly Cookie 加 SameSite。
  • 必须走 HTTPS：明文传的 token 和明文密码没区别，公共 WiFi 下尤其危险。

服务端要验哪几项

验签、验 exp、验签发者 iss 和受众 aud，三步都不能省。只做 base64 解码看载荷，等于没验。另外别在前端解 JWT 来判断权限，前端拿到的东西用户都能改，权限必须在服务端按接口再判一次。

什么时候不该用

内部定时任务、单机脚本，直接配一把长期密钥更简单。把 token 有效期设成一年、权限给全开，等于把密码换了个名字，出事一样收不了场。