初之oAuth

       OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAUTH的授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此OAUTH是安全的。oAuth是Open Authorization的简写。oAuth的本质是一种开放协议，oAuth是一种第三方可以使用的OAUTH认证服务。它的特点是安全简易而又开放。OAUTH对应的语言时PHP、Javascrip、Java.

一、定义：

OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。同时，任何第三方都可以使用OAUTH认证服务，任何服务提供商都可以实现自身的OAUTH认证服务，因而OAUTH是开放的。业界提供了OAUTH的多种实现如PHP、JavaScript，Java，Ruby等各种语言开发包，大大节约程序员的时间，因而OAUTH是简易的。互联网很多服务如Open API，很多大公司如Google，Yahoo，Microsoft等都提供了OAUTH认证服务，这些都足以说明OAUTH标准逐渐成为开放资源授权的标准。

在官方网站的首页，可以看到下面这段简介：

An open protocol to allow secure API authorization in a simple and standard method from web, mobile and desktop applications.

大概意思是说OAUTH是一种开放的协议，为桌面程序或者基于BS的web应用提供了一种简单的，标准的方式去访问需要用户授权的API服务。OAUTH类似于Flickr Auth、Google's AuthSub[1] 、Yahoo's BBAuth、 Facebook Auth等。

二、协议特点：

(1). 简单：不管是OAUTH服务提供者还是应用开发者，都很易于理解与使用；
       (2). 安全：没有涉及到用户密钥等信息，更安全更灵活；
       (3). 开放：任何服务提供商都可以实现OAUTH，任何软件开发商都可以使用OAUTH；

三、产生背景：

典型案例：如果一个用户拥有两项服务：一项服务是图片在线存储服务A，另一个是图片在线打印服务B。如

下图所示。由于服务A与服务B是由两家不同的服务提供商提供的，所以用户在这两家服务提供商的网站上各自注册了两个用户，假设这两个用户名各不相同，密码也各不相同。当用户

要使用服务B打印存储在服务A上的图片时，用户该如何处理？法一：用户可能先将待打印的图片从服务A上下载下来并上传到服务B上打印，这种方式安全但处理比较繁琐，效率低下；法二：用户将在服务A上注册的用户名与密码提供给服务B，服务B使用用户的账号再去服务A处下载待打印的图片，这种方式效率是提高了，但是安全性大大降低了，服务B可以使用用户的用户名与密码去服务A上查看甚至篡改用户的资源。

很多公司和个人都尝试解决这类问题，包括Google、Yahoo、Microsoft，这也促使OAUTH项目组的产生。OAuth是由Blaine Cook、Chris Messina、Larry Halff 及David Recordon共同发起的，目的在于为API访问授权提供一个开放的标准。OAuth规范的1.0版于2007年12月4日发布。

四、相关术语

三个URL

Request Token URL: 获取未授权的Request Token服务地址；

User Authorization URL: 获取用户授权的Request Token服务地址；

Access Token URL: 用授权的Request Token换取Access Token的服务地址；

参数定义

OAUTH_consumer_key: 使用者的ID，OAUTH服务的直接使用者是开发者开发出来的应用。所以该参数值的获取一般是要去OAUTH服务提供商处注册一个应用，再获取该应用的OAUTH_consumer_key。

OAUTH_consumer_secret：OAUTH_consumer_key对应的密钥。

OAUTH_token:OAUTH进行到最后一步得到的一个“令牌”，通过此“令牌”请求，就可以去拥有资源的网站抓取任意有权限可以被抓取的资源。

OAUTH_token_secret:OAUTH_token对应的私钥。

OAUTH_signature_method: 请求串的签名方法，应用每次向OAUTH三个服务地址发送请求时，必须对请求进行签名。签名的方法有：HMAC-SHA1、RSA-SHA1与PLAINTEXT等三种。

OAUTH_signature: 用上面的签名方法对请求的签名。

