OAuth和OpenID的区别(转)

Consumer：消费方
Service Provider：服务提供者
User：用户

OAuth流程：

用户访问客户端的网站，想操作用户存放在服务提供方的资源。
客户端向服务提供方请求一个临时令牌。
服务提供方验证客户端的身份后，授予一个临时令牌。
客户端获得临时令牌后，将用户引导至服务提供方的授权页面请求用户授权。在这个过程中将临时令牌和客户端的回调连接发送给服务提供方。
用户在服务提供方的网页上输入用户名和密码，然后授权该客户端访问所请求的资源。
授权成功后，服务提供方引导用户返回客户端的网页。
客户端根据临时令牌从服务提供方那里获取访问令牌。
服务提供方根据临时令牌和用户的授权情况授予客户端访问令牌。
客户端使用获取的访问令牌访问存放在服务提供方上的受保护的资源。

有腿的OAuth 我们前面描述的OAuth，被称为三条腿的OAuth（3-Legged OAuth），这也是OAuth的标准版本。这里所谓的“三条腿”，指的是授权过程中涉及前面提到的三种角色，也就是：消费方，服务提供者，用户。不过有些情况下，不需要用户的参与，此时就产生了一个变体，被称作两条腿的OAuth（2-Legged OAuth），一般来说，访问私有数据的应用需要三条腿的OAuth，访问公共数据的应用需要两条腿的OAuth。两条腿的OAuth和三条腿的OAuth相比，因为没有用户的参与，所以在流程中就不会涉及用户授权的环节，也就不需要使用Token，而主要是通过Consumer Key和Consumer Secret来完成签名的，此时的Consumer Key和Consumer Secret基本等价于账号和密码的作用。
OAuth和OpenID的区别： OAuth关注的是authorization授权，即：“用户能做什么”；而OpenID侧重的是authentication认证，即：“用户是谁”。 OpenID、OAuth联合使用例子：

OpenID 用户希望访问其在example.com的账户
example.com(在OpenID的黑话里面被称为“Relying Party”) 提示用户输入他/她/它的OpenID
用户给出了他的OpenID，比如说"http://user.myopenid.com"
example.com 跳转到了用户的OpenID提供商“mypopenid.com”
用户在"myopenid.com"(OpenID provider)提示的界面上输入用户名密码登录
“myopenid.com" (OpenID provider) 问用户是否要登录到example.com
用户同意后，"myopenid.com" (OpenID provider) 跳转回example.com
example.com 允许用户访问其帐号
用户在使用example.com时希望从mycontacts.com导入他的联系人
example.com (在OAuth的黑话里面叫“Consumer”)把用户送往mycontacts.com (黑话是“Service Provider”)
用户在mycontacts.com 登录(可能也可能不用了他的OpenID)
mycontacts.com问用户是不是希望授权example.com访问他在mycontact.com的联系人
用户确定
mycontacts.com 把用户送回example.com
example.com 从mycontacts.com拿到联系人
example.com 告诉用户导入成功

上面的例子告诉我们，OpenID是用来认证协议，OAuth是授权协议，二者是互补的。OAuth来自Twitter，可以让A网站的用户共享B网站上的他自己的资源，而不需泄露用户名和密码给另外一个网站。OAuth可以把提供的Token，限制在一个网站特定时间段的的特定资源。
Google Connect(基于OpenID + OAuth思想的定制)： OAuth和OpenID的区别(转)

OAuth 2.0的新特性 - 6种全新流程:

User-Agent Flow – 客户端运行于用户代理内（典型如web浏览器）。
Web Server Flow – 客户端是web服务器程序的一部分，通过http request接入，这是OAuth 1.0提供的流程的简化版本。
Device Flow – 适用于客户端在受限设备上执行操作，但是终端用户单独接入另一台电脑或者设备的浏览器
Username and Password Flow – 这个流程的应用场景是，用户信任客户端处理身份凭据，但是仍然不希望客户端储存他们的用户名和密码，这个流程仅在用户高度信任客户端时才适用。
Client Credentials Flow – 客户端使用它的身份凭据去获取access token，这个流程支持2-legged OAuth的场景。
Assertion Flow – 客户端用assertion去换取access token，比如SAML assertion。

