在浏览器上验证 JWT答案

【问题标题】：Verify JWT on browser在浏览器上验证 JWT
【发布时间】：2019-01-25 08:01:47
【问题描述】：

我一直在阅读有关JWT 的信息，我知道它包含三个部分，即header、payload 和signature。

我保留了标头中使用的散列算法，有效载荷中的基本信息例如。有效载荷中的名称、年龄、角色、到期等，然后将这两者都进行 base64 编码，然后使用标头中指定的算法以获取 JWT

我有一个可以使用username 和password 登录的前端。
登录请求发送到服务器，该服务器对其进行身份验证并返回 JWT。假设使用的算法是 HS256，它是一种对称密钥算法。
因此服务器将拥有secret key，将使用它来生成 JWT。
作为登录请求响应的一部分，浏览器将拥有 JWT。
现在这个 JWT 可能会在途中被篡改，所以在使用它之前，我应该验证 JWT 的真实性。
为了验证，我需要密钥。

问题：

如何在前端获取此secret key？
有效负载可以保留有关用户的任何信息（不是任何敏感信息，例如密码）。既然 JWT 中途可能被篡改，那么在前端不验证 JWT 的情况下使用 payload 信息是不是很危险？

【问题讨论】：

根据您使用的语言，已经有大量经过全面测试且可用的 JWT 库，因此您不必自己手动完成。
@Morgan 你能指点我一些链接，告诉我它是如何做到的。无论如何，在前端它将需要密钥。我想看看它是如何安全地提供给前端的。
您链接到的站点有一个适用于各种平台的 JWT 解码库列表。检查此stackoverflow.com/questions/38552003/… 以解码令牌客户端
@Ash 我不关心解码。关于如何在前端验证令牌

标签： authentication jwt

【解决方案1】：

接收 JWT 的服务器是验证令牌的服务器。如果有人修改了令牌，验证将失败并且访问将被拒绝，因为（希望）服务器外部没有人知道这个秘密，因此无法创建有效的令牌。如果客户知道秘密，特别是。在浏览器/js 环境和对称哈希算法中，这是一个很大的安全风险，有人可能会窃取机密并创建具有有效签名的新令牌。

【讨论】：

我完全同意你的观点，在客户端拥有秘密是一个很大的安全风险。那么这是否意味着，无论有效载荷中存在什么信息，我都不能在前端使用它？因为当 JWT 作为响应发送到浏览器时，可能会发生一些恶意用户截获响应并更改有效负载的情况。我可以确保有效负载没有被更改的唯一方法是验证 JWT，我将需要密钥。在这种情况下，我使用的有效负载信息不正确。因此，我必须验证 JWT 的真实性。怎么可能。
这就是为什么应该使用HTTPS的原因之一。如果您仍然觉得需要在客户端验证令牌，请使用非对称算法。然后你可以用公钥验证，但只有服务器可以用私钥创建一个有效的令牌。
什么是最佳实践。不建议在前端验证吗？
首先，扪心自问：被篡改的令牌会造成什么损害，一旦请求服务器端资源就会验证失败？令牌中的哪些信息可以更改？根据您自己的判断，您可能会考虑使用 HTTPS 和非对称密钥。但是没有通用的最佳实践。但对于 HS256 或其他对称算法，最佳做法是将密钥保留在服务器上。
afai 可以想到，我可以使用来自被篡改令牌的有效负载中的信息将其显示在 UI 上，这可能会误导用户，但是使用这个被篡改的 JWT 对受保护资源的下一个请求会失败，所以不会失败可能会造成损坏。如果我没有将有效载荷信息用于任何事情，那么是的，不会造成任何损害。

【解决方案2】：

任何不记名令牌只能在HTTPS 上使用。而保护HTTPS 连接的TLS 具有内置的完整性检查，以防止在传输过程中进行修改。

所以不需要在客户端验证令牌。

此外，最好将 JWT 令牌视为一些不透明的字符串。这允许发布服务器加密其内容而不会破坏您的应用程序。

正如其他人所指出的，客户端永远不应该拥有签名密钥，因为客户端永远不会被信任。

现在，如果令牌使用 非对称 密钥签名，您可以下载公钥并验证令牌，而不会损害系统的安全性。有 JavaScript 库可以做到这一点，但你没有理由这样做。

【讨论】：

是的，我同意。如果整个通信是通过 HTTPS 进行的，那么它是安全的，我可以确定 JWT 没有被篡改。我的疑问是关于何时通信不安全。因此，任何 Bearer 令牌都应仅在 HTTPS 上使用是有道理的。我想我只是想听听这句话。
这就是 OAuth2 RFC 强制使用 TLS 的原因，请参阅 tools.ietf.org/html/rfc6749#section-10.9。您可以通过接受来表明您对答案感到满意。