【OAuth2】用户授权第三方应用，流程详解及模式

一、讲述

1. 是什么

2. 工作流程

3. OAuth2的好处

二、协议流程

1. 应用场景

2. 实例

3. 安全体现

4. 角色

5. 认证流程

三、授权模式

1. 授权码模式

2. 简化(隐式)模式

3. 密码模式

4. 客户端模式

每篇一获

一、讲述

1. 是什么

OAuth（开放授权）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。OAuth通过提供一个授权令牌而不是用户名和密码来访问他们存储在服务提供者的数据。

OAuth的核心是它的授权框架，允许基于代表资源所有者进行授权的访问控制。在OAuth术语中，资源所有者通常是指用户，而第三方应用则被称为客户端（Client），用户的数据被保存在服务提供者（Service Provider）处。

OAuth 1.0和OAuth 2.0是最常见的版本，它们在协议流程和安全性方面有所不同。OAuth 2.0是最新的版本，它提供了更多的灵活性和更强的安全性。

2. 工作流程

OAuth 2.0的工作流程通常包括以下几个步骤：

注册应用：在想要访问用户数据的服务提供者上注册你的应用。注册成功后，你会获得一个客户端ID和一个客户端密钥，这些是你的应用与服务提供者通信的凭证。
获得授权：当用户使用你的应用并同意授权时，你的应用会将用户重定向到服务提供者的授权页面。用户登录他们的账户并同意授权后，服务提供者会发放一个授权码给客户端。
交换令牌：客户端（应用）使用上一步获得的授权码，向服务提供者的令牌端点发送请求以交换访问令牌。在这一步中，客户端需要验证其身份，通常是通过提供客户端ID和客户端密钥来完成。
访问资源：客户端（应用）使用访问令牌向服务提供者请求用户的资源。服务提供者验证访问令牌的有效性，如果验证成功，服务提供者将向客户端提供请求的资源。

3. OAuth2的好处

在项目开发中，使用**OAuth2**主要有以下几个原因：

1. **安全性**：OAuth2提供了一种安全的方式来授权第三方应用访问用户的资源，而无需用户将用户名和密码直接提供给第三方应用。这大大降低了用户信息被泄露的风险。

2. **简便性**：用户只需要在一个地方（通常是一个中心化的身份提供者）进行身份验证，就可以访问所有支持OAuth2的应用，无需为每个应用单独注册和登录。

3. **灵活性**：OAuth2支持多种授权模式，可以满足不同类型的应用和场景的需求。例如，对于Web应用，可以使用授权码模式；对于移动应用，可以使用隐式授权模式；对于后台服务，可以使用客户端凭证模式。

4. **标准化**：OAuth2是一个开放的标准，被广泛接受和使用。使用OAuth2可以使应用更容易集成到其他系统中，提高开发效率。

因此，使用OAuth2可以帮助我们在保证安全性的同时，提高用户体验和开发效率。

二、协议流程

1. 应用场景

**OAuth2.0**是一个授权框架，它允许第三方应用在用户的许可下访问其私有资源。以下是一些OAuth2.0的应用场景：

1. **Web应用授权**：这是最常见的OAuth2.0应用场景。在这种情况下，用户通过浏览器访问一个Web应用，该应用需要访问用户在另一个服务上的资源（例如，访问用户在Google Drive上的文件）。Web应用通过OAuth2.0获取用户的授权，然后使用该授权访问用户的资源。

2. **移动应用授权**：在这种情况下，用户在移动设备上使用一个应用，该应用需要访问用户在另一个服务上的资源（例如，访问用户在Facebook上的朋友列表）。移动应用通过OAuth2.0获取用户的授权，然后使用该授权访问用户的资源。

3. **后台服务授权**：在这种情况下，一个后台服务需要访问另一个服务上的资源，但没有用户直接参与。例如，一个服务器可能需要访问Google Cloud Storage上的数据。在这种情况下，后台服务可以使用OAuth2.0的客户端凭证模式获取授权。

4. **设备授权**：在这种情况下，一个设备（例如，智能电视或游戏控制台）需要访问用户在另一个服务上的资源。因为设备可能没有方便的方式让用户输入用户名和密码，所以可以使用OAuth2.0的设备授权流程获取用户的授权。

2. 实例

原生app授权：app登录请求后台接口，为了安全认证，所有请求都带token信息，如果登录验证、请求后台数据。
前后端分离单页面应用：前后端分离框架，前端请求后台数据，需要进行oauth2安全认证
第三方应用授权登录，比如QQ，微博，微信的授权登录。(本系列课程应用场景讲解)

步骤解读：