OAuth 2.0的新特性: 持信人token - OAuth 2.0 提供一种无需加密的认证方式，此方式是基于现存的cookie验证架构，token本身将自己作为secret，通过HTTPS发送，从而替换了通过 HMAC和token secret加密并发送的方式，这将允许使用cURL发起APIcall和其他简单的脚本工具而不需遵循原先的request方式并进行签名。签名简化 - 对于签名的支持，签名机制大大简化，不需要特殊的解析处理，编码，和对参数进行排序。使用一个secret替代原先的两个secret。短期token和长效的身份凭据 - 原先的OAuth，会发行一个有效期非常长的token(典型的是一年有效期或者无有效期限制)，在OAuth 2.0中，server将发行一个短有效期的access token和长生命期的refresh token。这将允许客户端无需用户再次操作而获取一个新的access token，并且也限制了access token的有效期。角色分开 - OAuth 2.0将分为两个角色： Authorization server负责获取用户的授权并且发布token； Resource负责处理API calls。参考： OAuth2.0 OpenID&Oauth The OAuth 2.0 Authorization Framework draft-ietf-oauth-v2-31 安全声明（断言）标记语言 saml（Security Assertion Markup Language）

OpenID_Oauth.zip (2.7 MB)

摘要：OAuth协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAuth的授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此OAuth是安全的。同时，任何第三方都可以使用 OAuth认证服务，任何服务提供商都可以实现自身的OAuth认证服务，因而OAuth是开放的。业界提供了OAuth的多种实现如 PHP，JavaScript，Java，Ruby等各种语言开发包，大大节约了程序员的时间，因而OAuth是简易的。目前互联网很多服务如Open API，很多大头公司如Google，Yahoo，Microsoft等都提供了OAuth认证服务，这些都足以说明OAuth标准逐渐成为开放资源授权的标准。

一、OAuth产生的背景

典型案例：如果一个用户拥有两项服务：一项服务是图片在线存储服务A，另一个是图片在线打印服务B。如下图所示。由于服务A与服务B是由两家不同的服务提供商提供的，所以用户在这两家服务提供商的网站上各自注册了两个用户，假设这两个用户名各不相同，密码也各不相同。当用户要使用服务B打印存储在服务A上的图片时，用户该如何处理？法一：用户可能先将待打印的图片从服务A上下载下来并上传到服务B上打印，这种方式安全但处理比较繁琐，效率低下；法二：用户将在服务A上注册的用户名与密码提供给服务B，服务B使用用户的帐号再去服务A处下载待打印的图片，这种方式效率是提高了，但是安全性大大降低了，服务B可以使用用户的用户名与密码去服务A上查看甚至篡改用户的资源。

OAuth和OpenID的区别(转)

很多公司和个人都尝试解决这类问题，包括Google、Yahoo、Microsoft，这也促使OAuth项目组的产生。OAuth是由Blaine Cook、Chris Messina、Larry Halff 及David Recordon共同发起的，目的在于为API访问授权提供一个开放的标准。OAuth规范的1.0版于2007年12月4日发布。通过官方网址：http://OAuth.net可以阅读更多的相关信息。

二、OAuth简介

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

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、Yahoo's BBAuth、 Facebook Auth等。OAuth认证授权具有以下特点：

1. 简单：不管是OAuth服务提供者还是应用开发者，都很容易于理解与使用；

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

3. 开放：任何服务提供商都可以实现OAuth，任何软件开发商都可以使用OAuth；

三、OAuth相关术语

在弄清楚OAuth流程之前，我们先了解下OAuth的一些术语的定义：

OAuth相关的三个URL：
- Request Token URL: 获取未授权的Request Token服务地址；
- User Authorization URL: 获取用户授权的Request Token服务地址；
- Access Token URL: 用授权的Request Token换取Access Token的服务地址；

