oauth2.0学习笔记（摘抄简化）

大量摘抄白话简明教程。

附：可以参考《RFC6749协议中文版及oauth2.0》文档

一、OAuth 白话简明教程 1.简述

http://www.cnblogs.com/Ceri/p/7673905.html

1、几个名词

先举个虚拟的例子：用户在 QQ 登录，然后授权千一网络社区使用，用户以 QQ 帐号身份在千一网络社区发布文章，同时将文章转发到 QQ 空间。

用户（User）：有些人又称资源拥有者（Resource Owner），我还是喜欢称用户，资源拥有者——文绉绉的。

用户代理（User Agent）：一般就是指浏览器，但不一定。

第三方应用（Third-party Application）：上面的例子中就是指千一网络。有些人又称客户端（Client），我不喜欢这样，因为称客户端，老是容易让人想到浏览器、用户终端。

授权服务器（Authorization Server）：上面的例子中就是指 QQ 登录服务器

资源服务器（Resource Server）：上面的例子中就是指 QQ 空间服务器。

2、OAuth 白话简明教程 2.授权码模式（Authorization Code）

重点细读

图中有三个红色的备注。

第一个红色备注参数解释如下：

client_id：就是第三方应用在授权服务器注册的 Id，比如现在千一网络要做 QQ 登录接口，都必须要先在 QQ 开放平台进行注册。

response_type：就是说你现在想干嘛，根据后面的流程，我们知道我们是想去获取 code 值，所以这里的值固定是“code”。

redirect_uri：前面不是提到授权服务器还要重定向回来么？重定向哪里呢？就是这个 URL。

scope：想要啥权限：可以读取 QQ 个人资料？可以发 QQ 空间？具体由提供 OAuth 的服务商（比如 QQ）来决定有哪些权限字符串。

state：随机字符串，可以省略。第三方应用可以指定一个随机字符串，一会儿授权服务器原封不动地把这个值传回来，第三方应用一验证——嗯，这个确实是我产生的随机字符串，这个确实是我发出的登录请求。

第二个红色备注参数解释如下：

code：授权服务器产生的一个临时随机码（一般 10 分钟内有效，使用一次后失效），第三方应用凭这个码去换正式的 Access Token。

state：就是第三方应用传来的 state，原封不动传回去。

第三个红色备注参数解释如下：

client_id：前面说过了。

grant_type：注意，现在是 grant_type，不是 response_type，就是说你想要用哪种模式，本文介绍的是授权码模式，所以这里就写“authorization_code”。

redirect_uri：与前面的保持一致，据说服务器除了验证 code，也要验证这个是否与之前的一致（图上没画这一流程）。

code：前面提到过的临时随机码。

code 相当于临时令牌，Access Token 相当于长期令牌（时间由授权服务器决定），那么为什么要用临时令牌换长期令牌呢？直接给长期令牌不好么？

（令牌，名字多高大上，但其实就是一个字符串，不过数据类型虽简单，但内容很有价值，就像银行卡密码。）

要说明的是用 code 换 Access Token 并不是通过用户代理（用户代理通常是浏览器），而是第三方应用的后台代码直接向授权服务器请求的（C# 中可用 WebRequest、WebClient），用户代理并不知道 Access Token 的值。这样做的好处是避免在用户代理上留下历史记录，也避免用户端中了木马后泄露 Access Token 值。

传输安全

肯定得用 HTTPS，否则 Access Token 这种机密都被探听了（纵然没有经过用户代理，但能不保证第三方应用和授权服务器之间没人“偷听”）。

之前说过，各大公司在应用 OAuth 时有所不同，举点例呢？

我们在各大开放平台注册时，一般都有 app_id、app_secret，app_id 对应 client_id，app_secret 前面没有提，code 换 Access Token 时，有些公司要求参数中把 app_secret 也带上，有些公司却用签名（将 app_secret 混合在参数值中进行散列运算）的方式来实现。

有些就拿 Access Token 去资源服务器使用，有些却要求用 Access Token 换一个叫 Token 的东西，然后用 Token 去使用。

各大公司对参数名称的确定也不一定相同。