第1步：浏览器打开Gitee码云，点击微信方式授权登录，重定向到微信授权服务页面等待获取授权码；

第2步：用户打开手机登录微信扫描“二维码”，点击“允许”授权，将重定向到客户端（Gitee）应用提供的URI；

第3步：客户端（Gitee）使用上一步获取的授权码，向微信授权服务器申请令牌（Token）；

第4步：微信授权服务器对客户端（Gitee）进行认证以后，确认无误，同意发放令牌；

第5步：客户端使用令牌向资源服务器（微信）申请获取资源；

第6步：资源服务器（微信）确认令牌无误后，同意向客户端开放资源；

3. 安全体现

在项目开发中，**OAuth2**的安全性主要体现在以下几个方面：

1. **用户凭证保护**：OAuth2允许用户授权第三方应用访问其资源，而无需将用户名和密码直接提供给第三方应用。这意味着用户的登录凭证不会被泄露给可能存在安全风险的第三方。

2. **访问令牌**：OAuth2使用访问令牌（Access Token）来代表用户的授权。这些令牌是短期的，并且可以被撤销，这意味着即使令牌被盗，攻击者也只能在有限的时间内访问用户的资源。

3. **权限限制**：OAuth2允许用户选择授权第三方应用访问其资源的范围。例如，用户可以选择只授权应用访问其公开的个人信息，而不授权访问其私人信息。

4. **刷新令牌**：对于需要长期访问用户资源的应用，OAuth2提供了刷新令牌（Refresh Token）。刷新令牌可以用来获取新的访问令牌，而无需用户重新授权。这意味着即使访问令牌被盗，攻击者也无法获取刷新令牌，从而无法长期访问用户的资源。

5. **安全传输**：OAuth2要求所有的通信都必须通过安全的HTTPS协议进行，以防止令牌在传输过程中被窃取。

4. 角色

在OAuth2.0协议中，主要定义了以下几种角色：

资源所有者（Resource Owner）：通常是指用户，他们拥有可以通过OAuth2.0访问的资源。资源所有者可以授权客户端访问他们在资源服务器上的受保护资源。
客户端（Client）：通常是指第三方应用，它代表资源所有者向资源服务器请求访问受保护资源的权限。客户端需要得到资源所有者的授权，并通过授权服务器获取访问令牌。
授权服务器（Authorization Server）：它负责验证资源所有者的身份，并向客户端发放访问令牌。授权服务器是OAuth2.0协议中的关键角色，它保证了资源的安全访问。
资源服务器（Resource Server）：它托管资源所有者的受保护资源。资源服务器可以接受和响应来自客户端的受保护资源请求，但前提是客户端必须拥有有效的访问令牌。
用户代理（User Agent）：在OAuth2.0中，用户代理通常指的是用户使用的浏览器或其他类型的客户端软件。用户代理在OAuth2.0的授权流程中起到了重要的作用。
第三方应用（Third-Party Application）：在OAuth2.0中，第三方应用通常被视为客户端（Client）。这是一个外部应用，它希望获取对资源所有者（通常是用户）在资源服务器上的受保护资源的访问权限。为了实现这一点，第三方应用需要通过授权服务器获取资源所有者的授权，并获得一个访问令牌。然后，第三方应用可以使用这个访问令牌向资源服务器请求访问受保护的资源。

这些角色共同构成了OAuth2.0的授权框架，使得用户可以安全、有效地将他们的资源授权给第三方应用访问。

5. 认证流程

（A）用户打开客户端以后，客户端要求用户给予授权。

（B）用户同意给予客户端授权。

（C）客户端使用上一步获得的授权，向认证服务器申请令牌。

（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。

（E）客户端使用令牌，向资源服务器申请获取资源。

（F）资源服务器确认令牌无误，同意向客户端开放资源。

三、授权模式

OAuth的优势在于它提供了一种安全的授权方式，而不需要用户分享他们的登录凭据，减少了用户凭据被第三方应用滥用的风险。同时，用户可以更精细地控制第三方应用对其私有资源的访问权限，并且可以随时撤销这些权限。

1. 授权码模式

（Authorization Code Grant）：适用于有自己服务器的应用，可以安全存储客户端密钥。

**授权码模式（Authorization Code Grant）**是OAuth2.0中最常用的授权模式，主要适用于服务器端的Web应用。

适用场景：当第三方应用需要访问用户在资源服务器上的受保护资源时，可以使用授权码模式。这种模式特别适用于那些可以安全地存储客户端密钥和访问令牌的服务器端Web应用。

主要流程：

