TL;DR 如果您有非常简单的场景，例如单个客户端应用程序、单个 API，那么使用 OAuth 2.0
可能没有回报，另一方面，许多不同的客户端（基于浏览器、本机移动、服务器端等）然后坚持 OAuth 2.0 规则可能比尝试推出自己的系统更易于管理。

如另一个答案所述，JWT（Learn JSON Web Tokens）只是一种令牌格式，它定义了一种紧凑且自包含的机制，用于在各方之间以一种可以验证和信任的方式传输数据，因为它是数字签名的。此外，JWT
的编码规则还使这些令牌在 HTTP 上下文中非常易于使用。

由于是自包含的（实际的令牌包含有关给定主题的信息），它们也是实现无状态身份验证机制的不错选择（又名 看妈妈，没有会话！
）。当走这条路时，一方必须出示才能被授予访问受保护资源的唯一权限是令牌本身，所讨论的令牌可以称为不记名令牌。

在实践中，您正在做的事情已经可以被归类为基于不记名令牌。但是，请考虑您没有使用 OAuth 2.0 相关规范指定的不记名令牌（请参阅RFC
6750）。这意味着依赖AuthorizationHTTP
标头并使用Bearer身份验证方案。

关于在不知道确切细节的情况下使用 JWT 来防止 CSRF，很难确定这种做法的有效性，但老实说，这似乎并不正确和/或不值得。以下文章（Cookies vs
Tokens: The Definitive Guide）可能是关于这个主题的有用读物，尤其是 XSS 和 XSRF 保护 部分。

最后一条建议，即使您不需要完整的 OAuth 2.0，我
强烈建议您在标头中传递您的访问令牌，Authorization而不是使用自定义标头。如果它们确实是不记名令牌，请遵循 RFC 6750
的规则。如果不是，您始终可以创建自定义身份验证方案并仍然使用该标头。

授权标头由 HTTP
代理和服务器识别和特殊处理。因此，使用此类标头将访问令牌发送到资源服务器通常会降低经过身份验证的请求的泄漏或意外存储的可能性，尤其是授权标头。