3、OAuth 白话简明教程 3.客户端模式（Client Credentials）

客户端模式，在我看来，并不是 OAuth 的初衷。客户端模式要解决什么样的问题呢？

举例：有一个服务商提供了很多资源，天气、股票、火车时刻……如果这个服务商大方点，人人都可以抓取这些资源，也简单了，可是这个服务商要采用认证机制，只有认证了的第三方应用才可以使用这些资源。

所以这个服务商做了一个授权服务器，第三方应用纷纷在这上面注册，拿到了各自的 app_id、app_secret。按理说第三方应用在取天气时把 app_id、app_secret 传给天气服务器，然后天气服务器向授权服务器验证 app_id、app_secret，验证成功就返回天气，也能实现需求。

发现没，到这里都在提第三方应用、授权服务器、资源服务器（上面提到的天气服务器就是一个资源服务器），并没有提用户，这就是 OAuth 的客户端模式。

可以看出客户端模式完全就是授权码模式的下半部分，app_secret相当于授权服务器返回的code，直接用，不用用户登录去获取.只需要对客户端（第三方程序）授权，不用对第三方程序中的用户挨个授权。

4、 还有两个模式真不常用，说一下就行。

简化模式

直接把 Access Token 发送到用户代理（用户代理通常是浏览器），用户能够看到 Access Token。其他形式是把access token放在千一网络的后台使用。放浏览器处有被盗用风险。

密码模式

用户把用户名和密码发送给第三方应用，第三方应用拿着用户名和密码去授权服务器校验。也就是说千一网络拿着用户的qq账户密码去访问qq登录授权服务器，一般不可行。QQ不会将用户密码随意的暴露给千一网络。

敢这么做的，要么第三方应用和授权服务器是同一家公司，要么第三方应用是个非常令人依赖的大公司。

二、谈谈基于OAuth 2.0的第三方认证 [上篇]

OAuth 2.0中的Authorization Grant代表一种中间凭证（Intermediate Credential），它代表了资源拥有者针对客户端应用获取目标资源的授权。OAuth 2.0定义了如下4种Authorization Grant类型，我们也可以利用定义其中的扩展机制定制其他类型的Authorization Grant。Authorization Grant的类型体现了授权采用的方式以及Access Token的获取机制。

Implicit 隐式认证：它代表一种“隐式”授权方式，即客户端在取得资源拥有者（最终用户）授权的情况下直接获取Access Token，而不是间接地利用获取的Authorization Grant来取得Access Token。换句话说，此种类型的Authorization Grant代表根本不需要Authorization Grant中间凭证，那么上面介绍的“Three-Legged OAuth”变成了“Two-Legged OAuth”。省略这些步骤。

Authorization Code 授权码认证：这是最为典型的Authorization Grant，客户端应用在取得资源拥有者授权之后会从授权服务器得到一个Authorization Code作为Authorization Grant。在它获取寄宿于资源服务器中的目标资源之前，需要利用此Authorization Code从授权服务器获取Access Token。

Resource Owner Password Credentials 用户名密码认证：第三方应用直接拿资源拥有者的凭证直接作为获取Access Token的Authorization Grant。这种Authorization Grant类型貌似与OAuth设计的初衷向违背。

就是上文中的密码模式，不常用。

用户把用户名和密码发送给第三方应用，第三方应用拿着用户名和密码去授权服务器校验。也就是说千一网络拿着用户的qq账户密码去访问qq登录授权服务器，一般不可行。QQ不会将用户密码随意的暴露给千一网络。

敢这么做的，要么第三方应用和授权服务器是同一家公司，要么第三方应用是个非常令人依赖的大公司。

Client Credentials 客户端认证：客户端（第三方程序）应用自身的凭证（app_id,app_secret，不需要用户登录，只需要用这个第三方程序）直接作为它用于获取Access Token的Authorization Grant。这种类型的Authorization Grant适用于客户端应用获取属于自己的资源，换句话说客户端应用本身相当于资源的拥有者。例如，在天气预报开放平台上注册个程序，获得app_id和app_secret，以后拿这两个参数就可以获取天气预报服务器的access Token.