为什么我可以在 jwt.io 上轻松解码 auth0 id_token？答案

【问题标题】：Why can i easily decode auth0 id_token on jwt.io?为什么我可以在 jwt.io 上轻松解码 auth0 id_token？
【发布时间】：2016-11-22 07:01:57
【问题描述】：

好的，我正在开发一个 Angular 2 应用程序。我添加了 auth0 身份验证，但对我来说它处理会话非常不安全。 jwt 令牌未加密并保存在 localStorage 中。这些声明对任何人都是可见的，它们可以很容易地被解码和揭示。更不用说，Web Storage 本身并不是一个安全的地方。

我选择 JWT，因为稍后我想用电子将此 Web 应用程序转换为桌面应用程序，因此我无法使用 cookie 会话。我的用户会有额外的信息，比如角色，我不想在每次请求时都在 db 中查找，这就是我想将它们存储在 jwt 中的原因。加密数据是有意义的，但 auth0 似乎没有提供该功能。

如果像角色这样的声明不受保护地存储在 localStorage 中，是什么阻止我去 Firefox 控制台并更改令牌，例如让自己成为管理员？

【问题讨论】：

标签： jwt auth0

【解决方案1】：

如果像角色这样的声明存储在 localStorage 中不受保护，是什么阻止我去 Firefox 控制台并更改令牌，例如让自己成为管理员？

由于JWT 已签名，因此在验证期间将检测到对内容或签名的任何更改

数字签名，像 hhhhhh.ppppppp.ssssss 这样的 JWT 令牌的第三部分是使用服务器私钥创建的，是您可以验证令牌发行者身份的方式，并且它没有被更改

如果您想隐藏有效负载，JWT 规范允许使用加密（请参阅 Json Web Encryption-JWE at RFC）。如果 auth0 不支持，你在jwt.io 中列出了很多库

【讨论】：

感谢您的澄清，好像我没有完全理解 jwts。
没问题，你的问题很有道理
现在等一下。攻击者更改 jwt 内容的唯一方法是现在的密钥。但是，如果他可以访问令牌，他会喜欢暴力破解吗？获得一台超级计算机，一秒生成 40k 秘密并破解它？
是的，理论上是可行的。如果有无限的处理器和大量的时间，你可以执行暴力攻击并破解密钥。很可能。如今，带有 SHA-256 的 2048 RSA 密钥被认为是安全的。此外，证书通常或多或少每两年更新一次。阅读此crypto.stackexchange.com/questions/1978/…
@JustasB。如果黑客可以访问令牌，他可以直接使用令牌与服务器通信并获得访问权限。我在下面的帖子中写了如何保护令牌不被黑客窃取。但请记住，您可以经常更改服务器上的“秘密”密钥（每月一次），这样您就可以免受暴力破解 jwt 令牌的侵害。

【解决方案2】：

JWT 令牌有两部分：explicit（base64 算法编码） - 带有有效负载数据，例如 exp 时间或用户 ID 和角色等，以及 implicit - 哈希密钥，它以极高的概率保证在创建令牌后显式数据的任何部分都不会更改（服务器使用它的私钥）。因此，在本地/会话存储中，您可以存储此显式部分。完整的令牌应该存储在 httpOnly cookie 中 - 然后您将受到保护免受 XSS 攻击（黑客想要窃取您的令牌）。

因此您可以从 firefox 读取和更改 jwt 令牌有效负载，但您将无法生成隐式哈希 - 服务器将拒绝您的令牌。

所以标题问题的答案是：因为Auth0 id_token is JWT token :)

【讨论】：

感谢您的解决方案。但是，我将创建一个具有相同功能的桌面应用程序（使用电子），因此 cookie 在这里不适用，因为电子没有它。
好的，但是你还必须处理电子应用程序中的XSS攻击问题吗？
嗯，是的。我认为，我可能错了，防止 xss 攻击比防止 xsrf 攻击更容易。与在您的网站上实施 xsrf-tokens 相比，从用户输入和令牌中转义内容要容易得多。
实际上是相反的 :) 可以很容易地创建机制来保护 csrf 攻击，但是我们没有办法以自动方式保护 xss - 开发人员需要始终记住这种攻击和过滤器在服务器端输入值（因此开发人员可能会犯错误的情况很多）。更大的问题是当您开始使用第三方库时-您较新知道库没有允许 xss 的错误...如果我的答案和 cmets 对您有帮助，请单击点上方的灰色向上按钮或/和灰色“检查” ' 这个答案左侧的按钮。