这对最终网络安全有好处

0 Shares

理解 JWT 与 OAuth：提升网络应用安全性的终极指南

为了增强您的网络应用程序的安全性，JWT (JSON Web Token) 和 OAuth 都提供了安全身份验证和授权机制。但是，您应该选择哪一个来确保用户安全访问您的应用程序呢？本文将深入探讨 JWT 和 OAuth，解答您的疑问。

阅读本文后，您将清楚了解 JWT 和 OAuth 的概念、优点、区别，以及应该选择哪一个来提高您网络应用程序的安全性。

让我们直接开始吧。

什么是 JWT？

JWT，即 JSON Web Token，是一种开放标准，它定义了如何在两方之间以 JSON 对象的形式安全地共享信息。由于信息经过数字签名，各方可以信任并验证通过 JSON Web Token 传输的数据。

JWT 的特点是大小相对较小，这使得它们可以通过 POST 参数、URL 或 HTTP 标头进行发送。一个 JSON Web Token 由三个部分组成：头部（header）、载荷（payload）和签名（signature）。

头部描述了令牌类型和所使用的签名算法。 JWT 的载荷部分包含有关用户和附加数据的声明。

顾名思义，JSON Web Token 的签名部分使用签名来验证消息在传输过程中是否被篡改。

JWT 的工作原理

图片来源： DEV

以下是 JSON Web Token 的工作流程：

用户登录

用户通过输入用户名和密码登录您的网络应用程序。您的应用程序会将这些登录凭据发送到身份验证服务器。

令牌生成

身份验证服务器验证用户登录凭据后，会生成一个 JSON Web Token 并将其发送给用户。这些 JWT 可能包含有关用户及其身份验证会话的关键信息。用户会在本地存储这些 JWT。根据您的设置，服务器还可以使用共享密钥或私钥对 JWT 进行签名，以增强安全性。

令牌验证

当用户向您的应用程序服务器发出访问资源的请求时，他们会在请求中包含 JWT。您的应用程序服务器会验证 JWT 中的签名，并检查载荷中的声明，以确认是否允许用户访问所请求的资源。

如果 JWT 有效，用户将被授予访问其在网络应用程序上请求的资源的权限。

JWT 的用例

JSON Web Token 可以应用于以下场景：

#1. 授权

当用户成功登录您的网络应用程序后，身份验证服务器会颁发一个 JWT。用户将使用此 JWT 来访问应用程序内的资源，这需要身份验证以证明其身份。

各方之间的信息交换

JSON Web Token 是安全地将信息传输给有效用户的理想选择。 JWT 经过签名以确保信息的来源可靠。此外，JWT（签名部分）的结构允许接收者验证信息在传输过程中未被篡改。

JWT 的好处

在您的网络应用程序中实施 JWT 的主要好处如下：

与 SAML 令牌不同，JWT 轻量级。因此，您可以在 HTML 和 HTTP 环境中快速实现它们，这使得 JWT 成为移动应用程序等客户端应用程序的理想选择。
JWT 提供了强大的安全性。您可以使用 HMAC 算法通过共享密钥对 JWT 进行对称签名，或者使用私钥对 JWT 进行非对称签名。
JWT 内置了过期机制，允许您设置 JWT 的过期时间，从而增强安全性。
JSON Web Token 被多种单点登录解决方案广泛采用，因此使用 JWT 很方便。

此外，JWT 可以帮助公司节省数据库存储空间，因为服务器只负责创建 JWT，它们会存储在客户端。此外，JWT 不需要数据库查找。

因此，JWT 可以实现快速验证，从而提供卓越的用户体验。

JWT 的局限性

虽然 JWT 是授权用户的强大方法，但它们也存在一些局限性，例如：