OAuth相关的参数定义：
- OAuth_consumer_key: 使用者的ID，OAuth服务的直接使用者是开发者开发出来的应用。所以该参数值的获取一般是要去OAuth服务提供商处注册一个应用，再获取该应用的OAuth_consumer_key。如Yahoo该值的注册地址为：https://developer.yahoo.com/dashboard/
- OAuth_consumer_secret：OAuth_consumer_key对应的密钥。
- OAuth_signature_method: 请求串的签名方法，应用每次向OAuth三个服务地址发送请求时，必须对请求进行签名。签名的方法有：HMAC-SHA1、RSA-SHA1与PLAINTEXT等三种。
- OAuth_signature: 用上面的签名方法对请求的签名。
- OAuth_timestamp: 发起请求的时间戳，其值是距1970 00:00:00 GMT的秒数，必须是大于0的整数。本次请求的时间戳必须大于或者等于上次的时间戳。
- OAuth_nonce: 随机生成的字符串，用于防止请求的重放，防止外界的非法攻击。
- OAuth_version: OAuth的版本号，可选，其值必须为1.0。

OAuth HTTP响应代码：

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

四、OAuth认证授权流程

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

1. 获取未授权的Request Token

2. 获取用户授权的Request Token

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

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

OAuth和OpenID的区别(转)

具体每步执行信息如下：

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和OpenID的区别(转)

五、OAuth服务提供商

OAuth标准提出到现在不到两年，但取得了很大成功。不仅提供了各种语言的版本库，甚至Google，Yahoo，Microsoft等等互联网大头都实现了OAuth协议。由于OAuth的client包有很多，所以我们就没有必要在去自己写，避免重复造轮子，直接拿过来用就行了。我使用了这些库去访问Yahoo OAuth服务，很不错哦！下面就贴出一些图片跟大家一起分享下！

下图是OAuth服务提供商引导用户登录（若用户开始没有登录）

OAuth和OpenID的区别(转)

下图是提示用户将要授权给第三方应用，是否同意授权的页面

OAuth和OpenID的区别(转)

下图提示用户已授权成功的信息

OAuth和OpenID的区别(转)

一些服务提供商不仅仅仅实现了OAuth协议上的功能，还提供了一些更友好的服务，比如管理第三方软件的授权服务。下图就是YAHOO管理软件授权的页面，用户可以取消都某些应用的授权。

OAuth和OpenID的区别(转)

原文地址： http://blog.csdn.net/hereweare2009/article/details/3968582

扩展阅读：

http://zh.wikipedia.org/wiki/OAuth

http://baike.baidu.com/view/3948029.htm

一、OpenID简介

OpenId是一个以用户为中心的数字身份识别框架，它具有开放、分散、自由等特性。OpenId的创建是基于这样一个概念：我们可以通过URI（或者URL网址）来识别一个网站。同样，我们也可以通过这样的方式来识别一个用户的身份。OpenId系统的身份认证就是通过 URI来认证用户身份。目前绝大部分网站都是通过用户名与密码来登录认证用户身份，这就要求大家在每个你要使用的网站上注册一个帐号。如果使用 OpenId，你可以在一个提供OpenId的网站上注册一个OpenId，以后你可以使用这个OpenId去登录支持OpenId的网站。这正是一处注册，到处使用的体现。

OAuth和OpenID的区别(转)

登录一个支持 OpenID 的网站非常简单（即便你是第一次访问这个网站也是一样）。只需要输入你注册好的 OpenID 用户名，然后你登录的网站会跳转到你的 OpenID 服务网站，在你的 OpenID 服务网站输入密码（或者其它需要填写的信息）验证通过后，你会回到登录的网站并且已经成功登录。 OpenID 系统可以应用于所有需要身份验证的地方，既可以应用于单点登录系统，也可以用于共享敏感数据时的身份认证。

除了一处注册到处通行以外，OpenID 给所有支持 OpenID 的网站带来了价值－－共享用户资源。用户可以清楚的控制哪些信息可以被共享，例如姓名、地址、电话号码等。今天，OpenID 作为以用户为中心的身份验证系统已经为数百万的用户提供了服务。

二、OpenID相关术语

