oauth初步学习小结.docx

oauth初步学习小结.docx

《oauth初步学习小结.docx》由会员分享，可在线阅读，更多相关《oauth初步学习小结.docx（6页珍藏版）》请在冰豆网上搜索。

oauth初步学习小结

oauth初步学习小结

还记得开心网，人人网这些SNS刚出来时，它们中有的功能，比如是要导入GOOGLE，MSN的联系人列表，这个时候要我们输入自己在这些系统上的帐号和密码，之后借助API或者WEBSERVICE等去把这些网站上的属于自己的资源导入到自己的网站中，但是，其实这个是很危险的！

因为很有可能这些网站已经获得了你的个人私隐信息了，尽管他们作了承诺，现在，我们可以用oauth协议去初步解决这个三方之间的不信任问题了（用户，第三方应用，服务提供商）。

由于最近在学习sina的微博API，因此小结一下。

一什么是oauth

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

AnopenprotocoltoallowsecureAPIauthorizationinasimpleandstandardmethodfromdesktopandwebapplications.大概意思是说OAUTH是一种开放的协议，为桌面程序或者基于BS的web应用提供了一种简单的，标准的方式去访问需要用户授权的API服务。

OAUTH类似于FlickrAuth、Google'sAuthSub、Yahoo'sBBAuth、FacebookAuth等。

OAUTH认证授权具有以下特点：

1.简单：

不管是OAUTH服务提供者还是应用开发者，都很容易于理解与使用；2.安全：

没有涉及到用户密钥等信息，更安全更灵活；3.开放：

任何服务提供商都可以实现OAUTH，任何软件开发商都可以使用OAUTH；

OAuth开始于2006年11月,当时布莱恩·库克（BlaineCook）正在开发Twitter的OpenID实现。

与此同时，Ma.gnolia需要一个解决方案允许使用OpenID的成员授权Dashboard访问他们的服务。

这样库克,克里斯·梅西纳（ChrisMessina）和来自Ma.gnolia的拉里·哈尔夫（LarryHalff）与戴维·雷科尔顿（DavidRecordon）会面讨论在Twitter和Ma.gnoliaAPI上使用OpenID进行委托授权。

他们讨论得出没有开发标准完成API访问的委托。

2007年4月，成立了OAuth讨论组，这个由实现者组成的小组撰写了一个开放协议的提议草案。

来自Google的德维特·克林顿（DeWittClinton）获悉OAuth项目后，表示他有兴趣支持这个工作。

2007年7月，团队起草了最初的规范。

随后，EranHammer-Lahav加入团队并协调了许多OAuth的稿件，创建了更为正式的规范。

2007年10月3日,OAuth核心1.0最后的草案发布了。

2010年4月，OAuth1.0协议发表为RFC5849，一个非正式RFC。

二oauth的产生背景oauth的产生目的其实就是为了解决其三方不信任的问题的，比如上面举例中的例子，

三方是：

google（或者MSN）这个叫服务资源提供方，用户，第三方应用（比如SNS），

有了oauth,则如果用户在使用SNS过程中，需要用到服务提供方上的资源（比如帐号，密码等），则不需要再第三方中存储或暴露个人私人信息的。

三oauth的组成和术语定义一个典型的OAuth应用通常包括三种角色，分别是：

Consumer：

消费方

ServiceProvider：

服务提供者

User：

用户

用户好理解，不必多言，消费方和服务提供者则需要解释一下，举例来说：

假设我们做了一个SNS，它有一个功能，可以让会员把他们在Google上的联系人导入到SNS上，那么此时的消费方就是SNS，而服务提供者则是Google。

再来看一个图：

如图所示OAuth解决方案中用户、消费方及其服务提供方之间的三角关系：

当用户需要Consumer为其提供某种服务时，该服务涉及到需要从服务提供方那里获取该用户的保护资源。

OAuth保证：

只有在用户显式授权的情况下（步骤4），消费方才可以获取该用户的资源，并用来服务于该用户。

从宏观层次来看，OAuth按以下方式工作：

消费方与不同的服务提供方建立了关系。

消费方共享一个密码短语或者是公钥给服务提供方，服务提供方使用该公钥来确认消费方的身份。

消费方根据服务提供方将用户重定向到登录页面。

该用户登录后告诉服务提供方该消费方访问他的保护资源是没问题的。

oauth的术语：

了解一下OAuth协议的一些基本术语定义：

ConsumerKey：

消费方对于服务提供方的身份唯一标识。

ConsumerSecret：

用来确认消费方对于ConsumerKey的拥有关系。

RequestToken：

获得用户授权的请求令牌，用于交换AccessToken。

AccessToken：

用于获得用户在服务提供方的受保护资源。

TokenSecret：

用来确认消费方对于令牌（RequestToken和AccessToken）的拥有关系。

OAUTH相关的三个URL：

RequestTokenURL:

获取未授权的RequestToken服务地址；

UserAuthorizationURL:

获取用户授权的RequestToken服务地址；

AccessTokenURL:

用授权的RequestToken换取AccessToken的服务地址；OAUTH相关的参数定义：

oauth_consumer_key:

使用者的ID，OAUTH服务的直接使用者是开发者开发出来的应用。

所以该参数值的获取一般是要去OAUTH服务提供商处注册一个应用，再获取该应用的oauth_consumer_key。

如Yahoo该值的注册地址为：

oauth_consumer_secret：

oauth_consumer_key对应的密钥。

oauth_signature_method:

请求串的签名方法，应用每次向OAUTH三个服务地址发送请求时，必须对请求进行签名。

签名的方法有：

