为什么大厂都用OAuth 2.0？一文带你深入学习OAuth 2.0-优快云博客

本文链接：https://blog.youkuaiyun.com/wcblog/article/details/148613233

OAuth 2.0的原理及流程详解

在当今数字化时代，互联网应用之间的交互日益频繁，用户常常需要在不同的应用中共享自己的资源或数据。然而，直接将用户名和密码提供给第三方应用存在巨大的安全风险。OAuth 2.0 应运而生，它是一个开放标准的授权框架，旨在解决不同应用之间的授权问题，让用户能够安全地授权第三方应用访问自己的资源，同时又无需暴露自己的敏感信息，如密码。

一、OAuth 2.0 的核心概念

（一）角色定义

资源所有者（Resource Owner）：通常是用户，拥有受保护的资源，如用户的照片、联系人信息、邮件等，并有权决定是否将这些资源授权给第三方应用访问。
客户端（Client）：即第三方应用，它需要访问资源所有者的资源，以提供特定的服务或功能。例如，一个健身应用想要获取用户在健康数据平台上的运动数据，这个健身应用就是客户端。
授权服务器（Authorization Server）：负责验证资源所有者的身份，并决定是否批准客户端对资源的访问请求。同时，在授权成功后，向客户端颁发访问令牌。常见的授权服务器有 Google Identity Platform、Facebook Login 等。
资源服务器（Resource Server）：存储资源所有者的受保护资源，它会验证客户端提供的访问令牌的有效性，并根据令牌的权限决定是否允许客户端访问相应的资源。资源服务器和授权服务器在很多情况下可以是同一实体，比如一些大型互联网公司的用户系统。

（二）访问令牌（Access Token）

访问令牌是 OAuth 2.0 中最重要的概念之一，它是客户端访问受保护资源的凭证。授权服务器在用户授权后会颁发访问令牌给客户端，客户端在后续请求资源服务器时，需要携带该令牌。访问令牌通常是一个字符串，它包含了客户端访问资源的权限信息，以及令牌的有效期等元数据。资源服务器会对访问令牌进行验证，只有验证通过的令牌才能被用来访问相应的资源。

（三）刷新令牌（Refresh Token）

刷新令牌是 OAuth 2.0 提供的一种机制，用于在访问令牌过期后，客户端能够无需用户再次授权，直接获取新的访问令牌。当授权服务器颁发访问令牌时，通常也会同时颁发一个刷新令牌给客户端。刷新令牌的有效期一般比访问令牌长，并且刷新令牌不能直接用于访问资源，它只能用于向授权服务器请求新的访问令牌。

二、OAuth 2.0 的授权模式

OAuth 2.0 定义了四种授权模式，分别是授权码模式（Authorization Code Grant）、隐式模式（Implicit Grant）、密码模式（Resource Owner Password Credentials Grant）和客户端凭证模式（Client Credentials Grant）。

流程类型	适用场景	安全性	典型应用
授权码流程	有服务器端的应用	高（推荐）	Web 应用、移动应用后端
隐式流程	纯前端应用（无服务器）	中（不推荐）	单页应用（需配合其他安全措施）
客户端凭据流程	客户端自身的权限	中	后台服务间的 API 调用
资源所有者密码	信任的客户端	低（仅用于特殊场景）	命令行工具、设备固件更新

每种模式都有其适用的场景和特点，下面重点介绍最为常用且安全性较高的授权码模式。

三、授权码模式流程详解

授权码模式适用于有后端的 Web 应用，其流程涉及资源所有者、客户端、授权服务器和资源服务器之间的多次交互，通过多个步骤确保授权过程的安全性和可靠性。
在这里插入图片描述

（一）第一步：客户端引导用户到授权服务器进行授权

客户端（A 网站）需要在其应用界面上提供一个明显的授权链接或按钮，当用户点击该链接或按钮时，会触发浏览器跳转到授权服务器（B 网站）的授权端点。跳转的 URL 中包含了一系列关键参数，这些参数用于向授权服务器传递客户端的相关信息和授权请求的细节。

