JSON Web Tokens (= JWTs) 基于RFC 7519，所有差异都将在此处详细描述。如果你看一下这个，你会发现，它们比你想象的要多得多。
除其他外，这些令牌：

• 用于声明声明（例如“以管理员身份登录”）
• 使用消息验证码（例如 HMAC-SHA256）签名（算法在 JWT 的标头中指定）
• 有一个包含声明的有效负载（配备时间戳）

签名是 base64url 编码的。这在 RFC的第 3.1 节和附录 A.1中进行了描述。

您可以通过精心制作的共享声明的本地实现来完成所有这些，但您为什么要这样做？
有标准、规范和 RFC 是有原因的。它们已经过专家的测试，值得信赖，人们使用它们是有原因的。（几乎）每个人都以公斤为单位称重他们的水果并以公里为单位旅行，这是一件好事。标准化的系统使信息共享变得更容易，并且对很多人来说都很容易使用。

这背后的结论是：不要为经过测试和信任的解决方案的问题构建过于复杂的解决方案。

^{另外：看看这个另一个“有什么区别..？” 问题：SHA和AES加密有什么区别？}

从我的其他 sec.SE答案：

JWT 是自给自足的令牌，用于在不同系统之间共享身份验证信息。它们解决了依赖第三方验证身份验证令牌的问题，因为验证 JWT 所需的所有信息都包含在令牌本身中。这简化了单点登录系统中的登录过程，因为所需的集成最少。JWT 也是 HTTP 友好的，因为它们只是 BASE-64 字符串。

您没有提供有关您的应用程序架构的足够信息。在您的特定情况下，任何其他第三方或受信任的资源服务器都很难验证您发布的 AES 令牌。这样做的唯一方法是与希望验证您颁发的身份验证令牌的每个人共享您的 AES 加密密钥。这将是一个糟糕的设计决策，可能会带来严重的机密性和完整性问题。

此外，令牌需要支持重要的安全功能，例如允许资源防止令牌重放攻击的时间戳。您的设计不支持这一点。

AES256.encrypt(JSON.stringify({id: 5552, admin: true}), key)

具有唯一 ID 5552 的管理员用户的安全令牌始终是相同的值。简而言之，您不应该尝试重新发明轮子并依赖现有的方法和框架进行身份验证。JWT 过去曾遇到过安全问题。阅读更多。

差异：

• JWT 发送明文及其 hmac，但您发送的是加密消息
• JWT 是一种标准，并且有多种语言的库

您的系统的问题是客户端无法读取令牌的内容（例如，哪个用户是所有者）。

我认为使用它们的唯一好理由是浏览器应用程序需要一种方法来验证它们。这意味着如果客户端代码可以验证它们，那么它用于验证它们的代码也将对任何黑客可见，尤其是充当中间人的人，这意味着 Internet 上的某些服务器正在中继 HTTP请求和响应。因此，既然您要公开您正在使用的加密算法，那么您不妨使用一种强大、众所周知并且具有支持它的客户端库的算法。但是如果你要依赖一个标准的加密库，你还不如全力以赴，使用 JSON 作为数据格式。最后，您也可以使用 JWT，因为已经存在库来处理所有这些。就个人而言，我不会在标题中包含算法类型。

虽然我不能肯定地说，但我高度怀疑是否有任何银行使用 JWT，因为它们存在安全漏洞。因此，除非您需要银行级别的加密和安全性，否则 JWT 对于您的典型网络应用程序（如社交网络、YouTube 等）可能已经足够了。