这是我参与8月更文挑战的第13天，活动详情查看：8月更文挑战
工作原理
在身份验证中，当用户使用其凭据成功登录时，将返回 JWT。由于令牌是凭证，因此必须非常小心以防止出现安全问题。通常，不应该将令牌的保留时间超过过期时间。并且必须在本地保存(通常在本地保存，但也可以使用cookie)，而不是在服务器中创建会话并返回cookie的传统方法。
由于缺乏安全性，你也不应该在浏览器中保存敏感数据
每当用户想要访问受保护的路由或资源时，用户代理应该发送 JWT，通常在使用Bearer模式的Authorization标头中。标题的内容应如下所示：
Authorization: Bearer <token>
这是一个无状态的身份验证机制，因为用户状态永远不会保存在服务器内存中。服务器的受保护路由将检查Authorization标头中的有效 JWT ，如果存在，则用户将被允许访问受保护的资源。如果 JWT 包含必要的数据，则可能会减少为某些操作查询数据库的需要，尽管情况并非总是如此。
如果令牌在Authorization标头中发送，跨源资源共享 (CORS) 不会成为问题，因为它不使用 cookie。
流程：
sequenceDiagram
Application(Client)->>Auth0(Authorization Server): ①
Auth0(Authorization Server)-->>Application(Client): ②
Application(Client)-)API(Resource Server): ③
①： 应用程序或客户端向授权服务器请求授权。这是通过不同的授权流程之一执行的。例如，典型的OpenID Connect兼容 Web 应用程序将/oauth/authorize使用授权代码流通过端点。
②：当授权被授予时，授权服务器向应用程序返回一个访问令牌。
③：应用程序使用访问令牌来访问受保护的资源（如 API）。
请注意，使用签名令牌，令牌中包含的所有信息都会暴露给用户或其他方，即使他们无法更改它。这意味着您不应将秘密信息放入令牌中。
优点
- 因为
JSON数据格式的通用性，所以JWT是可以跨语言的，主流语言都可以支持。 payload部分可以存储其他业务逻辑所必要的非敏感信息。JWT构成简单，字节占用很小，所以非常便于传输的。- 不需要在服务端保存会话信息，易于应用的扩展和安全等。
注意事项
- 不要在
payload存放敏感信息，因为该部分是可解密的。 - 保存好
secret私钥十分重要。 - 尽量使用
https协议
