Authentication with JWT

本文关键字：JWT with Authentication 更新时间：2023-09-26

我一直在关注这篇博客文章(https://auth0.com/blog/2015/04/09/adding-authentication-to-your-react-flux-app/)，并且对JWT的一个方面感到困惑。

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

我想知道是什么阻止人们添加假JWT cookie来访问应用程序的已验证部分？我一定错过了什么显而易见的东西。换句话说，在维护会话时，前端如何确保JWT是"由服务器签名的"或其他东西，而不是为了获得访问权限而欺诈创建的JWT？

在许多应用程序中，有人可以添加一个假的JWT来访问前端的某些部分，而你只想让他们在登录时看到这些部分。但是，他们也可以在自己的计算机上运行前端，并可以更改代码来做同样的事情。

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

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

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

JWT安全性的关键是"秘密"——一个只能在受信任的服务器上使用的密钥（如果使用第三方，则与您的身份验证提供商一起使用）。JWT使用这个秘密进行加密。它可以是一个密码短语，但JWT也支持公钥/私钥加密，因此密钥也可以是私钥。

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