如何在客户端层处理JWT？

Question

这是一个主观的问题，尽管我认为这不是基于观点的。 在这里提出问题的唯一原因是，即使阅读了有关JWT身份验证的多篇文章，我也找不到令人满意的答案。

我最近开始学习JWT，发现它是由服务器颁发给客户端的3部分令牌，用于真实性以及以声明形式传递诸如用户范围/角色/权限等数据。

但是我的问题是：

1. 令牌的声明部分仍然是base64编码的字符串，可以使用atob/btoa轻松解析该字符串。 那么传输真的安全吗？ 这里真正的收获是什么？

2. 关于生成令牌并将令牌发送到UI有多篇文章。 但是，几乎没有关于UI到底如何使用它的好文章。 使用atob解码令牌并使用其中的内容是一种常见的做法吗？ 还是存在另一种验证和检索数据的方式。

3. 通过标头传输数据真的安全吗？ 我的意思是它可以安全抵御MITM，XSS等问题。

我真的很感谢专家为解决这些问题付出的努力？

Answer 1

对于问题1，收益不在客户端。 如果您不信任从服务器收到的内容，则无论如何对其进行混淆/编码/加密/，都将无法信任它。 关键是您将此令牌发送回服务器。 在服务器上，快速检查将发现此令牌是合法的。 想象一下一个复杂的登录场景，其中MegaCorp在739个子系统中查找用户的权限，将其合并为一个有效负载，然后不必在进一步的请求上再次这样做。 客户端将令牌发回时，它会验证您是否已正确登录并使用权限进行进一步处理。

对于＃2，您可以将任何您喜欢的东西放入此有效负载中，只要它不是太安全即可。 我主要将其用于基本用户信息和应用程序权限。 因此，我可以绘制用户名并提供指向特定用户设置页面的链接。 我可以检查用户是否有权访问管理页面或需要检查的任何权限。 尽管恶意用户可以通过操纵客户端数据来欺骗系统，因此可以看到管理页面，但是当调用返回到服务器以获取该页面的数据时，令牌要么是非法的，要么是请求将被拒绝，或者它不包含适当的权限，再次，它将被拒绝。

我对安全性的了解还不足以尝试回答＃3。

---

有些人只将JWT用于isLoggedIn ，这很好，但是我认为错过了一些有用的可能性。 如果使用得当，这可以是捕获客户端和服务器的用户信息的单一机制。 但是我认为重要的一面是服务器。 这可以在客户端上以多种方式完成。 但是很难为服务器找到更好的东西。

Answer 2

令牌的声明部分仍然是base64编码的字符串，可以使用atob / btoa轻松解析该字符串。 那么传输真的安全吗？ 这里真正的收获是什么？

如果您通过https发送令牌，则传输是安全的（其他人无法读取/修改）。 JWT包含两个重要部分：有效负载和验证签名。 签名只能由一个人生产和验证，并证明有效载荷对该人是合法的。 这是一个简单的用例：

1. 客户端发送到Auth服务器的凭据才能获得发布内容的权利
2. 服务器接收凭证并通过一个复杂的过程对其进行验证，然后将JWT发送回客户端，并说：{我授予客户端发布签名的Auths erver的权利}
3. 客户端在本地存储令牌
4. 当客户端需要发布某些内容时，他发送JWT到服务器B，服务器B与Auth服务器共享签名密钥。
5. 服务器B轻松验证令牌并发布客户端的工作

用法的另一个示例是仅通过邮件进行身份验证。

关于生成令牌并将令牌发送到UI有多篇文章。 但是，几乎没有关于UI到底如何使用它的好文章。 使用atob解码令牌并使用其中的内容是一种常见的做法吗？ 还是存在另一种验证和检索数据的方式。

通常，客户端希望从某个服务器获取令牌，以便稍后将其发送回去。 客户端无法验证签名，因为他不与服务器共享私钥，他不是信任源。

通过标头传输数据真的安全吗？ 我的意思是它可以安全抵御MITM，XSS等问题。

使用https是安全的： HTTPS标头是否已加密？