【OAuth 2.0】授权模式

概述

OAuth是一个关于授权( authorization )的开放网焰标准协议，简单理解就是一种授权机制，它是在客户端和资源所有者之间的授权层，用来分离两种不同的角色。在资源所有者同意并向客户端颁发令牌后，客户端携带令牌可以访问资源所有者的资源。OAuh2.0是OAuth协议的一个版本，2.0版本不兼容1.0版本，相当于1.0版本已经废弃。

OAuth就是一种授权机制.数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入今牌( token )，用来代替密码，供第三方应用使用。

OAuth 2.0 定义了四种不同的授权模式，用来获取访问令牌（Access Token）。这些模式适用于不同的使用场景，具体包括：授权码模式（Authorization Code）、隐藏式（Implicit）、密码凭证模式（Resource Owner Password Credentials） 和 客户端凭证模式（Client Credentials）。

一、授权码模式（Authorization Code Grant）

授权码模式 是最常用、最安全的一种授权方式，通常用于服务器端应用（Server-side Apps），它借助授权码来进行授权，避免直接暴露用户凭证。此模式分为两个步骤：首先客户端获取授权码（Authorization Code），然后使用授权码去获取访问令牌（Access Token）。

授权流程：

1. 用户访问客户端：用户尝试访问第三方应用（如 Web 或移动应用）。
2. 客户端重定向至授权服务器：客户端将用户重定向到 OAuth 授权服务器，并携带必要的参数（如 client_id、redirect_uri、response_type=code、scope=read 等）。
   • response_type=code 表示本次请求需要返回授权码
   • client_id 让第三方知道是谁在请求数据
   • redirect_uri 第三方处理完连接请求后的跳转地址
   • scope=read 表示授权的范围，read 表示对授权资源进行只读的操作
3. 用户登录并授权：用户在授权服务器上登录，并同意客户端访问其资源。
4. 授权服务器返回授权码：如果用户授权成功，授权服务器会将授权码通过重定向（通常到 redirect_uri）返回给客户端。
5. 客户端请求访问令牌：客户端将授权码、client_id、client_secret 发送到授权服务器的令牌端点（Token Endpoint），以交换访问令牌。
6. 授权服务器返回访问令牌：授权服务器验证授权码的有效性后，返回访问令牌（Access Token）。

示例流程图：

客户端 --------> 授权服务器 --------> 用户授权
               <--------  授权码  <--------
客户端 ------> 授权服务器（带授权码）
              <-------- 访问令牌  <--------

适用场景：

• 服务器端应用或 web 应用程序。
• 客户端可以安全存储 client_secret。
• 高安全性要求的场景。

二、隐藏式（Implicit Grant）

隐藏式授权 是专门为浏览器端应用（如单页应用，SPA）设计的授权模式。与授权码模式不同的是，隐藏式授权模式直接将访问令牌返回给客户端，而不是通过授权码交换令牌。它减少了一次与授权服务器的交互，使得流程更简化，但安全性较低，因为令牌直接暴露给用户代理（浏览器）。

授权流程：

1. 用户访问客户端：用户通过浏览器访问客户端应用。
2. 客户端重定向到授权服务器：客户端重定向用户到 OAuth 授权服务器，并发送请求（包含 client_id、redirect_uri、response_type=token 等参数）。
3. 用户登录并授权：用户在授权服务器上登录并授权客户端应用访问其资源。
4. 授权服务器返回访问令牌：授权服务器直接将访问令牌通过 URL Fragment（#access_token=…）返回给客户端，客户端可以在重定向后的 URL 中获取令牌。

安全性考虑：

由于令牌直接在浏览器中暴露，因此存在安全风险。通常会通过缩短令牌有效期、使用 HTTPS、加密存储等方法来增强安全性。

示例流程图：

客户端 --------> 授权服务器 --------> 用户授权
               <--------  访问令牌 <--------

适用场景：

• 单页应用程序（SPA）。
• 客户端无法安全存储 client_secret。
• 安全要求较低，或只需要短期访问令牌的场景。

相较于上述主要的区别就是少了一个授权码的过程。

三、密码凭证模式（Resource Owner Password Credentials Grant）

密码凭证模式 直接使用用户的用户名和密码进行授权。这种方式适用于客户端和资源所有者（用户）之间高度信任的场景，通常仅用于内部应用或用户直接向应用信任度非常高的情况。客户端直接使用用户的凭据向授权服务器请求访问令牌。

授权流程：

1. 用户向客户端提供第三方的用户名和密码：用户输入自己的用户名和密码。
2. 客户端请求访问令牌：客户端将用户名、密码、client_id、client_secret 发送到授权服务器的令牌端点。
3. 授权服务器验证用户凭据：授权服务器验证用户名和密码的正确性。
4. 授权服务器返回访问令牌：验证成功后，授权服务器返回访问令牌。

示例流程图：

客户端 ------> 授权服务器
              <-------- 访问令牌  <--------

安全性考虑：

密码凭证模式存在较高的安全风险，因为客户端必须收集和存储用户的用户名和密码。通常不推荐使用这种方式，除非客户端和用户之间有高度信任关系，并且在后台环境下运行。

适用场景：

• 客户端与用户之间有高度信任（如自有移动应用、内部应用）。
• 无法使用授权码模式的场景。
• 用户直接与客户端交互，客户端能够安全地处理用户凭据。

四、客户端凭证模式（Client Credentials Grant）

客户端凭证模式 是 OAuth 2.0 中最简单的一种授权方式，适用于服务器到服务器（Server to Server）的授权场景。客户端以自己的身份而不是用户的身份向授权服务器请求访问资源。

授权流程：

1. 客户端请求访问令牌：客户端使用其 client_id 和 client_secret 向授权服务器发送请求。
2. 授权服务器验证凭据：授权服务器验证客户端的凭据（client_id 和 client_secret）。
3. 授权服务器返回访问令牌：验证成功后，授权服务器返回访问令牌。

示例流程图：

客户端 ------> 授权服务器
              <-------- 访问令牌  <--------

安全性考虑：

• 客户端凭证模式的安全性依赖于客户端和授权服务器之间的信任。由于没有涉及用户身份验证，因此适用于访问应用程序自己的资源，而非用户资源。

适用场景：

• 服务器与服务器之间的通信，例如微服务之间的通信。
• 无用户交互的自动化系统。
• 客户端自己管理的资源，且无需用户授权的场景。

五、四种授权模式的比较

总结

• 授权码模式 是最常用、最安全的方式，适用于需要用户授权并且有服务器参与的应用。
• 隐藏式模式 是为单页应用设计的，简化了流程，但安全性较低。
• 密码凭证模式 允许用户直接向客户端提供凭据，适用于客户端和用户高度信任的场景。
• 客户端凭证模式 则用于服务器与服务器之间的授权，无需用户参与。