授权的未来：为什么 OAuth 2.0 仅仅是开始

授权的未来：为什么 OAuth 2.0 仅仅是开始

授权是应用程序安全性的关键组成部分，仅允许经过身份验证和授权的用户访问受保护的资源。 OAuth 2.0 已成为授权的行业标准协议，为委托访问控制提供了框架。

OAuth 2.0 于 2012 年首次发布，允许应用程序通过颁发访问令牌来代表资源所有者访问资源服务器托管的资源。它允许用户授予第三方应用程序访问其在另一服务上的数据的权限，而无需公开其凭据。

OAuth 已在网络上广泛采用，为包括 Facebook、Google、Twitter 和 Microsoft 在内的许多主要平台提供授权。然而，随着 OAuth 使用量呈指数级增长，漏洞和弱点也随之被发现。这些使得攻击者能够窃取访问令牌并冒充有效用户。

在本文中，我们将概述 OAuth 2.0 的工作原理、常见用例、最佳实践和漏洞。我们还将关注 OAuth 之外的更高级的授权和身份验证协议，旨在增强安全性 - OpenID Connect、双向 TLS 和 WebAuthn。最后，您将对 OAuth 2.0 以及如何安全地使用它有一个深入的了解。此外，您还将深入了解超越 OAuth 的新标准和技术，以进一步保护现代应用程序的访问控制。

OAuth 2.0 的工作原理

OAuth 2.0 是访问委托的开放标准，它为应用程序代表用户访问服务器资源提供安全授权。它允许用户授予对其资源的有限访问权限，而无需公开其凭据。

OAuth 2.0 定义了四种主要授权流程：

授权码流程

授权代码流最适合机密客户端，例如 Web 应用程序。它涉及一个中间授权代码来交换访问令牌：

  1. 客户端应用程序将用户重定向到授权服务器以登录并批准访问。
  2. 授权服务器对用户进行身份验证并使用授权代码重定向回来。
  3. 客户端用授权代码交换访问令牌。
  4. 客户端可以使用访问令牌进行API调用来访问资源。

此流程提供了更高的安全性，因为访问令牌永远不会直接通过用户的浏览器传输。

隐式流程隐式流程针对基于用户代理的客户端（例如单页 Web 应用程序）进行了优化。直接返回访问令牌，无需授权码：

  1. 客户端应用程序将用户重定向到授权服务器以登录并批准访问。
  2. 授权服务器对用户进行身份验证，并使用 URL 片段中的访问令牌重定向回来。
  3. 客户端可以使用访问令牌进行API调用来访问资源。

这种简化的流程无需额外往返授权服务器，但安全性较低，因为访问令牌会在浏览器历史记录中公开。

流程比较

授权码流程更安全，但涉及更多往返。隐式流程更简单，并且针对用户代理客户端进行了优化，但以安全性为代价。

总体而言，OAuth 2.0 为客户端应用程序提供了一个安全的委托授权框架，以标准化的方式访问服务器资源。然而，如果实施不当，漏洞仍然存在。

OAuth 2.0 的优点和缺点

优点：

  • 委托授权，无需共享用户凭据
  • 针对不同客户类型的灵活授权流程
  • 跨主要平台和提供商的广泛采用

缺点：

  • 复杂性导致常见的实施错误
  • 依靠 HTTPS 和令牌保密来确保安全
  • 如果保护不当，访问令牌可能会泄露
  • 超出范围的有限内置用户上下文

OAuth 2.0 解决了安全授权的关键问题，但也存在更高级协议试图解决的弱点。

OAuth 2.0 用例

OAuth 2.0 通常用于在互联网上的各种应用程序和服务中启用授权流程。一些最常见的用例和示例包括：

  • 社交媒体登录 - Facebook、Twitter、Google 和 GitHub 等服务均利用 OAuth 2.0 使用户能够使用其平台凭据“登录”。这允许用户放弃创建新帐户，而是授权这些网站连接到他们现有的社交资料。

  • 应用程序授权 - 移动和桌面应用程序通常集成 OAuth 以授权访问 REST API。例如，应用程序可以使用 OAuth 来访问云存储服务中的用户照片、地址簿服务中的联系人或来自 API 提供商的其他数据。- 安全和单点登录 - OAuth 允许通过单个身份提供商进行集中身份验证，而不是单独管理每个应用程序的凭据。这种单点登录 (SSO) 方法在企业环境中很流行，可以提高安全性和便利性。

  • 用户帐户保护 - 对于注重安全的用户，OAuth 无需共享其主要凭据即可授权应用程序访问。如果应用程序遭到破坏或恶意攻击，这可以保护用户的帐户。

  • 服务集成 - OAuth 通过其授权流程和访问令牌实现不同平台之间的无缝集成。服务可以代表用户通过 API 直接相互连接，从而避免执行冗余身份验证步骤的摩擦和麻烦。

