OAuth2-简介

1. 简介

OAuth（开放授权）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。因此OAUTH是安全的。OAuth是Open Authorization的简写。

而OAuth2.0是OAuth协议的下一版本，但不向后兼容OAuth 1.0。 OAuth 2.0关注客户端开发者的简易性，同时为Web应用，桌面应用和手机，和起居室设备提供专门的认证流程。2012年10月，OAuth 2.0协议正式发布为RFC 6749 。

RFC文档

2. 认证过程

 +--------+                               +---------------+
 |        |--(A)- Authorization Request ->|   Resource    |
 |        |                               |     Owner     |
 |        |<-(B)-- Authorization Grant ---|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(C)-- Authorization Grant -->| Authorization |
 | Client |                               |     Server    |
 |        |<-(D)----- Access Token -------|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(E)----- Access Token ------>|    Resource   |
 |        |                               |     Server    |
 |        |<-(F)--- Protected Resource ---|               |
 +--------+                               +---------------+

上图中所涉及到的对象分别为：

Client 第三方应用，我们访问的应用就是一个Client。
Resource Owner 资源所有者，即用户。
Authorization Server 授权服务器，即提供第三方登录服务的服务器，如Github。
Resource Server 拥有资源信息的服务器，通常和授权服务器属于同一应用。

根据上图的信息，我们可以知道OAuth2的基本流程为：

第三方应用请求用户授权。
用户同意授权，并返回一个凭证（code）
第三方应用通过第二步的凭证（code）向授权服务器请求授权
授权服务器验证凭证（code）通过后，同意授权，并返回一个资源访问的凭证（Access Token）。
第三方应用通过第四步的凭证（Access Token）向资源服务器请求相关资源。
资源服务器验证凭证（Access Token）通过后，将第三方应用请求的资源返回。

3. 实例

看完OAuth的基本流程后，大家实际上对到底如何做OAuth验证还是不太清楚，同时，也会产生疑问，为什么需要两次获取凭证，而不是直接用户授权拿到凭证后就直接获取资源呢？这和OAuth的具体实现有关，让我们来看看OAuth2的具体实现吧。

我们以CSDN为例。

3.0 访问登陆页面

当用户希望使用第三方登录进行登录时，第三方应用会通过类似下图"快速登陆图标"的方式将用户引导至授权页面，为了和OAuth基本流程一致，我们将这一步定义为第0步。

3.0.5 用户身份验证

当我们点击Github的图标，我们会进入到Github应用下面，此时实际上进行了一次用户身份的验证，之前没有登录Github的用户需要输入Github的账号密码，已登录的用户Github会根据Session进行身份确认。此操作我们称为0.5步。接下来正式进入OAuth2的流程。

3.1 用户授权

用户身份确认后会进入下面这个页面，该页面由授权服务器提供，授权服务器会告诉用户该第三方在授权服务器中提交的相关信息（如果需要实现第三方登录功能，第三方应用需要向Github、微博等应用中提交应用的相关信息，不同服务可能会需要审核等不同的步骤），以及授权后第三方应用能够获取哪些资源。在Github中，最基础的认证可以访问用户的公共信息。如果用户同意授权，需要主动的点击【Authorize application】按钮。

3.2 返回用户凭证（code）

当用户点击按钮同意授权后，授权服务器将生成一个用户凭证（code），此时授权服务器如何将用户凭证（code）传递给第三方应用呢？

当我们向授权服务器提交应用信息时，通常需要填写一个redirect_uri，当我们引导用户进入授权页面时，也会附带一个redirect_uri的信息（如Sign in to GitHub · GitHub），当授权服务器验证两个URL一致时，会通知浏览器跳转到redirect_uri，同时，在redirect_uri后附加用户凭证（code）的相关信息，此时，浏览器返回第三方应用同时携带用户凭证（code）的相关信息。授权后访问的redirect_uri如下：

https://www.csdn.net/oauth/github/callback?code=9e3efa6cea739f9aaab2&state=XXX

这样，第二步返回用户凭证（code）就完成了。

3.3 请求授权服务器授权

从这一步开始，OAuth2 的授权将有两个重大变化的发生：

用户主动行为结束，用户理论上可以不需要再做任何主动的操作，作为第三方应用的我们可以在后台拿到资源服务器上的资源而对用户是不可见的，当用户的浏览器跳到下一个页面时，整个OAuth2的流程已经结束
浏览器端行为结束，从OAuth2 的基本流程可以看出，接下来的流程已经不需要和用户进行交互，接下来的行为都在第三方应用与授权服务器、资源服务器之间的交互。

我们知道浏览器端的行为实际上是不安全的，甚至安全凭证的传递都是通过URL直接传递的。但是由于用户凭证（code）不是那么敏感，其他攻击者拿到用户凭证（code）后依然无法获取到相应的用户资源，所以之前的行为是允许的。接下来我们看看服务器如何交互来安全的获得授权服务器授权。

要拿到授权服务器的授权，需要以下几个信息：

client_id 标识第三方应用的id，由授权服务器（Github）在第三方应用提交时颁发给第三方应用
client_secret 第三方应用和授权服务器之间的安全凭证，由授权服务器（Github）在第三方应用提交时颁发给第三方应用
code 第一步中返回的用户凭证redirect_uri 第一步生成用户凭证后跳转到第二步时的地址
state 由第三方应用给出的随机码

我们看到，上述信息还涉及到第三方应用的安全凭证（client_secret），因此要求OAuth要求该请求必须时POST请求，同时，还必须时HTTPS服务，以此保证获取到的验证凭证（Access Token）的安全性。

3.4 返回访问凭证（Access Token）

当授权服务器拿到第3步中的所有信息，验证通过后，会将Access Token返回给第三方应用。

3.5 向资源服务器请求相关资源

拿到验证凭证（Access Token）后，剩下的事情就很简单了，资源服务器会提供一系列关于用户资源的API，拿验证凭证（Access Token）访问相应的API即可，例如，在Github中，如果你想拿到用户信息，可以访问以下API：

GET https://api.github.com/user?access_token=...

注意，此时的访问不是通过浏览器进行的，而是服务器直接发送HTTP请求，因此其安全性是可以保证的。

3.6 返回资源

如果验证凭证（Access Token）是正确的，此时资源服务器就会返回资源信息，此时整个OAuth流程就结束了。