我一直在关注这篇博文（https://auth0.com/blog/2015/04/09/adding-authentication-to-your-react-flux-app/），并且对 JWT 的某个方面感到困惑。
上面的帖子似乎通过检查是否有存储为 cookie 的 JWT 来测试用户是否已经登录，如果是，它只是对其进行解码以找到用户名和其他信息，并将用户重定向到经过身份验证的页。
我想知道是什么阻止了某人添加虚假的 JWT cookie 来访问应用程序的经过身份验证的部分？我一定遗漏了一些明显的东西。换句话说，在维护会话时，前端如何确保 JWT 是“由服务器签名”之类的，而不是为试图获得访问权限而欺诈性创建的？
在许多应用程序中，有人可以添加一个假的 JWT 来访问您只希望他们查看是否已登录的前端部分。但是，他们也可以在自己的计算机上运行前端并且可以更改代码做同样的事情。
后端服务器使用前端不应该存在的密钥对 JWT 进行编码，当您将 JWT 传递回服务器时，服务器将在处理您的请求之前对其进行解码。所以它知道之前有人使用了你的登录凭证，它发出了 JWT 作为响应，并且有人再次向它发送了 JWT。这阻止了没有（真正的）JWT 的人对您的 API 的攻击。
它还比会话 cookie 具有优势，因为它在服务器端是无状态的，并且它使某些跨站点请求伪造攻击在传统浏览器中更加困难，因为攻击者无法将请求嵌入到您的站点并信任浏览器添加您的会话曲奇饼。
但这只是更大的安全解决方案的一部分。
JWT 安全性的关键是“秘密”——这个密钥应该只存在于受信任的服务器上（或者如果使用第三方，则应该存在于您的身份验证提供者处）。JWT 使用此密钥进行加密。它可以是密码，但 JWT 也支持公钥/私钥加密，因此密钥也可以是私钥。
因此，在您的情况下，阻止用户创建新 JWT 的原因是，除非他们知道秘密，否则他们用于创建自己的 JWT 的加密将无法在服务器上运行，如果编码正确，将阻止用户从他们希望的方式进行身份验证。