https://b.com/oauth/authorize?
  response_type=code&
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL&
  scope=read

response_type=code：明确告知授权服务器，客户端期望获得的授权响应类型是授权码。这是授权码模式的核心标识，授权服务器根据这个参数确定按照授权码模式的流程进行处理。
client_id=CLIENT_ID：CLIENT_ID 是客户端在授权服务器上注册时获得的唯一标识，用于让授权服务器识别是哪个客户端在发起授权请求。授权服务器可以根据这个标识查询客户端的相关配置信息，如客户端的名称、重定向 URI 白名单等。
redirect_uri=CALLBACK_URL：CALLBACK_URL 是客户端指定的重定向 URI，当用户在授权服务器完成授权操作后，授权服务器会将用户重定向回这个 URI。客户端需要在授权服务器上预先注册这个 URI，以确保安全性，防止恶意应用伪造重定向地址。
scope=read：scope 参数用于指定客户端请求的授权范围。这里的“read”表示客户端只请求读取资源的权限，不同的应用场景下，scope 可以有多种取值，如“write”（写入权限）、“delete”（删除权限）等，也可以是多个权限的组合，如“read write”。

（二）第二步：用户在授权服务器进行授权操作

当用户跳转到授权服务器（B 网站）后，授权服务器首先会要求用户进行登录操作（如果用户尚未登录），以确认用户的身份。登录成功后，授权服务器会向用户展示一个授权页面，该页面会明确告知用户客户端（A 网站）正在请求访问哪些资源以及具有哪些权限。例如，页面可能会显示“A 网站想要访问你的联系人信息和照片，你是否同意？”。

用户在授权页面上可以选择同意或拒绝授权请求。如果用户点击同意授权，授权服务器会根据客户端在请求中提供的 redirect_uri 参数，将用户重定向回客户端指定的回调地址。在重定向的过程中，授权服务器会在 URL 中附加一个授权码（authorization code），如下所示：

https://a.com/callback?code=AUTHORIZATION_CODE

这里的 AUTHORIZATION_CODE 就是授权码，它是一个临时的、一次性的凭证，具有较短的有效期。授权码只能被使用一次，用于向授权服务器换取访问令牌。

（三）第三步：客户端使用授权码换取访问令牌

客户端（A 网站）的后端在接收到包含授权码的回调请求后，会提取出授权码，并使用该授权码向授权服务器（B 网站）的令牌端点发起请求，以获取访问令牌。这个请求必须在客户端的后端服务器上进行，因为请求中需要包含客户端的 client_secret 参数，这是客户端在授权服务器上注册时获得的一个保密密钥，用于验证客户端的身份，不能暴露在前端。

https://b.com/oauth/token?
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET&
  grant_type=authorization_code&
  code=AUTHORIZATION_CODE&
  redirect_uri=CALLBACK_URL

client_id=CLIENT_ID和client_secret=CLIENT_SECRET：这两个参数用于授权服务器验证客户端的身份。只有提供正确的 client_id 和 client_secret，授权服务器才会认为请求是合法的。
grant_type=authorization_code：明确告知授权服务器，本次请求采用的授权方式是授权码模式。
code=AUTHORIZATION_CODE：即上一步从回调 URL 中获取的授权码，授权服务器会验证该授权码的有效性和合法性，包括检查授权码是否过期、是否已被使用等。
redirect_uri=CALLBACK_URL：与第一步请求中提供的 redirect_uri 保持一致，用于授权服务器进一步验证请求的合法性，防止 CSRF（跨站请求伪造）攻击。

（四）第四步：授权服务器颁发访问令牌和刷新令牌

授权服务器（B 网站）在接收到客户端的令牌请求后，会对请求中的参数进行全面验证。如果验证通过，授权服务器会生成访问令牌和刷新令牌（如果配置了颁发刷新令牌），并将它们返回给客户端。返回的数据通常以 JSON 格式呈现，如下所示：