总之，OAuth 2.0 提供了一个标准化框架，用于在不暴露凭据的情况下授予对用户数据和功能的有限访问权限。其灵活的流程和令牌格式使其成为广泛适用的跨 Web、移动、桌面、物联网和 API 驱动集成的授权协议。 OAuth 2.0 是现代网络上应用程序和服务之间无缝互操作性的基础。

OAuth 2.0 最佳实践

为了充分利用 OAuth 2.0 的安全优势，遵循有关注册、密钥、令牌和刷新令牌的最佳实践非常重要。

注册和密钥处理

  • 使用 HTTPS 作为授权和令牌端点。这可以防止中间人攻击。

  • 生成具有足够熵的加密强密钥。建议 RSA 密钥大小为 2048 位，EC 密钥大小为 256 位。

  • 切勿在应用程序中硬编码客户端机密或与不受信任的各方共享机密。将机密安全地存储在服务器端。

  • 设置较短的授权码过期时间，大约 10 分钟。这减少了拦截窗口。

  • 立即撤销暴露的客户端机密并生成新密钥。

代币使用

  • 保持访问令牌的生命周期较短，大约 1 小时。刷新令牌的有效期可能较长，约为 2 周。

  • 仅通过 HTTPS 发送访问令牌并且仅发送到受信任的后端。切勿在 URL、日志或前端代码中包含令牌。

  • 始终验证令牌受众以匹配 API 的预期受众。

  • 检查颁发者是否与您的授权服务器域匹配。

  • 根据已知的可信密钥验证令牌签名算法和密钥。

刷新令牌- 仅为受信任的第一方应用程序和设备颁发刷新令牌。避免为第三方客户端提供刷新令牌。

  • 将刷新令牌绑定到单个特定客户端 ID 和用户身份组合。

  • 当用户注销或权限更改时撤销刷新令牌。重新验证时颁发新令牌。

  • 相当于长期授权的安全刷新令牌。仅通过 HTTPS 传输并通过加密限制访问。

遵循这些最佳实践将确保 OAuth 2.0 为 API 授权提供强大的安全性。

OAuth 2.0 漏洞

虽然 OAuth 2.0 比以前的身份验证协议有所改进，但如果未正确实施和保护，它仍然存在攻击者可以利用的漏洞。一些常见的 OAuth 攻击包括：

  • 令牌劫持 - 攻击者窃取访问令牌并使用它来获得对资源的未经授权的访问。如果令牌没有得到适当的保护或通过不安全的通道传输，就会发生这种情况。

  • 授权代码拦截 - 用于交换访问令牌的授权代码可以在授权过程中被攻击者拦截，从而使他们能够获取有效的访问令牌。

  • 客户端模拟 - 攻击者冒充有效客户端来欺骗授权服务器颁发访问令牌。弱客户端身份验证使这成为可能。

  • 用户模拟 - 攻击者窃取或猜测用户的凭据，并使用它们来进行用户身份验证并获取对其数据的访问权限。

  • 损坏的 OAuth 流 - OAuth 流和验证的错误实施可能会使端点容易被利用。攻击者可以滥用redirect_uri验证、状态参数和代码/令牌发行中的缺陷来危害帐户。

  • 跨站点请求伪造 (CSRF) - 攻击者可以利用 OAuth 对浏览器重定向流的依赖，迫使经过身份验证的用户在不知不觉中代表他们发出请求。

  • 开放重定向器 - 在 OAuth 登录后允许开放重定向可以让攻击者将用户重定向到网络钓鱼站点并窃取凭据或令牌。

为了防止 OAuth 滥用，正确实施至关重要：

  • 使用状态和随机数参数来防止CSRF
  • 执行安全的客户端注册和验证
  • 利用加密的通信渠道
  • 设置较短的代币到期时间
  • 不再需要时撤销令牌
  • 谨慎谨慎地使用刷新令牌
  • 遵循 OAuth 验证和重定向最佳实践虽然 OAuth 2.0 提供了标准化的授权框架，但组织必须注意通过正确的实施、安全控制和强大的访问策略来减少漏洞。 OpenID Connect 等其他协议基于 OAuth 构建，以增强安全性，这表明需要持续发展。

