OAuth2.0 基础介绍

一、应用场景

二、角色说明

三、OAuth2.0 概述

四、协议流程

五、四种受权模式

六、受权码模式

应用场景

这里以“简书”为例，网友但愿在简书的文章下留言，但须要先登陆。在登陆页面，提供多种方式登陆，例如：微博、微信、QQ帐户等。减小了网友注册并管理多个帐户的麻烦。但简书如何使用微博登陆，获取用户信息并确保其数据不被泄露，这时 OAuth2.0 派上用场。

角色说明

一、Resource Owner

资源拥有者，可以许可对受保护资源的访问权限的实体。当资源全部者是我的时，它被称为最终用户。
二、Resource Server

资源服务器，管理受保护资源的服务器，可以接收和响应使用访问令牌对受保护资源的请求。例如，微博的资源服务器。
三、Client                

第三方应用客户端，资源拥有者发起对受保护资源的请求的应用程序。例如：简书。
四、Authorization Server 

受权服务器，在成功验证资源拥有者且得到受权后颁发访问令牌给客户端的服务器。例如，微博的受权服务器。

OAuth2.0 概述

OAuth2.0 受权框架容许第三方应用获取对 HTTP 服务的有限的访问权限，既能够以资源全部者名义在资源全部者和 HTTP 服务之间进行容许的交互，也能够容许第三方应用以本身的名义进行访问。本规范取代并淘汰 RFC5849 中描述的 OAuth 1.0 协议。（摘自：https://github.com/jeansfish/RFC6749.zh-cn/blob/master/index.md）

协议流程

OAuth 2.0 的协议流程以下图，摘自 RFC6749。

上图是抽象的 OAuth 2.0 协议流程，描述了四种角色之间的交互，包括如下步骤：

• （A）客户端从资源全部者处请求受权。受权请求能够直接向资源全部者发起，或者更可取的是经过受权服务器做为中介间接发起。
• （B）客户端收到受权许可，这是一个表明资源全部者的受权的凭据，使用本规范中定义的四种许可类型之一或者使用扩展许可类型表示。受权许可类型取决于客户端请求受权所使用的方法以及受权服务器支持的类型。
• （C）客户端与受权服务器进行身份认证并出示受权许能够请求访问令牌。
• （D）受权服务器验证客户端身份并验证受权许可，如有效则颁发访问令牌。
• （E）客户端从资源服务器请求受保护资源并出示访问令牌进行身份验证。
• （F）资源服务器验证访问令牌，如有效则处理该请求。

客户端从资源全部者得到受权许可（步骤（A）和（B）所示）的更好方法是使用受权服务器做为中介，也就是受权码模式。

四种受权模式

客户端必须获得用户的受权（authorization grant），才能得到令牌（access token）。OAuth 2.0定义了四种受权方式。

• 受权码模式（authorization code）
• 简化模式（implicit）
• 密码模式（resource owner password credentials）
• 客户端模式（client credentials）

  受权码模式

受权码许可类型用于得到访问令牌和刷新令牌而且为受信任的客户端进行了优化。因为这是一个基于重定向的流程，客户端必须可以与资源全部者的用户代理（一般是Web浏览器）进行交互并可以接收来自受权服务器的传入请求（经过重定向）。

注：说明步骤（A）、（B）和（C）的直线由于经过用户代理而被分为两部分。
上图描述了受权码流程，包括如下步骤：

• （A）客户端经过向受权端点引导资源全部者的用户代理开始流程。客户端包括它的客户端标识、请求范围、本地状态和重定向URI，一旦访问被许可（或拒绝）受权服务器将传送用户代理回到该URI。
• （B）受权服务器验证资源拥有者的身份（经过用户代理），并肯定资源全部者是否授予或拒绝客户端的访问请求。
• （C）假设资源全部者许可访问，受权服务器使用以前（在请求时或客户端注册时）提供的重定向URI重定向用户代理回到客户端。重定向URI包括受权码和以前客户端提供的任何本地状态。
• （D）客户端经过包含上一步中收到的受权码从受权服务器的令牌端点请求访问令牌。当发起请求时，客户端与受权服务器进行身份验证。客户端包含用于得到受权码的重定向URI来用于验证。
• （E）受权服务器对客户端进行身份验证，验证受权代码，并确保接收的重定向URI与在步骤（C）中用于重定向（资源全部者的用户代理）到客户端的URI相匹配。若是经过，受权服务器响应返回访问令牌与可选的刷新令牌。

注：上述的应用场景使用了此模式，将在下一篇以示例说明。