OAuth和OpenID的区别(转)

时间  2019-12-10
标签 oauth openid 区别 繁體版
原文   原文链接
OAuth（开放受权）是一个开放标准，容许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。   OAuth协议为用户资源的受权提供了一个安全的、开放而又简易的标准。与以往的受权方式不一样之处是OAuth的受权不会使第三方触及到用户的账号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就能够申请得到该用户资源的受权，所以OAuth是安全的。同时，任何第三方均可以使用OAuth认证服务，任何服务提供商均可以实现自身的OAuth认证服务，于是OAuth是开放的。 
OAuth简史：  2007年12月4日发布了OAuth Core 1.0， 此版本的协议存在严重的安全漏洞：OAuth Security Advisory: 2009.1，更详细的安全漏洞介绍能够参考：Explaining the OAuth Session Fixation Attack。2009年6月24日发布了OAuth Core 1.0 Revision A：此版本的协议修复了前一版本的安全漏洞，并成为RFC5849，咱们如今使用的OAuth版本多半都是以此版本为基础。  OAuth 2.0是OAuth协议的下一版本，但不向后兼容OAuth 1.0。 OAuth 2.0关注客户端开发者的简易性，同时为Web应用，桌面应用和手机，和起居室设备提供专门的认证流程。 
OAuth角色: 
  • 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 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）



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

1、OAuth产生的背景程序员

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

 

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

2、OAuth简介安全

   在官方网站的首页，能够看到下面这段简介：服务器

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

 

    大概意思是说OAuth是一种开放的协议，为桌面程序或者基于BS的web应用提供了一种简单的，标准的方式去访问须要用户受权的API服务。OAuth 相似于Flickr Auth、Google's AuthSub、Yahoo's BBAuth、 Facebook Auth等。OAuth认证受权具备如下特色：架构

1. 简单：无论是OAuth服务提供者仍是应用开发者，都很容易于理解与使用；并发

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

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

3、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-SHA一、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

4、OAuth认证受权流程

   在弄清楚了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流程中的字母：

 

5、OAuth服务提供商

   OAuth标准提出到如今不到两年，但取得了很大成功。不只提供了各类语言的版本库，甚至Google，Yahoo，Microsoft等等互联网大头都 实现了OAuth协议。因为OAuth的client包有不少，因此咱们就没有必要在去本身写，避免重复造轮子，直接拿过来用就好了。我使用了这些库去访 问Yahoo OAuth服务，很不错哦！下面就贴出一些图片跟你们一块儿分享下！

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

 

   下图是提示用户将要受权给第三方应用，是否赞成受权的页面

 

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

 

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

 

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

扩展阅读：

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

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

1、OpenID简介

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

登陆一个支持 OpenID 的网站很是简单（即使你是第一次访问这个网站也是同样）。只须要输入你注册好的 OpenID 用户名，而后你登陆的网站会跳转到你的 OpenID 服务网站，在你的 OpenID 服务网站输入密码（或者其它须要填写的信息）验证经过后，你会回到登陆的网站而且已经成功登陆。 OpenID 系统能够应用于全部须要身份验证的地方，既能够应用于单点登陆系统，也能够用于共享敏感数据时的身份认证。

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

2、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

3、OpenID验证流程

  1. 终端用户请求登陆RP网站，用户选择了以OpenID方式来登陆
  2. RP将OpenId的登陆界面返回给终端用户
  3. 终端用户以OpenID登录RP网站
  4. RP网站对用户的OpenID进行标准化，此过程很是负责。因为OpenID多是URI，也多是XRI，因此标 准化方式各不相同。具体标准化过程是：若是OpenID以xri://、xri://$ip或者xri://$dns开头，先去掉这些符号；而后对以下的 字符串进行判断，若是第一个字符是=、@、+、$、!，则视为标准的XRI，不然视为HTTP URL（若没有http,为其增长http://）。
  5. RP发现OP，若是OpenId是XRI，就采用XRI解析，若是是URL，则用Yadis协议解析，若Yadis解析失败，则用Http发现。
  6. RP跟OP创建一个关联。二者之间能够创建一个安全通道，用于传输信息并下降交互次数。
  7. OP处理RP的关联请求
  8. RP请求OP对用户身份进行鉴权
  9. OP对用户鉴权，请求用户进行登陆认证
  10. 用户登陆OP
  11. OP将鉴权结果返回给RP
  12. 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

  1. 用户但愿访问其在example.com的帐户
  2. example.com (在OpenID的黑话里面被称为“Relying Party”) 提示用户输入他/她/它的OpenID
  3. 用户给出了他的OpenID，好比说”http://user.myopenid.com”
  4. example.com 跳转到了用户的OpenID提供商“mypopenid.com”
  5. 用户在”myopenid.com”(OpenID provider)提示的界面上输入用户名密码登陆
  6. “myopenid.com” (OpenID provider) 问用户是否要登陆到example.com
  7. 用户赞成后，”myopenid.com” (OpenID provider) 跳转回example.com
  8. example.com 容许用户访问其账号

OAuth

  1. 用户在使用example.com时但愿从mycontacts.com导入他的联系人
  2. example.com (在OAuth的黑话里面叫“Consumer”)把用户送往mycontacts.com (黑话是“Service Provider”)
  3. 用户在mycontacts.com 登陆(可能也可能不用了他的OpenID)
  4. mycontacts.com问用户是否是但愿受权example.com访问他在mycontact.com的联系人
  5. 用户肯定
  6. mycontacts.com 把用户送回example.com
  7. example.com 从mycontacts.com拿到联系人
  8. 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

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程