JWT
JSON Web Token
高级通用JWT（JSON Web Token）是一种带有声明和数字签名的令牌格式，服务器可以用它传递用户身份等信息。它解决了多个服务核验请求身份时需要共享可信信息的问题，例如网站登录后访问不同的 API。
你可能会说：「我做的网站登录后要调用多个 API，想让它们认出当前用户，该怎么设计？」
动手看看登录后访问订单接口
1
用户提交登录信息。登录服务先核对身份，确认是谁之后，才会签发令牌。
要点JWT 为什么能让服务认出你？
- 1
令牌里装着哪些信息
JWT 通常由头部、载荷和签名三部分组成。载荷可以写用户 ID、过期时间等声明。你可以把它理解成服务端签发的一张凭据，而不是存放密码或其他秘密的保险箱。
- 2
签名证明内容没有被改动
API 收到 JWT 后，会按约定验证签名，并检查过期时间等声明。因为载荷本身可以被读取，所以签名解决的是「能否信任这些内容」，不是「让别人看不见这些内容」。
- 3
认出用户不等于放行操作
验证通过后，API 才能根据令牌中的信息识别请求者。但你要判断他能否删除项目、查看账单，还得做权限检查；如果权限可能随时变化，就要考虑查询当前权限，而不是只信令牌里的旧信息。
容易混淆的地方
JWT 是令牌的格式，不等于登录流程本身；OAuth 解决的是授权流程，可以在流程中使用 JWT，也可以不用。它也不等于 Cookie：Cookie 是浏览器存放并随请求发送数据的一种机制，可以装 JWT，也可以装普通会话标识。传统服务端会话通常靠标识去服务端查询状态，而 JWT 可让服务仅凭令牌和验证所需的密钥核验其中的声明。
什么时候用
适合用
- 你做一个网站，登录后需要让多个 API 识别同一用户，可以由登录服务签发 JWT，再由各 API 验证。
- 你有独立部署的移动端后端接口，想让请求携带有有效期的身份声明，供接口验证后继续处理。
- 你在拆分后台服务，希望接收请求的服务能先验证令牌，再结合当前业务数据判断操作权限。
不适合用
- 你只做一个服务端渲染的小网站，登录状态都由同一服务管理时，用服务端会话和 Cookie 往往更直接。
- 你只是给单个自动化脚本调用内部接口，不涉及用户登录；用受限的 API 密钥可能更合适。
- 你需要保存用户的密码或私密资料时，JWT 不是存储容器；密码交给密码哈希处理，资料放在受控数据库里。
练一练选一个答案，看看解释
你做的项目管理后台把用户 ID 写进 JWT。现在要开放「删除项目」接口，哪种处理方式更合理？
让 AI 帮你做复制给 AI Agent 直接用
请为我的项目管理后台设计 JWT 登录后的 API 身份验证：说明令牌里放哪些必要声明、服务端怎样验证签名和有效期，以及删除项目时怎样另查当前权限。别把密码或私密资料放进令牌。