您有责任确保加密密钥的安全。如果黑客获取了用于签署 JWT 的密钥，可能会导致严重的安全问题。他们可以使用伪造的令牌来干扰您的用户数据。
JWT 不需要每次检查都调用数据库，这听起来很棒，但如果您需要尽快撤销一个令牌，则需要将其列入黑名单，这不是一个快速或简单的过程。
当 JWT 过期时，不能简单地延长其有效期。您的系统会要求用户重新登录以获取新的令牌。这增加了整个过程的复杂性，需要更全面地考虑用户体验和安全流程。为了简化此过程，您可以将 JWT 与刷新令牌结合使用。当访问令牌过期时，客户端可以使用这些刷新令牌来请求新的访问令牌，而无需用户再次输入登录凭据。
在网络应用程序中实施 JWT 并非易事；它需要额外的工程工作。您需要建立令牌创建流程、选择适合您应用程序的签名机制，并将其与您现有的架构集成。

JWT 不是一个直接的解决方案，而是一个需要仔细计划和执行的项目。

什么是 OAuth？

OAuth，即开放授权的缩写，是一种用于授权的开放标准协议。它允许网络应用程序或网站代表用户访问第三方应用程序托管的资源，而无需用户共享第三方应用程序的登录凭据。

目前，OAuth 的最新版本是 OAuth 2.0，它被广泛用于通过身份验证服务器进行用户身份验证。

例如，使用 OAuth 后，用户可以使用其 Facebook 或 Google 帐户登录您的应用程序，而只需要在 Facebook 或 Google 帐户上输入登录凭据。

OAuth 的工作原理

图片来源：佐霍

假设您有一个时间管理应用程序。为了让用户有效地使用您的应用程序，您需要访问他们的电子邮件收件箱。在以前，用户必须与您的应用程序共享他们的登录凭据，才能允许应用程序访问他们的收件箱。而 OAuth 2.0 解决了这个问题。

OAuth 2.0 的工作流程如下所示：

您的时间管理应用程序（客户端）请求访问受保护的资源，即用户的收件箱，由用户（资源所有者）拥有。您的应用程序通过将用户重定向到授权端点来实现此目的。
资源所有者（用户）对时间管理应用程序发出的资源访问请求进行身份验证和授权。客户端（您的应用程序）将从授权端点获得授权。
您的应用程序将从授权服务器请求访问令牌，以访问用户的收件箱。这将通过提交授权和应用程序本身的身份验证来实现。
如果您的应用程序的身份已经过验证，并且授权有效，您的应用程序将收到一个访问令牌，以访问用户的收件箱。
如果访问令牌有效，您的应用程序现在可以通过提交访问令牌进行身份验证，以访问用户数据（用户的收件箱）。

现在，您的时间管理应用程序可以访问用户的收件箱。正如 OAuth 文档中所述，不同的授权类型可能会导致授权流程略有差异。

OAuth 的好处

使用 OAuth 的主要优点如下：

OAuth 是一个被广泛接受的标准。这意味着所有主要的身份验证服务都了解并使用 OAuth。
由于 OAuth 的广泛应用和兼容性，用户可以找到许多 OAuth 插件和功能。
OAuth 为几乎所有编程语言和 Web 框架都提供了经过测试的客户端库，因此您可以使用自己喜欢的语言来使用 OAuth。
OAuth 具有高度安全性，并且经过严格审查。由于它被广泛使用，专家们已经考虑了所有潜在的安全风险。
OAuth 非常适合代码解耦。在处理身份验证任务时，您的主应用程序代码不会变得混乱。从长远来看，这使得管理和更新应用程序变得更加容易。

OAuth 的用例

以下是一些 OAuth 的常见用例：

OAuth 2.0 最常见的用途是让第三方应用程序访问用户的帐户。通过 OAuth 2.0，用户可以授权第三方访问存储在不同服务中的数据，而无需向第三方提供这些服务的登录凭据。
作为网络应用程序的所有者，您可以使用 OAuth 2.0 来实现单点登录。您可以为您的项目探索这些开源的 OAuth 解决方案。
您可以在 API 网关中实现 OAuth 2.0，使 API 网关充当授权服务器，确保 API 网关仅转发来自具有有效访问令牌的客户端的请求。
OAuth 2.0 可以让物联网设备（如冰箱或电视）等智能设备代表用户与第三方 API 进行交互。当用户需要在没有传统键盘的设备（如智能电视或游戏机）上登录应用程序时，这将非常有用。

