oauth2.0授权协议

参考文章

一.OAuth是什么？

OAuth的英文全称是Open Authorization，它是一种开放授权协议。OAuth目前共有2个版本，2007年12月的1.0版（之后有一个修正版1.0a）和2010年4月的2.0版，1.0版本存在严重安全漏洞，而2.0版解决了该问题，下面简单谈一下我对OAuth2.0的理解。

OAuth 是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。目前，OAuth 的最新版本为 2.0

OAuth 允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的网站（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth 允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息，而不需要分享他们的访问许可或他们数据的所有内容。

OAuth 2.0 的核心概念

resource owner：资源所有者，指终端的“用户”（user）
resource server：资源服务器，即服务提供商存放受保护资源。访问这些资源，需要获得访问令牌（access token）。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。如果，我们访问新浪博客网站，那么如果使用新浪博客的账号来登录新浪博客网站，那么新浪博客的资源和新浪博客的认证都是同一家，可以认为是同一个服务器。如果，我们是新浪博客账号去登录了知乎，那么显然知乎的资源和新浪的认证不是一个服务器。
client：客户端，代表向受保护资源进行资源请求的第三方应用程序。
authorization server：授权服务器，在验证资源所有者并获得授权成功后，将发放访问令牌给客户端。

二.OAuth2.0有什么用？

使用 OAuth 2.0 认证的的好处是显然易见的。你只需要用同一个账号密码，就能在各个网站进行访问，而免去了在每个网站都进行注册的繁琐过程。

简单概括，就是用于第三方在用户授权下调取平台对外开放接口获取用户相关信息。

OAuth引入了一个授权环节来解决上述问题。第三方应用请求访问受保护资源时，资源服务器在获准资源用户授权后，会向第三方应用颁发一个访问令牌(AccessToken)。该访问令牌包含资源用户的授权访问范围、授权有效期等关键属性。第三方应用在后续资源访问过程中需要一直持有该令牌，直到用户主动结束该次授权或者令牌自动过期。

三.认证授权过程

1、服务提供方，用户使用服务提供方来存储受保护的资源，如照片，视频，联系人列表。如QQ，微信

2、用户，存放在服务提供方的受保护的资源的拥有者。如QQ账号，微信账号

3、客户端，要访问服务提供方资源的第三方应用，通常是网站，如提供照片打印服务的网站。在认证过程之前，客户端要向服务提供者申请客户端标识。如：58同城，转转，豆瓣等可以使用QQ，微信账号登陆到这些第三方应用，还能看到微信中的好友。

四.详解OAuth2.0的授权码简化模式？

简单概括，就是用于第三方在用户授权下调取平台对外开放接口获取用户相关信息。

有三个关键字：第三方，用户，平台，关系如下图

看起来很简单对吧，其实授权的部分，要比上图展示的复杂一丢丢，下面来讲解一下授权的部分。

首先，有个问题，就拿微博平台来说吧，不能说随便一个第三方过来要求申请用户资源，微博平台就去用户那问一句是否授予权限吧，微博大哥能这么随便？所以第三方需要去想要请求的接口所在平台去报备一下，也就是告诉平台：我的xxx地址想要申请使用你的接口，可以吗？等平台审核通过之后，会下发一组appid+appkey，第三方持凭此就有资格去请求该平台的接口了。

第三方的准备工作做好了，下面就是具体运作流程了。（各大平台大多使用授权码模式——Authorization Code，因为它相比其它几种模式更为严谨，这里我仅分析一下该模式的原理）

这里我们假设一个场景，就是想用‘云打印’来打印自己‘微博的关注列表’。

简图如下：

详图如下：

在第②，④，⑥，⑧步中，分别用到了云打印在微博平台上获得的appid+appkey。关于每一步请求所需要的一系列参数这里就不一一列举了，官方文档非常详细，这里仅说明一下请求code和请求access token时重要的参数。

第④步参数：

response_type：指授权类型，必选，这里填固定值‘code’

client_id：指客户端id，必选，这里填在平台报备时获取的appid

redirect_uri：指重定向URI，可选

scope：指申请的权限范围，可选

state：指客户端当前状态，可选，若填了，则认证服务器会原样返回该值

第⑥步参数：

grant_type：指使用哪种授权模式，必选，这里填固定值‘authorization_code’

code：指从第⑤步获取的code，必选

redirect_uri：指重定向URI，必选，这个值需要和第④步中的redirect_uri保持一致

client_id：指客户端id，必选，这里填在平台报备时获取的appid

client_secret：指客户端密钥，必选，这里填在平台报备时获取的appkey

第⑧步参数：

access_token：指访问令牌，必选，这里填第⑦步获取的access_token

token_type：指令牌类型，必选，大小写不敏感，bearer类型 / mac类型

expires_in：指过期时间，单位秒，当其他地方已设置过期时间，此处可省略该参数

refresh_token：指更新令牌，可选，用即将过期token换取新token

scope：指权限范围，可选，第④步中若已申请过某权限，此处可省略该参数

到这里，OAuth2.0 授权码模式的认证过程就完成了，原理还算比较简单，就是较为繁琐，但是不算难。

注意：1.code时效较短，多为10s-10min，每次获得的code仅可使用一次，且code与client_id和redirect_uri有一一对应关系。

2.access token 有过期时间，多为10-15天。（过期处理有2种，请求用户重新授权/refreshToken，一般多用重新授权。）

3.在请求时，参数中包含重定向地址的，需要和第三方在授权方平台报备时留的地址前部一致

4.关于token_type的两种类型有什么区别，有个博客写的很详细，推荐阅读：www.cnblogs.com/XiongMaoMengNan/p/6785155.html

此处奉上找了好久才找到的OAuth2 RFC6749中文翻译：http://colobu.com/2017/04/28/oauth2-rfc6749/

本人能力有限，错误之处，敬请指正。

标准的认证过程
OAuth认证和授权的过程如下:
1、用户访问第三方网站网站，想对用户存放在服务商的某些资源进行操作。
2、第三方网站向服务商请求一个临时令牌。
3、服务商验证第三方网站的身份后，授予一个临时令牌。
4、第三方网站获得临时令牌后，将用户导向至服务商的授权页面请求用户授权，然后这个过程中将临时令牌和第三方网站的返回地址发送给服务商。
5、用户在服务商的授权页面上输入自己的用户名和密码，授权第三方网站访问所相应的资源。
6、授权成功后，服务商将用户导向第三方网站的返回地址。
7、第三方网站根据临时令牌从服务商那里获取访问令牌。
8、服务商根据令牌和用户的授权情况授予第三方网站访问令牌。
9、第三方网站使用获取到的访问令牌访问存放在服务商的对应的用户资源。