超越 OAuth 2.0

OAuth 2.0 一直是重要的授权标准，至今仍被广泛使用。然而，作为一个已有 10 多年历史的标准，OAuth 2.0 在现代安全威胁面前开始显示出它的年龄和局限性。以下是 OAuth 2.0 可能不再足够的一些关键原因：

  • 专为桌面和 Web 而设计，而不是移动或本机应用程序 - OAuth 2.0 是在移动和本机应用程序之前的时代创建的。它依赖于在 Web 浏览器上下文之外无法正常工作的重定向。这可能会造成安全漏洞。

  • 默认情况下不加密令牌 - OAuth 2.0 令牌通常以未加密的方式发送，从而使它们容易被拦截。该规范要求授权流程使用 https，但访问令牌仍然可以明文传输。

  • 没有用于验证身份的内置方法 - OAuth 2.0 侧重于授权和访问委托。它不验证用户的身份。这为冒充攻击留下了空间。

  • 令牌重用和嵌入风险 - OAuth 2.0 提供单次使用授权，但不阻止令牌被多次使用。具有更广泛访问权限的代币也可以嵌入到应用程序中，从而扩大曝光度。

  • 不需要拥有证明 - 没有加密证据证明使用令牌的一方是预期的授权用户。如果令牌被拦截，这会产生更大的风险。

  • 有限的加密标准 - OAuth 2.0 仅支持 SHA-1 等较旧的加密。 SHA-256 等更强大的现代算法并未内置于核心规范中。

随着威胁的发展，OAuth 2.0 防御威胁的能力已达到极限。尽管 OAuth 2.0 仍在广泛使用，但对于某些用例，需要用更强大、更现代的授权标准来增强和取代。探索 OpenID Connect、双向 TLS 和 WebAuthn 等协议为未来增强安全性提供了选择。

OpenID 连接OpenID Connect 是一种构建在 OAuth 2.0 之上的身份验证协议，可提供额外的身份功能。使用 OAuth 2.0，资源服务器会收到授予访问权限的访问令牌，但不提供有关用户身份的任何信息。

OpenID Connect 允许客户端通过授权服务器进行身份验证来验证用户的身份。这允许客户端获取有关用户的基本个人资料信息。 OpenID Connect 使用 JWT（JSON Web 令牌），其中包含有关用户身份验证的声明，可以将其传回客户端。

OpenID Connect 增强安全性的一些关键用例：

  • 单点登录 (SSO) - OpenID Connect 允许跨多个站点和应用程序进行简单的 SSO。身份验证由身份提供商的授权服务器处理，因此站点不需要各自处理自己的身份验证。

  • 提高完整性 - ID 令牌包含已由身份提供商安全验证的签名声明。这提供了比标准 OAuth 访问令牌更好的完整性保证。

  • 用户个人资料访问 - OpenID Connect 可以选择提供对最终用户个人资料信息的访问，为客户端提供有关用户身份的附加上下文，而无需额外的 API 调用。

  • 更高的身份可信度 - 与基本 OAuth 相比，围绕范围使用、JWT 声明和加密的标准提供了更高的可信度，让用户确信用户是他们所声明的人。

总之，OpenID Connect 构建在 OAuth 2.0 提供的授权之上，还提供可靠的身份验证并验证用户的身份。对于 SSO 等用例以及当身份保证至关重要时，OpenID Connect 是一种更安全、更强大的协议。

用于更强身份验证的相互 TLS

相互 TLS 要求客户端和服务器之间进行双向身份验证，从而提供比传统 TLS 更强大的身份验证。使用 mTLS，客户端和服务器在建立加密的 TLS 连接之前都必须提供证书来识别自己的身份。

mTLS 身份验证的工作原理如下：

  • 客户端通过向服务器发送其客户端证书来发起握手。该证书由受信任的证书颁发机构 (CA) 颁发并验证客户端的身份。

  • 服务器然后向客户端提供自己的服务器证书。该证书根据受信任的 CA 进行验证，以验证服务器的身份。- 如果双方成功验证彼此的证书，客户端和服务器将协商加密的 TLS 会话。这将创建一个经过身份验证的双向通信通道。

  • 客户端和服务器现在可以通过加密的 TLS 隧道安全地交换数据，因为知道两端的身份都已得到验证。

