使用 JWT 进行身份验证答案

【问题标题】：Authentication with JWT使用 JWT 进行身份验证
【发布时间】：2016-04-07 00:42:38
【问题描述】：

上面的帖子似乎通过检查是否有存储为 cookie 的 JWT 来测试用户是否已经登录，如果有，它会简单地对其进行解码以找到用户名和其他信息，并将用户重定向到经过身份验证的页面。

我想知道是什么阻止了某人添加虚假的 JWT cookie 来访问应用程序的经过身份验证的部分？我一定遗漏了一些明显的东西。换句话说，在维护会话时，前端如何确保 JWT 是“由服务器签名”之类的，而不是为试图获得访问权限而欺诈性创建的？

【问题讨论】：

“我想知道是什么阻止了某人添加虚假的 JWT cookie 来访问应用程序的经过身份验证的部分？” --- 你会用什么密钥来签名？
所以当 JWT 作为 cookie 存储在前端时，在满足任何请求之前，服务器会检查该 JWT 是否使用其密钥签名，如果是，是否允许？
"服务器检查 JWT 是否使用其密钥签名，如果是，是否允许？" - - 是的。换句话说 - 您不能信任客户端发送的任何内容。
嗯.. 我想我很困惑，因为当应用程序刷新并且用户之前登录时，我正在关注的教程（或链接到它的 repo）似乎没有这样做. 似乎只是检查localStorage 是否有jwt，如果是，则对用户进行身份验证。

【解决方案1】：

在许多应用程序中，有人可以添加假 JWT 来访问您只希望他们查看是否已登录的前端部分。但是，他们也可以在自己的计算机上运行前端，并且可以更改代码来做同样的事情。

后端服务器使用前端不应该存在的密钥对 JWT 进行编码，当您将 JWT 传递回服务器时，服务器将在处理您的请求之前对其进行解码。所以它知道之前有人使用了你的登录凭证，它发出了 JWT 作为响应，并且有人再次向它发送了 JWT。这可以阻止没有（真正的）JWT 的人对您的 API 进行攻击。

与会话 cookie 相比，它还具有优势，因为它在服务器端是无状态的，并且它使某些跨站点请求伪造攻击在传统浏览器中更加困难，因为攻击者无法将请求嵌入到您的站点并信任浏览器添加您的会话 cookie。

但这只是更大的安全解决方案的一部分。

【讨论】：

【解决方案2】：

JWT 安全性的关键是“秘密”——该密钥应该只存在于受信任的服务器上（如果使用第三方，则应该存在于您的身份验证提供商处）。 JWT 使用此密钥进行加密。它可以是密码，但 JWT 也支持公钥/私钥加密，因此密钥也可以是私钥。

因此，在您的情况下，阻止用户创建新 JWT 的原因是，除非他们知道秘密，否则他们用于创建自己的 JWT 的加密将无法在服务器上运行，如果编码正确，将阻止用户按照他们希望的方式进行身份验证。

【讨论】：