> OAuth（开放授权）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如基本消息，照片，联系人列表），而无需将**用户名**和**密码**提供给第三方应用，使得自己的所有资源暴露给第三方应用。 # 1. 应用场景 ## 1.1 第三方授权登录 用户借助微信认证登录黑马程序员网站，用户就不用单独在黑马程序员注册用户，怎么样算认证成功吗？黑马程序 员网站需要成功从微信获取用户的身份信息则认为用户认证成功，那如何从微信获取用户的身份信息？用户信息的 拥有者是用户本人，微信需要经过用户的同意方可为黑马程序员网站生成令牌，黑马程序员网站拿此令牌方可从微 信获取用户的信息。 * 1、 客户端请求第三方授权 用户进入黑马程序的登录页面，点击微信的图标以微信账号登录系统，用户是自己在微信里信息的资源拥有者。 点击“微信”出现一个二维码，此时用户扫描二维码，开始给黑马程序员授权。 * 2、 资源拥有者同意给客户端授权 资源拥有者扫描二维码表示资源拥有者同意给客户端授权，微信会对资源拥有者的身份进行验证， 验证通过后，微信会询问用户是否给授权黑马程序员访问自己的微信数据，用户点击“确认登录”表示同意授权，微信认证服务器会颁发一个授权码，并重定向到黑马程序员的网站。 * 3、 客户端获取到授权码，请求认证服务器申请令牌 此过程用户看不到，客户端应用程序请求认证服务器，请求携带授权码。 * 4、认证服务器向客户端响应令牌 微信认证服务器验证了客户端请求的授权码，如果合法则给客户端颁发令牌，令牌是客户端访问资源的通行证。 此交互过程用户看不到，当客户端拿到令牌后，用户在黑马程序员看到已经登录成功。 * 5、客户端请求资源服务器的资源 客户端携带令牌访问资源服务器的资源。 黑马程序员网站携带令牌请求访问微信服务器获取用户的基本信息。 * 6、资源服务器返回受保护资源 资源服务器校验令牌的合法性，如果合法则向用户响应资源信息内容。 **OAauth2.0包括以下角色：** **1、客户端（黑马）** 本身不存储资源，需要通过资源拥有者的授权去请求资源服务器的资源，比如：`Android`客户端、`Web`客户端（浏览器端）、微信客户端等。 **2、资源拥有者（用户）** 通常为用户，也可以是应用程序，即该资源的拥有者。 **3、授权服务器（也称认证服务器，微信认证服务）** 用于服务提供商对资源拥有的身份进行认证、对访问资源进行授权，认证成功后会给客户端发放令牌 （`access_token`），作为客户端访问资源服务器的凭据。本例为微信的认证服务器。 **4、资源服务器（微信服务）** 存储资源的服务器，本例子为微信存储的用户信息。 现在还有一个问题，服务提供商能允许随便一个客户端就接入到它的授权服务器吗？答案是否定的，服务提供商会 给准入的接入方一个身份，用于接入时的凭据: `client_id`：客户端标识 `client_secret`：客户端秘钥 因此，准确来说，授权服务器对两种`OAuth2.0`中的两个角色进行认证授权，分别是资源拥有者、客户端。 我们要做的就是将这两者进行连接起来 先到第三方平台资质审核，审核通过后（client_id,client_secret），用户去第三方平台授权登录后，就可以获取用户基本信息，完成登陆。 ## **1.2 oauth四种模式** 根据场景不同，oauth有四种模式 ### **1.2.1 授权码模式** #### 流程 > 说明：【A服务客户端】需要用到【B服务资源服务】中的资源 **第一步**：【A服务客户端】将用户自动导航到【B服务认证服务】，这一步用户需要提供一个回调地址，以备【B服务认证服务】返回授权码使用。 **第二步**：用户点击授权按钮表示让【A服务客户端】使用【B服务资源服务】，这一步需要用户登录B服务，也就是说用户要事先具有B服务的使用权限。 **第三步**：【B服务认证服务】生成授权码，授权码将通过第一步提供的回调地址，返回给【A服务客户端】。 > 注意这个授权码并非通行【B服务资源服务】的通行凭证。 **第四步**：【A服务认证服务】携带上一步得到的授权码向【B服务认证服务】发送请求，获取通行凭证`token`。 **第五步**：【B服务认证服务】给【A服务认证服务】返回令牌`token`和更新令牌`refresh token`。 #### 使用场景 授权码模式是`OAuth2`中最安全最完善的一种模式，应用场景最广泛，可以实现服务之间的调用，常见的微信，QQ等第三方登录也可采用这种方式实现。 ### **1.2.2 password模式** 1. client端自己本身有一套用户体系，在认证时需要带上自己的用户名和密码，以及客户端的client\_id,client\_secret。 2. accessToken所包含的权限是用户本身的权限，而不是客户端的权限。 3. 如果你的系统已经有了一套用户体系，每个用户也有了一定的权限，可以采用password模式；如果仅仅是接口的对接，不考虑用户，则可以使用client模式。 4. 不支持刷新token #### 流程 **第一步**：直接告诉【A服务客户端】自己的【B服务认证服务】的用户名和密码 **第二步**：【A服务客户端】携带【B服务认证服务】的用户名和密码向【B服务认证服务】发起请求获取 `token`。 **第三步**：【B服务认证服务】给【A服务客户端】颁发`token`。 ### 1.2.3 简化模式（implicit） #### 流程 > 说明：简化模式中没有【A服务认证服务】这一部分，全部有【A服务客户端】与B服务交互，整个过程不再有授权码，token直接暴露在浏览器。 **第一步**：【A服务客户端】将用户自动导航到【B服务认证服务】，这一步用户需要提供一个回调地址，以备【B服务认证服务】返回`token`使用，还会携带一个【A服务客户端】的状态标识`state`。 **第二步**：用户点击授权按钮表示让【A服务客户端】使用【B服务资源服务】，这一步需要用户登录B服务，也就是说用户要事先具有B服务的使用权限。 **第三步**：【 B服务认证服务】生成通行令牌`token`，`token`将通过第一步提供的回调地址，返回给【A服务客户端】。 #### 使用场景 适用于A服务没有服务器的情况。比如：纯手机小程序，`JavaScript`语言实现的网页插件等。 ### 1.2.4 client模式 #### 流程 > 仍需要client_id和secret > 说明：这种模式其实已经不太属于`OAuth2`的范畴了。A服务完全脱离用户，以自己的身份去向B服务索取`token`。换言之，用户无需具备B服务的使用权也可以。完全是A服务与B服务内部的交互，与用户无关了。 **第一步**：A服务向B服务索取`token`。 **第二步**：B服务返回`token`给A服务。 #### 使用场景 A服务本身需要B服务资源，与用户无关。 ## client配置