用户访问第三方应用，第三方应用引导用户到授权服务器进行登录。
用户在授权服务器上登录并授权第三方应用访问其资源。
授权服务器将用户重定向回第三方应用，并在重定向的URL中附带一个授权码。
第三方应用从重定向的URL中获取授权码，并使用授权码和其客户端密钥向授权服务器请求访问令牌。
授权服务器验证授权码和客户端密钥，如果验证成功，则向第三方应用发放访问令牌。
第三方应用使用访问令牌向资源服务器请求访问用户的资源。

这种模式的优点是，访问令牌永远不会直接暴露给用户代理（例如浏览器），而是安全地存储在服务器端。这大大降低了访问令牌被盗用的风险。

2. 简化(隐式)模式

（Implicit Grant）：适用于无法安全存储客户端密钥的客户端，如基于浏览器或移动应用的客户端。

简化模式不通过第三方应用程序的服务器，直接在浏览器中向授权服务器申请令牌，跳过了"授权码"这个步骤，所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。

这种方式把令牌直接传给前端，是很不安全的。因此，只能用于一些安全要求不高的场景，并且令牌的有效期必须非常短，通常就是会话期间（session）有效，浏览器关掉，令牌就失效了。

适用场景：当第三方应用无法安全地存储客户端密钥和访问令牌时，可以使用简化模式。这种模式特别适用于运行在浏览器中的客户端应用，因为这些应用无法安全地存储敏感信息。

主要流程：

用户访问第三方应用，第三方应用引导用户到授权服务器进行登录。
用户在授权服务器上登录并授权第三方应用访问其资源。
授权服务器将用户重定向回第三方应用，并在重定向的URL的片段部分（#后面的部分）中附带一个访问令牌。
第三方应用从重定向的URL的片段部分中获取访问令牌，并使用该令牌访问用户的资源。

请注意，由于访问令牌直接暴露给用户代理（浏览器），所以简化模式的安全性较低。因此，现在更推荐使用授权码模式配合PKCE（Proof Key for Code Exchange）来保护前端应用。

3. 密码模式

（Resource Owner Password Credentials Grant）：适用于用户对客户端高度信任的情况，用户将直接在客户端输入用户名和密码。

如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）。

在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而授权服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。

适用场景：当用户对第三方应用有高度的信任，例如该应用是由服务提供商自己开发的，用户可以直接将用户名和密码提供给这个应用，然后应用可以使用这些凭证获取访问令牌。

主要流程：

用户提供用户名和密码给第三方应用。
第三方应用使用这些凭证向授权服务器请求访问令牌。
授权服务器验证这些凭证，如果验证成功，就向第三方应用发放访问令牌。
第三方应用使用访问令牌访问用户在资源服务器上的受保护资源。

需要注意的是，由于这种模式涉及到用户直接将用户名和密码提供给第三方应用，因此存在一定的安全风险，只有在用户对第三方应用有高度信任的情况下才适用。

4. 客户端模式

（Client Credentials Grant）：适用于客户端直接访问它自己在服务提供者上的资源，而不是代表用户。

适用于没有前端的命令行应用，即在命令行下请求令牌。一般用来提供给我们完全信任的服务器端服务。

适用场景：当一个应用需要访问另一个应用的受保护资源，而不涉及任何用户交互时，可以使用客户端模式。例如，一个后台服务可能需要访问另一个后台服务的API。

主要流程：

客户端应用使用其自己的凭证（客户端ID和客户端密钥）向授权服务器请求访问令牌。
授权服务器验证这些凭证，如果验证成功，就向客户端应用发放访问令牌。
客户端应用使用访问令牌访问另一个应用的受保护资源。

每篇一获

学习OAuth2.0可以带来以下几个方面的收获：

1. **提高安全性**：OAuth2.0是一种安全的授权协议，它可以保护用户的敏感信息，如密码和访问令牌，不被直接暴露给第三方应用。这对于提高应用的安全性非常重要。

2. **简化开发**：OAuth2.0提供了一种标准的方式来处理授权和身份验证。这意味着开发者不需要从头开始开发这些功能，可以直接使用现有的库和服务。

3. **提高用户体验**：通过OAuth2.0，用户可以使用他们已经拥有的账户（如Google或Facebook账户）来登录第三方应用，而无需创建新的账户。这可以大大提高用户的体验。

4. **促进互操作性**：OAuth2.0是一个开放的标准，被广泛应用于各种应用和服务中。通过使用OAuth2.0，您的应用可以更容易地与其他应用和服务进行集成。

5. **提高开发效率**：理解OAuth2.0的工作原理可以帮助开发者更有效地使用这个协议，从而提高开发效率。