OAuth2权限认证(第三方登录）——70%

黑马详细
参考文档

1.什么是OAuth2

OAuth 2.0是一种用于授权的开放标准，通常用于用户允许第三方应用访问其在另一个服务提供者上存储的信息，而无需将用户名和密码提供给第三方应用。OAuth 2.0协议允许用户授权第三方应用访问他们在另一个服务提供者上持有的资源，例如照片、视频、个人资料等。

Oauth2.0 的认证流程如下图所示

在OAuth 2.0流程中，涉及以下几个主要角色：

• 资源所有者：即用户，拥有资源的最终所有者，可以授权第三方应用访问他们的资源。

• 客户端：即第三方应用，希望访问用户的资源。

• 授权服务器：负责验证用户身份并颁发访问令牌（Access Token）给客户端。

• 资源服务器：存储用户资源的服务器，用来响应客户端的资源请求，并验证访问令牌的有效性。

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

• 客户端注册：客户端向授权服务器注册，并获取客户端ID和客户端密钥。

• 请求授权：客户端重定向用户到授权服务器，请求授权。用户登录并同意授权。

• 颁发授权码：授权服务器返回一个授权码给客户端。

• 获取访问令牌：客户端使用授权码向授权服务器请求访问令牌。

• 访问资源：客户端使用访问令牌向资源服务器请求用户资源。

OAuth 2.0的设计使得用户可以控制他们的数据，并允许他们选择分享数据给其他应用程序，同时避免了直接共享用户名和密码。这种方式提高了安全性和用户隐私保护，因此在许多Web应用程序和API中广泛应用。

2.四种授权方式

OAuth 2.0定义了四种授权方式：授权码模式、隐式授权模式、密码模式和客户端模式。

1.授权码模式 (authorization code)

授权码模式（authorization code）是功能最完整、流程最严密安全的授权模式。它的特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。

注意这种方式适用于那些有后端的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。

（1）流程：【A 服务客户端】需要用到【B 服务资源服务】中的资源
授权码模式流程如下：

• 1）用户访问客户端，【A 服务客户端】将用户自动导航到【B 服务认证服务】，这一步用户需要提供一个回调地址，以备【B 服务认证服务】返回授权码使用。

• 2）用户选择是否给予客户端授权。 用户点击授权按钮表示让【A 服务客户端】使用【B 服务资源服务】，这一步需要用户登录 B 服务，也就是说用户要事先具有 B 服务的使用权限。

• 3）假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码（每个用户的授权码不同）。
  ——【B 服务认证服务】生成授权码，授权码将通过第一步提供的回调地址，返回给【A 服务客户端】。注意这个授权码并非通行【B 服务资源服务】的通行凭证。

• 4）客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的 后台服务器 上完成的，对用户不可见。
  ——【A 服务认证服务】携带上一步得到的授权码向【B 服务认证服务】发送请求，获取通行凭证 token。

• 5）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。
  ——【B 服务认证服务】给【A 服务认证服务】返回令牌 token 和更新令牌 refresh token。

从上述的流程描述可知，只有第 2 步需要用户进行授权操作，之后的流程都是在客户端的后台和认证服务器后台之前进行"静默"操作，对于用户来说是无感知的。

（2）使用场景：授权码模式是 OAuth2 中最安全最完善的一种模式，应用场景最广泛，可以实现服务之间的调用，常见的微信，QQ 等第三方登录也可采用这种方式实现。

2.简化模式 (授权码隐藏式implicit)

有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）“隐藏式”（implicit）。
（1）流程
说明：简化模式中没有【A 服务认证服务】这一部分，全部有【A 服务客户端】与 B 服务交互，整个过程不再有
授权码，token 直接暴露在浏览器。

• 第一步：【A 服务客户端】将用户自动导航到【B 服务认证服务】，这一步用户需要提供一个回调地址，以备【B 服务认证服务】返回token使用，还会携带一个【A 服务客户端】的状态标识state。
• 第二步： 用户点击授权按钮表示让【A 服务客户端】使用【B 服务资源服务】，这一步需要用户登录B服务，也就是说用户要事先具有B服务的使用权限。
• 第三步：【B 服务认证服务】生成通行令牌token，token将通过第一步提供的回调地址，返回给【A 服务客户端】。
  （2）使用场景：适用于 A 服务没有服务器的情况。比如：纯手机小程序，JavaScript语言实现的网页插件等。

3.密码模式 (resource owner password credentials)——高信任

（1）流程

• 第一步： 直接告诉【A 服务客户端】自己的【B 服务认证服务】的用户名和密码
• 第二步：【A 服务客户端】携带【B 服务认证服务】的用户名和密码向【B 服务认证服务】发起请求获取 token。
• 第三步：【B 服务认证服务】给【A 服务客户端】颁发 token。

（2）使用场景
此种模式虽然简单，但是用户将 B 服务的用户名和密码暴露给了 A 服务，需要两个服务信任度非常高才能使用。

4.客户端模式 (client credentials)

凭证式（client credentials），适用于没有前端的命令行应用，即在命令行下请求令牌。
（1）流程
说明：这种模式其实已经不太属于 OAuth2 的范畴了。A 服务完全脱离用户，以自己的身份去向 B 服务索取 token。换言之，用户无需具备 B 服务的使用权也可以。完全是A服务与B服务内部的交互，与用户无关了。

• 第一步： A 服务向 B 服务索取 token。
• 第二步： B 服务返回 token 给 A 服务。

（2）使用场景：A 服务本身需要 B 服务资源，与用户无关。