mTLS 比仅向客户端验证服务器身份的标准 TLS 更安全。通过要求相互身份验证，mTLS 可防止未经授权的网络连接，从而阻止中间人攻击。

mTLS 增强安全性的用例：

  • 保护微服务之间的通信。 mTLS 可防止未经授权的微服务加入网格。

  • 内部连接的 Kubernetes Pod 的身份验证。 mTLS 验证集群内通信的 Pod 身份。

  • 确保物联网设备通信的安全。 mTLS 通过要求客户端证书来锁定机器对机器的通信。

  • 银行和金融交易。 mTLS 保证金融系统之间的交易完整性。

实现需要客户端和服务器都支持 mTLS。 NGINX 等负载均衡器可以终止 mTLS 连接，然后以普通 TLS 模式中继流量。客户端 SDK 可以更轻松地将 mTLS 身份验证集成到连接到后端服务的移动和 Web 应用程序中。通过适当的库和负载平衡，公司可以大规模部署 mTLS 安全性。

WebAuthn/FIDO2

WebAuthn（Web 身份验证）和 FIDO2 是新兴的 Web 标准，为传统的基于密码的身份验证提供了替代方案。

WebAuthn 允许网站使用公钥加密而不是密码来注册和验证用户。这是通过安全密钥或生物识别等身份验证器实现的。该标准由 FIDO 联盟和万维网联盟 (W3C) 创建。

FIDO2 是一组技术规范，可使用安全密钥、生物识别或平台身份验证器等安全凭证来实现无密码身份验证方法。它是 FIDO（快速身份在线）标准的扩展。

以下是 WebAuthn 和 FIDO2 相对于传统密码身份验证的一些主要优势：

  • 提高安全性 - 密码可能较弱、重复使用、泄露、被盗或遭受网络钓鱼攻击。 WebAuthn 使用非对称（公钥）加密技术来提供更强大的身份验证形式来抵御这些威胁。- 更好的用户体验 - 无需创建或记住密码。用户只需使用指纹或安全密钥进行身份验证，速度更快、更容易。

  • 降低成本 - 组织在处理密码重置、帮助台呼叫以及其他增加 IT 开销的密码相关问题上花费更少。

  • 隐私保护 - 通过 WebAuthn，原始凭证（生物识别模板或私钥）永远不会离开用户的设备。这样可以保护隐私。

  • 与平台/设备无关 - WebAuthn 可跨桌面和移动设备工作。而且它不会将用户锁定在特定的平台或设备上。

总体而言，WebAuthn 和 FIDO2 代表了网络身份验证安全性和可用性的重大进步。随着这些标准得到更广泛的采用，我们将看到对易受攻击的基于密码的系统的依赖减少。

结论

OAuth 2.0 已成为许多应用程序的授权和身份验证标准，为用户提供了一种在不暴露凭据的情况下授予对其数据的有限访问权限的方法。但是，作为较旧的协议，OAuth 2.0 在安全性、访问范围和用户体验方面存在一些限制。

较新的协议旨在以多种方式改进 OAuth 2.0：

  • OpenID Connect 构建在 OAuth 2.0 之上，添加身份服务，提供身份验证以及身份验证和授权。这有助于解决 OAuth 2.0 中的一些安全漏洞。

  • 相互 TLS 为客户端和服务器提供基于证书的身份验证，防止中间人攻击。虽然实施起来更加复杂，但与单独的 OAuth 2.0 相比，相互 TLS 提高了完整性和隐私保护。

  • WebAuthn/FIDO2 使用公钥加密代替密码进行身份验证，提供防网络钓鱼和防篡改登录。在许多情况下，该协议可以完全替代 OAuth 进行登录。

总体而言，虽然 OAuth 2.0 为安全授权奠定了基础，但它的年龄表现在各种遗留限制上。较新的协议基于 OAuth 构建，但解决了其在安全、隐私和用户体验方面的弱点。

对于医疗保健、金融服务和身份管理等高度敏感的应用程序，应大力考虑相互 TLS 和 WebAuthn 等协议来提供深度防御。即使对于消费者应用程序，使用 OpenID Connect 增强 OAuth 也有助于确保更好的用户身份和身份验证的完整性。请继续关注 APIRobots，了解有关这个令人兴奋的领域的更多见解和最新动态。不要错过 API 为您的业务带来的机会。立即通过 API Robots 和 API 开发机构 与我们联系，让我们一起释放 API 的全部潜力。