隐式流与授权码流：为什么隐式流已死？

授权码流和隐式流是 OAuth 2.0 中最常用的两种授权类型，使得 Web 应用程序可以实现安全高效的用户授权。两种流都实现了一种授权过程，允许用户在不直接暴露其凭证的情况下授予应用程序访问权限。隐式流最初是为了解决浏览器限制而开发的，但随着现代 Web 技术的出现，授权码流因其增强的安全功能已成为许多开发者的首选。

在本文中，我们将探究这两种授权类型的区别，并解释为什么你应该避免使用隐式流而选择授权码流。

什么是 OAuth 2.0？#

在我们深入了解这两种授权类型的细节之前，让我们先来了解什么是 OAuth 2.0 及其对现代 Web 应用程序的重要性。

当人们谈论 OAuth 时，我们通常指的是 OAuth 2.0，即“开放授权”，这是一种公认的协议，允许网站或应用程序在用户的授权下使用其他 Web 服务的资源。它于 2012 年继承了 OAuth 1.0，从此成为数码授权的广泛接受标准。OAuth 2.0 的设计目的是为用户提供受控访问，允许客户端应用程序获得特定权限与代表用户的资源互动，而无需透露用户的登录详情。

虽然主要用于 Web 环境中，OAuth 2.0 的框架也扩展到各种客户端形式。这包括基于浏览器的应用程序、服务器端 Web 应用程序、原生或移动应用程序，甚至是互联设备，详细描述了在这些平台上管理委托访问的方法。它引入了“授权类型”的概念，以定义客户端应用程序、用户和授权服务器之间的授权过程。这些授权类型用于确定客户端应用程序如何获得访问令牌以访问用户的资源。在 OAuth 2.0 中，最常见的授权类型有：

• 授权码：适用于所有类型的应用程序，尤其是服务器端 Web 应用程序，其中客户端应用程序可以通过授权码交换访问令牌并安全管理令牌。
• 隐式：一种简化的流程，设计用于基于浏览器的应用程序，没有安全的服务器组件。它是为了快速向客户端应用程序提供令牌而创建的，但由于安全性问题，现在已被广泛认为是废弃的。
• 资源所有者密码凭证：这种类型允许客户端应用程序直接请求并接收访问令牌，通过提交用户的凭证（用户名和密码）。由于客户端应用程序可以直接访问用户的凭证，该授权类型也被认为是废弃的，在所有情况下都应避免使用。
• 客户端凭证：用于机器对机器通信，其中应用程序本身是客户端。涉及应用程序向授权服务器进行身份验证，并请求访问令牌以访问其自身的资源或其他服务的资源。

什么是隐式流？#

隐式流是一种简化的 OAuth 2.0 流程，访问令牌在重定向 URI 中直接返回给客户端，不需要额外步骤来通过授权码交换令牌。最初设计用于因浏览器限制而无法对令牌端点进行服务器端请求的 Web 应用程序。

隐式流如何工作？#

1. 用户在客户端应用程序上点击按钮或链接以启动认证过程。
2. 客户端应用程序将用户重定向到授权服务器进行认证，包括所需的访问范围。
3. 授权服务器提示用户登录并授予客户端应用程序权限。
4. 在成功认证和授权后，授权服务器将用户的浏览器重定向回客户端指定的重定向 URI，访问令牌包含在 URL 片段中。
5. 客户端应用程序从 URL 片段中提取访问令牌，并使用它访问资源服务器上的用户资源。

隐式流的安全风险#

隐式流存在若干安全漏洞：

• 令牌暴露：访问令牌直接在 URL 片段中返回给客户端，可能容易被恶意方截取。这会导致访问令牌的潜在窃取和误用。
• CSRF 攻击：隐式流容易受到跨站点请求伪造（CSRF）的攻击，恶意网站可能会诱骗用户授予对其帐户的未授权访问。

由于这些安全问题，不再建议在现代 Web 应用程序中使用隐式流。相反，带有 PKCE（代码验证密钥）的授权码流是首选的安全用户授权方式。

什么是授权码流？#

另一方面，授权码流是更安全的 OAuth 2.0 流程，将授权过程分为两步：客户端应用程序首先从授权服务器获取授权码，然后将该代码交换为访问令牌。此过程最初为能够安全存储客户端凭证和管理访问令牌的服务器端 Web 应用程序而设计。随着 PKCE 扩展的引入，授权码流现在也可用于基于浏览器的应用程序。

私有客户端与服务器端组件的授权码流如何工作？#

1. 用户在客户端应用程序上点击按钮或链接以启动认证过程。
2. 客户端应用程序将用户重定向到授权服务器进行认证，包括所需的访问范围。
3. 授权服务器提示用户登录并授予客户端应用程序权限。
4. 在成功认证和授权后，授权服务器将授权码返回给客户端。
5. 客户端应用程序通过使用其客户端凭证对令牌端点进行服务器到服务器请求，安全地将授权码交换为访问令牌。
6. 授权服务器验证授权码和客户端凭证，并将访问令牌返回给客户端。
7. 客户端应用程序使用访问令牌访问资源服务器上的用户资源。

公共客户端与 PKCE 的授权码流如何工作？#

1. 用户在客户端应用程序上点击按钮或链接以启动认证过程。
2. 客户端应用程序生成代码验证器和代码质询。
3. 客户端应用程序将用户重定向到授权服务器，使用代码质询进行认证。
4. 授权服务器存储代码质询以备后验证。
5. 用户认证并批准对客户端应用程序的访问。
6. 授权服务器将授权码返回给客户端。
7. 客户端应用程序通过使用代码验证器对令牌端点进行服务器到服务器请求，交换授权码为访问令牌。
8. 授权服务器根据存储的代码质询验证授权码和代码验证器。
9. 授权服务器将访问令牌返回给客户端。
10. 客户端应用程序使用访问令牌访问资源服务器上的用户资源。

了解更多关于 PKCE 流程的信息。

隐式流与授权码流#

授权码流能否消除隐式流的安全问题？#

答案是肯定的：

授权码流引入了一个额外步骤，用于将授权码交换为访问令牌，这显著降低了令牌暴露的风险。

• 对于具有安全服务器端组件的私有客户端，客户端应用程序可以安全地使用其客户端凭证交换授权码为访问令牌。
• 对于没有安全服务器端组件的公共客户端，可以使用 PKCE 扩展来保护授权码交换过程。

如果你目前在业务中使用隐式流，切换到带有 PKCE 的授权码流可以为你和你的用户提供更好的安全性。我们理解迁移和管理身份系统可能既麻烦又昂贵，但增强的安全性和合规性的好处是值得付出的努力。