JWT 与基于 https 的 REST API 的自定义加密

Question

对于我们的 REST API 架构，我们目前正在考虑两种选择 -

1. Json Web Token - 优点是它是行业标准，我们传递了一个添加访问控制层的密钥，使用它我们还可以在后端添加二级授权限制，会话维护和相关安全功能由提供默认情况下是 Django。

缺点是参数对任何人都是开放的，似乎（如果我弄错了，请纠正我）如果有人可以访问我们的链接，他可能会更改未链接的参数核心身份验证过程，从而危及数据。

1. 我们开发的内部加密过程可加密所有参数。优点是我们相当肯定它从未被泄露，因为即使链接会落入某人手中，他们也不知道如何解密它以查看参数。

缺点是我们必须通过表中的后端代码管理所有会话数据，因此我们无法利用 Django 功能。此外，我们正在做的事情不是行业标准的想法。

在这种情况下，正确的决策方式是什么，我们应该考虑哪些因素？

Answer 1

我在这里引用你的问题：

缺点是参数对任何人都是开放的，似乎（如果我弄错了，请纠正我）如果有人可以>访问我们的链接，他可能会更改不是与>核心身份验证过程相关联，从而危及数据。

我认为这里对 JWT 有效负载（或您所称的参数）存在一些误解。确实，有效负载仅经过 Base64 编码，任何有权访问令牌的人都可以解码有效负载并检索信息。但是，他们不能更改有效负载，因为签名会在服务器端使其无效。理想情况下，这应该会导致将 JWT 令牌列入黑名单。您应该注意的是，payload 中不应包含敏感信息（密码、DOB 等）。

我们开发的内部加密过程可加密所有参数。 >优点是我们相当肯定它从未被泄露，>因为即使链接会落入某人手中，他们>也不知道如何解密它以查看参数。

关闭加密算法并不能保证安全。这样的系统也很难扩展，并且容易受到版本错误的影响。程序员可以关闭整个身份验证系统，因为该算法没有正确记录。更糟糕的是，他们会害怕再次触摸它，而不是修复它的错误或尝试跨版本改进它。这变成了难以偿还的技术债务。

JWT

如果您决定在您的架构中使用 JWT，请将刷新令牌用于长期会话并保持 JWT 令牌的有效期较短。在客户端，不将令牌存储在 localStorage 中提供了额外的安全层。您可以将刷新令牌存储在 cookie 中，并在令牌过期时使用它。