JSON 网络令牌的效用？它比当前系统更有效吗？
Utility of JSON Web Tokens ? How is it more efficient than current systems?
我一直在阅读有关 JSON Web 令牌的文章，一些问题突然出现在我的脑海中。我已经阅读了很多关于我们应该如何从基于会话的方法转向 JWT 的说法。我更多地考虑 Node JS 后端，它为 UI 和移动 .
公开 API
声明：JWT 不要求您为每个 http 请求与您的键值数据存储进行通信。
问题 1: 我不能为所有用户使用一个私钥（如果我只有一个私钥，会有什么安全风险？）。那我无论如何都需要一个数据库。
声明：JWT 在每个 request.And 上发送令牌，因此我们不需要在会话上存储任何数据，如 "name,email"，而是它们可以驻留在令牌本身.
问题 2：负载的大小不会增加吗，因为每个请求都会发送它们并且它还包含数据？
声明：您可以使用相同的方法进行移动身份验证以及 Web UI 身份验证。
问题 3 : 由于服务器现在必须解密令牌并与服务器通信，这对 Web UI 来说不是一种开销吗？
声明：将token传递给JS，将token存储在sessionStorage或localStorage中。
问题4 : 由于sessionStorage中没有"httpOnly"的概念，难道不是安全问题吗？ chrome 插件也可以通过获取令牌并登录来规避安全性吗？
最后，除了 CRSF 问题，在 UI 和 Mobile Auth 之间共享代码并使 CSRF 受益，我真的看不出有什么比当前基于会话的好处机制。我的想法正确吗？
此外，与传统的基于会话的系统相比，JWT 的缺点是什么？
问题 1
是的，如果您想为每个用户签署唯一的 JWT，那么您需要将这些密钥存储在您的数据库中
此外，您无论如何都需要将令牌存储在您的数据库中，因为当令牌被撤销时，即使令牌有效，您也需要拒绝该请求
但这里要注意的是，这种基于令牌的身份验证对所有客户端都很有用，而不仅仅是我们的应用程序，因此不需要重写 API
JWT 是基于令牌的身份验证中令牌的一种格式
问题2
是的，即使您在 JWT 中添加少量详细信息，您的负载也可以轻松达到 700 到 1000 个字符
但它有助于在不点击的情况下获得有关经过身份验证的用户的清晰信息，这里的建议是尽可能少地进入并将其余部分存储在数据库中，并在需要时使用它
问题 3
不，客户端 (Webapp) 在这里需要做的就是在每个请求中存储和发送该令牌，这与发送会话 cookie 相同（它只是自动的）
问题4
是的，任何人都可以复制令牌并获得访问权限（但它会在短时间后过期）这与（会话劫持）相同，或者在建立会话后，用户可以直接从 bowser 中的休息控制台调用 Apis 和它仍然有效
在这种情况下，令牌是有效的，因为它的生命周期通常较短，而不是会话的生命周期
JWT 有真正的好处，最重要的是可以向任何客户端公开相同的 Apis，无需为 Webapp 和其他客户端编写单独的 Apis
JWT 仍然是一个草案而不是一个规范，如果你仔细使用它会有真正的好处，搜索基于令牌的身份验证你会发现比会话有很多优势
我一直在阅读有关 JSON Web 令牌的文章，一些问题突然出现在我的脑海中。我已经阅读了很多关于我们应该如何从基于会话的方法转向 JWT 的说法。我更多地考虑 Node JS 后端，它为 UI 和移动 .
公开 API声明：JWT 不要求您为每个 http 请求与您的键值数据存储进行通信。
问题 1: 我不能为所有用户使用一个私钥（如果我只有一个私钥，会有什么安全风险？）。那我无论如何都需要一个数据库。
声明：JWT 在每个 request.And 上发送令牌，因此我们不需要在会话上存储任何数据，如 "name,email"，而是它们可以驻留在令牌本身.
问题 2：负载的大小不会增加吗，因为每个请求都会发送它们并且它还包含数据？
声明：您可以使用相同的方法进行移动身份验证以及 Web UI 身份验证。
问题 3 : 由于服务器现在必须解密令牌并与服务器通信，这对 Web UI 来说不是一种开销吗？
声明：将token传递给JS，将token存储在sessionStorage或localStorage中。
问题4 : 由于sessionStorage中没有"httpOnly"的概念，难道不是安全问题吗？ chrome 插件也可以通过获取令牌并登录来规避安全性吗？
最后，除了 CRSF 问题，在 UI 和 Mobile Auth 之间共享代码并使 CSRF 受益，我真的看不出有什么比当前基于会话的好处机制。我的想法正确吗？
此外，与传统的基于会话的系统相比，JWT 的缺点是什么？
问题 1
是的，如果您想为每个用户签署唯一的 JWT，那么您需要将这些密钥存储在您的数据库中
此外，您无论如何都需要将令牌存储在您的数据库中，因为当令牌被撤销时，即使令牌有效，您也需要拒绝该请求
但这里要注意的是，这种基于令牌的身份验证对所有客户端都很有用，而不仅仅是我们的应用程序，因此不需要重写 API
JWT 是基于令牌的身份验证中令牌的一种格式
问题2
是的，即使您在 JWT 中添加少量详细信息，您的负载也可以轻松达到 700 到 1000 个字符
但它有助于在不点击的情况下获得有关经过身份验证的用户的清晰信息，这里的建议是尽可能少地进入并将其余部分存储在数据库中，并在需要时使用它
问题 3
不，客户端 (Webapp) 在这里需要做的就是在每个请求中存储和发送该令牌，这与发送会话 cookie 相同（它只是自动的）
问题4
是的，任何人都可以复制令牌并获得访问权限（但它会在短时间后过期）这与（会话劫持）相同，或者在建立会话后，用户可以直接从 bowser 中的休息控制台调用 Apis 和它仍然有效
在这种情况下，令牌是有效的，因为它的生命周期通常较短，而不是会话的生命周期
JWT 有真正的好处，最重要的是可以向任何客户端公开相同的 Apis，无需为 Webapp 和其他客户端编写单独的 Apis
JWT 仍然是一个草案而不是一个规范，如果你仔细使用它会有真正的好处，搜索基于令牌的身份验证你会发现比会话有很多优势