OAuth协议

时间 2019-11-18

标签 oauth 协议繁體版

原文原文链接

OAUTH协议为用户资源的受权提供了一个安全的、开放而又简易的标准。与以往的受权方式不一样之处是OAUTH的受权不会使第三方触及到用户的账号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就能够申请得到该用户资源的受权，所以OAUTH是安全的。

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

An open protocol to allow secure API authorization in a simple and standard method from desktop and web 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对应的密钥。

因此：注册应用服务生成的consumer_key和consumer_secret就比较重要了。

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

OAUTH_token_secret:OAUTH_token对应的私钥。

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

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

OAUTH_timestamp: 发起请求的时间戳，其值是距1970 00:00:00 GMT的秒数，必须是大于0的整数。本次请求的时间戳必须大于或者等于上次的时间戳。

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

OAUTH_version: OAUTH的版本号。

认证流程

获取未受权的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. 使用者（第三方软件）向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 OAUTH就不会返回任何信息给使用者。

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流程前端

版本编辑

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年底完成。