{
  "access_token":"ACCESS_TOKEN",
  "token_type":"bearer",
  "expires_in":2592000,
  "refresh_token":"REFRESH_TOKEN",
  "scope":"read",
  "uid":100101,
  "info":{...}
}

access_token":“ACCESS_TOKEN”：这是客户端用于访问资源服务器的关键凭证，客户端在后续请求资源服务器的受保护资源时，需要在请求头中携带该访问令牌。
token_type":“bearer”：表示令牌的类型为 Bearer Token，这是 OAuth 2.0 中最常用的令牌类型。客户端在使用令牌时，需要按照这种类型的规范进行操作，通常是在请求头中添加“Authorization: Bearer <ACCESS_TOKEN>”。
expires_in":2592000：指定了访问令牌的有效期，单位通常是秒。这里的 2592000 秒表示 30 天，当访问令牌过期后，客户端需要使用刷新令牌获取新的访问令牌。
refresh_token":“REFRESH_TOKEN”：如果授权服务器配置了颁发刷新令牌，客户端会收到该刷新令牌。在访问令牌过期后，客户端可以使用刷新令牌向授权服务器请求新的访问令牌，而无需用户再次进行授权操作。
scope":“read”：返回了该访问令牌所具有的权限范围，与客户端最初请求的授权范围一致。
uid":100101：通常是资源所有者在授权服务器上的唯一标识，客户端可以根据这个标识来区分不同用户的资源访问权限。
info":{…}：可能包含一些额外的信息，如用户的基本信息、令牌的颁发时间等，具体内容由授权服务器根据配置决定。

（五）第五步：客户端使用访问令牌访问资源服务器

客户端（A 网站）在获取到访问令牌后，就可以使用该令牌向资源服务器请求访问受保护的资源。客户端在发送请求时，需要在请求头中添加“Authorization: Bearer <ACCESS_TOKEN>”，以表明自己的身份和权限。资源服务器在接收到请求后，会提取访问令牌，并向授权服务器或本地的令牌验证机制发送验证请求，检查令牌的有效性、权限范围以及是否过期等。如果验证通过，资源服务器会根据请求返回相应的资源数据；如果验证失败，资源服务器会返回错误信息，拒绝客户端的请求。

四、OAuth 2.0 授权码模式的安全性保障

授权码模式通过多个环节的设计来保障授权过程的安全性：

授权码的使用：授权码是一个临时的、一次性的凭证，且只能由客户端的后端服务器使用，降低了授权码被窃取后造成的风险。即使授权码被截获，由于其只能使用一次且有较短的有效期，攻击者也很难利用它获取访问令牌。
client_secret 的保护：客户端的 client_secret 只在后端服务器与授权服务器通信时使用，不会暴露在前端，防止了恶意应用通过前端获取 client_secret 进行非法授权。
重定向 URI 的验证：授权服务器会验证客户端请求中的 redirect_uri 是否与注册的一致，防止恶意应用伪造重定向地址，进行 CSRF 攻击。
访问令牌和刷新令牌的保护：访问令牌和刷新令牌在传输过程中通常采用 HTTPS 协议进行加密传输，防止被中间人窃取。同时，刷新令牌的使用也需要客户端提供 client_secret 进行身份验证，进一步保障了其安全性。

五、总结

OAuth 2.0 的授权码模式通过一系列严谨的流程和安全机制，实现了用户对第三方应用访问自己资源的安全授权。它在不同角色之间的交互过程中，充分考虑了安全性和易用性，既保护了用户的敏感信息，又让第三方应用能够方便地获取资源访问权限。理解 OAuth 2.0 的原理和授权码模式的流程，对于开发安全可靠的互联网应用至关重要，也为后续深入探讨 OAuth 2.0 在不同场景下的应用和扩展奠定了坚实的基础。