OAUTH_timestamp: 发起请求的时间戳（时间戳（timestamp），通常是一个字符序列，唯一地标识某一刻的时间。数字时间戳技术（数字时间戳（digital time-stamp）对于成功的电子商务应用，要求参与交易各方不能否认其行为。）是数字签名技术一种变种的应用。），其值是距1970 00:00:00 GMT的秒数，必须是大于0的整数。本次请求的时间戳必须大于或者等于上次的时间戳。

OAUTH_nonce: 随机生成的字符串，用于防止请求的重复，防止外界的非法攻击。

OAUTH_version: OAUTH的版本号。
响应代码

HTTP 400 Bad Request 请求错误

Unsupported parameter 参数错误

Unsupported signature method 签名方法错误

Missing required parameter 参数丢失

Duplicated OAUTH Protocol Parameter 参数重复

HTTP 401 Unauthorized 未授权

Invalid Consumer Key 非法key

Invalid / expired Token 失效或者非法的token

Invalid signature 签名非法

Invalid / used nonce 非法的nonce

认证流程

获取未授权的request token

请求参数：

OAUTH_consumer_key:消费方键值。

OAUTH_signature_method:消费方签署本请求所用的签名方法。

OAUTH_signature:签名，定义于签署请求 (签署请求)。

OAUTH_timestamp:定义于Nonceand Timestamp (单次值与时间戳)。

OAUTH_nonce:定义于Nonceand Timestamp (单次值与时间戳)。

OAUTH_version:可选。

额外参数:由服务提供方定义的任意额外参数

服务方返回结果，响应包含如下参数：

OAUTH_token:请求令牌

OAUTH_token_secret:令牌密钥

附加参数:由服务提供方定义的任意参数。

获取用户授权的request token

请求参数：

OAUTH_token:可选。在前述步骤中获得的请求令牌。服务提供方可以声明此参数为必须，也可以允许不包含在授权URL中并提示用户手工输入。

OAUTH_callback:可选。消费方可以指定一个URL，当 获取用户授权 (获取用户授权)成功后，服务提供方将重定向用户到这个URL。

附加参数:由服务提供方定义的任意参数。

服务提供方将用户引导回消费方

如果消费方在OAUTH_callback中提供了回调URL(在消费方引导用户至服务提供方 (消费方引导用户至服务提供方)中描述)，则服务提供方构造一个HTTP GET请求URL，重定向用户浏览器到该URL，并包含如下参数：

OAUTH_token:被用户授权或否决的请求令牌回调URL可以包含消费方提供的查询参数，服务提供方必须保持已有查询不变并追加OAUTH_token参数。
用授权的request token换取Access Token

消费方请求访问令牌参数：

OAUTH_consumer_key:消费方键值。

OAUTH_token:之前获取的请求令牌。

OAUTH_signature_method:消费方使用的签署方法。

OAUTH_signature:签署请求 (签署请求)中定义的签名。

OAUTH_timestamp:在单次值与时间戳 (单次值与时间戳)中定义

OAUTH_nonce:在单次值与时间戳 (单次值与时间戳)中定义。

OAUTH_version:版本号，可选。

返回参数：

OAUTH_token:访问令牌。

OAUTH_token_secret:令牌密钥。

访问受保护资源
请求参数：

OAUTH_consumer_key:消费方键值。

OAUTH_token:访问令牌。

OAUTH_signature_method:消费方使用的签署方法。

OAUTH_signature:签署请求 (签署请求)中定义的签名。

OAUTH_timestamp:定义于单次值与时间戳 (单次值与时间戳).

OAUTH_nonce:定义于单次值与时间戳 (单次值与时间戳).

OAUTH_version:版本号，可选。

附加参数:服务提供方指定的附加参数。

五、授权流程

在弄清楚了OAUTH的术语后，我们可以对OAUTH认证授权的流程进行初步认识。其实，简单的来说，
OAUTH认证授权就三个步骤，三句话可以概括：

1. 获取未授权的Request Token

2. 获取用户授权的Request Token

3. 用授权的Request Token换取Access Token