HMAC-SHA1、RSA-SHA1与PLAINTEXT等三种。

oauth_signature:

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

oauth_timestamp:

发起请求的时间戳，其值是距197000:

00:

00GMT的秒数，必须是大于0的整数。

本次请求的时间戳必须大于或者等于上次的时间戳。

oauth_nonce:

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

oauth_version:

OAUTH的版本号，可选，其值必须为1.0。

OAUTHHTTP响应代码：

HTTP400BadRequest请求错误

Unsupportedparameter参数错误

Unsupportedsignaturemethod签名方法错误

Missingrequiredparameter参数丢失

DuplicatedOAuthProtocolParameter参数重复

HTTP401Unauthorized未授权

InvalidConsumerKey非法key

Invalid/expiredToken失效或者非法的token

Invalidsignature签名非法

Invalid/usednonce非法的nonce简单的来说，OAUTH认证授权就三个步骤，三句话可以概括：

1.获取未授权的RequestToken2.获取用户授权的RequestToken3.用授权的RequestToken换取AccessToken流程图如下：

具体每步执行信息如下：

A.使用者（第三方软件）向OAUTH服务提供商请求未授权的RequestToken。

向RequestTokenURL发起请求，请求需要带上的参数见上图。

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

C.使用者向OAUTH服务提供商请求用户授权的RequestToken。

向UserAuthorizationURL发起请求，请求带上上步拿到的未授权的token与其密钥。

D.OAUTH服务提供商将引导用户授权。

该过程可能会提示用户，你想将哪些受保护的资源授权给该应用。

此步可能会返回授权的RequestToken也可能不返回。

如YahooOAUTH就不会返回任何信息给使用者。

E.RequestToken授权后，使用者将向AccessTokenURL发起请求，将上步授权的RequestToken换取成AccessToken。

请求的参数见上图，这个比第一步A多了一个参数就是RequestToken。

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

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

基本就是用RequestToken换取AccessToken的过程。

这里需要注意的是，对服务提供者而言，RequestToken和AccessToken的生命周期不一样，通常，RequestToken的生命周期很短，一般在一个小时以内，这样相对安全一些；而AccessToken的生命周期很长，往往是无限，如此一来，消费方就可以把它保存起来，以后的操作就无需用户再授权了，即便用户修改账号密码，也不会受影响，当然，用户可以废除消费方的授权。

四再用通俗点的语言去说这个流程吧

网上的说明还是比较复杂，我再简化下。

1）服务商：

google

2）第三方：

SNS

3）用户

步骤为：

1）第三方先要去GOOGLE注册好cosumer_key和consumer_secret,

2）SNS向GOOGLE发起请求，对GOOGLE说：

HI，你看，我用你给的cosumer_key和consumer_secret来请求你了，我是再你这里申请的哦3）GOOGLE对SNS说：

好，我认得你了，我返回给你一个未经过用户授权的oauth_token和oauth_token_secet吧（有的文中也叫RequestToken和及其相对应的TokenSecret）4）当用户要使用SNS时，假如要调用到GOOGLE的服务时，则SNS引导用户到GOOGLE的网站，这个时候，SNS是把oauth_token带上了，这个时候，一般会让用户在网站

GOOGLE上用帐号密码先登陆一次，当登陆完毕后，GOOGLE询问是否授权SNS访问用户自己的信息5）用户如果允许SNS访问自己的授权信息，则GOOGLE通过URL引导用户重新回到SNS那里，这个时候，SNS再用用户授权过的requesttoken，又向GOOGLE去请求一个ACCESSTOKEN。

6）GOOGLE返回ACCESSTOKEN给SNS，那么SNS就可以开始访问GOOGLE的资源了。

五OAuth和OpenID的区别

OAuth关注的是authorization；而OpenID侧重的是authentication。

从表面上看，这两个英文单词很容易混淆，但实际上，它们的含义有本质的区别：

authorization:

n.授权，认可；批准，委任

authentication:

n.证明；鉴定；证实

OAuth关注的是授权，即：

“用户能做什么”；而OpenID关注的是证明，即：

“用户是谁”。

如果混淆了OAuth和OpenID的含义，后果很严重。

以国内某网站开发的应用为例：

它的功能是通过OAuth授权让新浪微博和豆瓣的用户使用各自的身份发表评论，此类应用属于身份证明问题，本应该通过OpenID来实现，但因为错误的使用了OAuth，从而带来安全隐患：

设想一下用户只是在网站上发表了评论而已，但却赋予了网站随意操作自己私有数据的权利六OAuth安全机制是如何实现的？

OAuth使用的签名加密方法有HMAC-SHA1,RSA-SHA1（可以自定义）。

拿HMAC-SHA1来说吧，HMAC-SHA1这种加密码方法，可以使用私钥来加密要在网络上传输的数据，而这个私钥只有Consumer及服务提供商知道，试图攻击的人即使得到传输在网络上的字符串，没有私钥也是白搭。

私钥是：

consumersecret&tokensecret（哈两个密码加一起）要加密的字符串是：

除oauth_signature外的其它要传输的数据。

按参数名字符排列，如果一样，则按内容排。

如：

domain=&oauth_consumer_key=XYZ&word=welcome......................前面提的加密里面都是固定的字符串，那么攻击者岂不是直接可以偷取使用吗？

不，oauth_timestamp，oauth_nonce。

这两个是变化的。

而且服务器会验证一个nonce（混淆码）是否已经被使用。

那么这样攻击者就无法自已生成签名，或者偷你的签名来使用了。

七参考资料

本文摘录了如下优秀文的参考资料