OAuth 的局限性

对于 OAuth 的新手来说，可用的流程范围可能让人不知所措。这不仅仅是选择一个，而是选择一个组合。有时，您需要一个组合才能满足您的所有安全要求。这种复杂性可能会让初学者难以知道从哪里开始，应该使用什么，以及如何有效集成它。

每个流程都有其独特的用途，无论是移动应用程序、服务器到服务器通信还是网络应用程序。因此，在做出选择之前，仔细分析您的具体需求至关重要。

OAuth 2.0 依赖 SSL/TLS 来保证安全。如果 SSL/TLS 设置不当，OAuth 2.0 的安全性可能会受到威胁。

此外，OAuth 可能会引发隐私问题，尤其是在跟踪用户活动时。当您使用“使用 Google 登录”等服务时，Google 可能会注意到您在该第三方网站上的活动。 Google 不仅可以知道您已登录，还可以跟踪您与该网站交互的频率和时间。

此外，对于更简单的设置（例如只有一个前端和后端的应用程序），OAuth 可能有点过度，在这种情况下，您可能不需要它的复杂性。

JWT 和 OAuth 之间的区别

JWT 和 OAuth 都提供了验证用户身份以授权访问资源的关键功能。它们是安全领域的必要工具，但在范围、复杂性和应用方面有所不同。

特点	JWTs	OAuth
主要用途	JWT 主要关注 API。	OAuth 涵盖网络、浏览器、API 和其他应用程序。
令牌 vs. 协议	JWT 是一种令牌格式。	OAuth 是一种授权协议。
存储	JWT 仅依赖于客户端存储。	OAuth 同时使用客户端和服务器端存储。
灵活性	JWT 的范围更加有限。	OAuth 提供更大的灵活性和更广泛的用例。
易于使用	JWT 更简单、更容易掌握。	OAuth 更复杂。

JWT 更简单且面向 API 安全，而 OAuth 提供全面的身份验证机制解决方案，可以适应各种场景。

OAuth 允许用户允许第三方应用程序在另一个平台上访问他们的数据，而无需透露他们的登录详细信息。

选择哪种技术取决于所讨论的系统或网络的具体需求。

JWT 和 OAuth 可以一起使用吗？

虽然 JWT 和 OAuth 有不同的用途，但您可以将它们结合使用。

OAuth 协议没有指定任何必须严格使用的令牌格式，因此您可以在 OAuth 中实现 JWT。

例如，OAuth2 身份验证服务器可以颁发一个带有 JWT 的访问令牌。此 JWT 可以在有效载荷中包含附加信息，从而提高性能，因为身份验证和资源服务器之间的往返次数会减少。

JWT 和 OAuth2 的组合也可以通过双令牌方法实现，即 OAuth2 发出两个单独的令牌：access_token 和 JWT。其中 JWT 包含额外的身份信息。这种方法提供了额外的细节层，使您可以更好地控制用户访问和数据。

在选择这种双令牌策略时，使用 OpenID Connect 至关重要。 OpenID Connect 基于 OAuth2 构建，并向令牌添加了更多标准化字段。

使用 JWT 代替 OAuth2 可以使某些任务的处理速度更快、更简单，但这也可能使开发更具挑战性。

当您决定将 JWT 与 OAuth2 结合使用时，请仔细考虑速度的提升是否值得增加开发工作。

结论

在 JWT 与 OAuth 的网络安全之争中，两者各有优缺点。 JWT 擅长无状态、快速身份验证，但存在一些局限性，例如缺乏内置的撤销机制。 OAuth 在复杂的授权场景中表现出色，但对于简单的项目可能有些过度。

如果您需要强大的授权和高效的身份验证，请考虑通过 OpenID Connect 将 JWT 和 OAuth 结合使用。

您的选择应基于您特定的项目需求，而不是围绕这些技术的炒作。

此外，您可以探索这些流行的用户身份验证平台，为您的应用程序选择最佳解决方案。