End User：终端用户，使用OP与RP的服务
Relying Party依赖方：简称RP，服务提供者，需要OP鉴权终端用户的身份
OpenID Provider：OpenID提供者，简称OP，对用户身份鉴权
Identifier标识符：标识符可以是一个HTTP、HTTPS或者XRI(可扩展的资源标识)
User-Agent：实现了HTTP1.1协议的用户浏览器
OP Endpoint URL：OP鉴权的URL，提供给RP使用
OP Identifier：OP提供给终端用户的一个URI或者XRI,RP根据OP Identifier来解析出OP Endpoint URL与OP Version
User-Supplied Identifier：终端用户使用的ID，可能是OP提供的OpenID，也可以是在RP注册的ID。RP可以根据User-Supplied Identifier来解析出OP Endpoint URL、OP Version与OP_Local Identifer
Claimed Identifier：终端用户声明自己身份的一个标志，可以是一个URI或者XRI
OP-Local Identifier：OP提供的局部ID

三、OpenID验证流程

OAuth和OpenID的区别(转)

终端用户请求登录RP网站，用户选择了以OpenID方式来登录
RP将OpenId的登录界面返回给终端用户
终端用户以OpenID登陆RP网站
RP网站对用户的OpenID进行标准化，此过程非常负责。由于OpenID可能是URI，也可能是XRI，所以标准化方式各不相同。具体标准化过程是：如果OpenID以xri://、xri://$ip或者xri://$dns开头，先去掉这些符号；然后对如下的字符串进行判断，如果第一个字符是=、@、+、$、!，则视为标准的XRI，否则视为HTTP URL（若没有http,为其增加http://）。
RP发现OP，如果OpenId是XRI，就采用XRI解析，如果是URL，则用Yadis协议解析，若Yadis解析失败，则用Http发现。
RP跟OP建立一个关联。两者之间可以建立一个安全通道，用于传输信息并降低交互次数。
OP处理RP的关联请求
RP请求OP对用户身份进行鉴权
OP对用户鉴权，请求用户进行登录认证
用户登录OP
OP将鉴权结果返回给RP
RP对OP的结果进行分析

原文地址：http://www.biaodianfu.com/learn-openid.html

http://www.cnblogs.com/likebeta/archive/2012/06/28/2568781.html

前面两篇文章（OAuth和OpenID）都说了可以用来认证身份，但是他们之间到底有哪些不同，哪些情况应该用OAuth，哪些情况应该用OpenID呢?下面就一起来看下他们之间的区别。

简短的说，OAuth关注的是authorization；而OpenID侧重的是authentication。从表面上看，这两个英文单词很容易混淆，但实际上，它们的含义有本质的区别：

authorization: n. 授权，认可；批准，委任
authentication: n. 证明；鉴定；证实

OAuth关注的是授权，即：“用户能做什么”；而OpenID关注的是证明，即：“用户是谁”。下面就分别来说两者的功能。

OpenID

用户希望访问其在example.com的账户
example.com (在OpenID的黑话里面被称为“Relying Party”) 提示用户输入他/她/它的OpenID
用户给出了他的OpenID，比如说”http://user.myopenid.com”
example.com 跳转到了用户的OpenID提供商“mypopenid.com”
用户在”myopenid.com”(OpenID provider)提示的界面上输入用户名密码登录
“myopenid.com” (OpenID provider) 问用户是否要登录到example.com
用户同意后，”myopenid.com” (OpenID provider) 跳转回example.com
example.com 允许用户访问其帐号

OAuth

用户在使用example.com时希望从mycontacts.com导入他的联系人
example.com (在OAuth的黑话里面叫“Consumer”)把用户送往mycontacts.com (黑话是“Service Provider”)
用户在mycontacts.com 登录(可能也可能不用了他的OpenID)
mycontacts.com问用户是不是希望授权example.com访问他在mycontact.com的联系人
用户确定
mycontacts.com 把用户送回example.com
example.com 从mycontacts.com拿到联系人
example.com 告诉用户导入成功

OpenID是用来验证的，就是说可以用一个url来唯一表明身份（不用挨个记每个网站的用户密码）。OAuth是用来授权的（俺可以授权一个网站访问俺在另外一个网站的数据，而俺不用把俺的密码给第一个网站。

很多人现在错误的把OAuth当做OpenID使用。但是其实也不会照成什么影响。如水煮鱼开发的WordPress插件

原文地址：http://www.biaodianfu.com/oauth-openid.html

http://www.cnblogs.com/likebeta/archive/2012/06/28/2568786.html