当应用拿到Access Token后，就可以有权访问用户授权的资源了。大家可能看出来了，这三个步骤不就是对应OAUTH的三个URL服务地址嘛。一点没错，上面的三个步骤中，每个步骤分别请求一个URL，并且收到相关信息，并且拿到上步的相关信息去请求接下来的URL直到拿到Access Token。

具体每步执行信息如下：

A. 使用者（第三方软件（所谓第三方软件指的是该非线性编辑系统（非线性编辑是相对于线性编辑而言的，非线性编辑直接从计算机的硬盘中以帧或文件的方式迅速、准确地存取素材，进行编辑的方式。它是以计算机为平台的专用设备，可以实现多种传统电视制作设备的功能。编辑时，素材的长短和顺序可以不按照制作的长短和顺序的先后进行。对素材可以随意地改变顺序，随意地缩短或加长某一段。目前国内的非线性编辑系统已经基本国产化，以中科大洋、索贝、索尼、苹果、极速、SDI 高清非线性编辑系统的国内厂家为代表占据了国内90%以上的市场份额！）生产商以外的软件公司提供的软件。这些软件大都不能直接与非线性卡挂靠，进行输入/输出，但可以对已进入了硬盘阵列的视音频素材进行加工处理和编辑，或者制作自己的二维和三维图像再与那些视频素材合成，合成后的作品再由输入/输出软件输出。这些软件的品种非常丰富，功能十分强大，有些甚至是从工作站转移过来的，可以这么说，非线性编辑系统之所以能做到效果变幻莫测，匪夷所思，吸引众人的视线，完全取决于第三方软件。））向OAUTH服务提供商请求未授权的Request Token。向Request Token URL发起请求，请求需要带上的参数见上图。

B. OAUTH服务提供商同意使用者的请求，并向其颁发未经用户授权的oauth_token与对应的oauth_token_secret，并返回给使用者。

C. 使用者向OAUTH服务提供商请求用户授权的Request Token。向User Authorization URL发起请求，请求带上上步拿到的未授权的token与其密钥。

D. OAUTH服务提供商将引导用户授权。该过程可能会提示用户，你想将哪些受保护的资源授权给该应用。此步可能会返回授权的Request Token也可能不返回。如Yahoo OA

OAUTH流程

OAUTH流程UTH就不会返回任何信息给使用者。

E. Request Token 授权后，使用者将向Access Token URL发起请求，将上步授权的Request Token换取成Access Token。请求的参数见上图，这个比第一步A多了一个参数就是Request Token。

F. OAUTH服务提供商同意使用者的请求，并向其颁发Access Token与对应的密钥，并返回给使用者。

G. 使用者以后就可以使用上步返回的Access Token访问用户授权的资源。

从上面的步骤可以看出，用户始终没有将其用户名与密码等信息提供给使用者（第三方软件），从而更安全。用OAUTH实现背景一节中的典型案例：当服务B（打印服务）要访问用户的服务A（图片服务）时，通过OAUTH机制，服务B向服务A请求未经用户授权的Request Token后，服务A将引导用户在服务A的网站上登录，并询问用户是否将图片服务授权给服务B。用户同意后，服务B就可以访问用户在服务A上的图片服务。整个过程服务B没有触及到用户在服务A的帐号信息。如下图所示，图中的字母对应OAUTH流程中的字母：

六、版本

OAuth Core 1.0 版本发布于2007年12月4日，由于存在可被会话定向攻击(session fixation attack)的缘故，2009年6月24日发布了OAuth Core 1.0 Revision A 版本。最终在2010年4月，OAuth成为了RFC标准： RFC 5849: The OAuth 1.0 Protocol。

OAuth 2.0的草案是在2010年5月初在IETF发布的。OAuth 2.0是OAuth协议的下一版本，但不向后兼容OAuth 1.0。 OAuth 2.0关注客户端开发者的简易性，同时为Web应用，桌面应用和手机，和起居室设备提供专门的认证流程。规范还在IETF OAuth工作组的开发中，按照Eran Hammer-Lahav的说法，OAuth于2010年末完成。