最近老大给了我一个任务,就是要我去了解一下什么是OAuth认证,刚开始说真的, 我是一头雾水,我听都没听过.没办法,只好去网上查资料,看帖子.
经过一段时间的了解,大致的明白了什么是OAuth2.0 认证,下面呢,我就把我所学到的呢,跟大家分享一下.如果写的不好,请大家见谅..!

OAuth 2.0 认证<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

全称 Open the Authentication 开放认证

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

OAuth简史

2007 年 12 月 4 日发布了 OAuth Core 1.0 ： 此版本的协议存在严重的安全漏洞

2009 年 6 月 24 日发布了 OAuth Core 1.0 Revision A ：

此版本的协议修复了前一版本的安全漏洞，并成为 RFC5849.

 

 

产生条件

  如今很多网站的功能都强调彼此之间的交互 , 因此我们需要一种简单 , 标准的解决方案来安全的完成应用的授权 ,于是OAuth应运而生.

 

角色

典型的 OAuth 应用通常包含三种角色
1.       Consumer 消费方
2.       Service Provider 服务提供方
3.       User 用户
举例说明 :
假设我们做了一个 SNS( 社交网络 ) ，它有一个功能，可以让会员把他们在 Google 上的联系人导入到 SNS 上，那么此时的消费方就是 SNS ，而服务提供者则是 Google 。

 

条件

消费方如果想使用服务提供者的 OAuth 功能，通常需要先申请两样东西：

Consumer Key ( 消费者的关键 , 多指 : 账户 )

Consumer Secret ( 消费者秘密 , 多指 : 密码 )

 

OAUTH认证授权具有以下特点

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

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

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

 

有腿的OAuth

我们前面描述的 OAuth ，被称为三条腿的 OAuth （ 3-Legged OAuth ），这也是 OAuth 的标准版本。这里所谓的 “ 三条腿 ” ，指的是授权过程中涉及前面提到的三种角色，也就是：消费方，服务提供者，用户。不过有些情况下，不需要用户的参与，此时就产生了一个变体，被称作两条腿的 OAuth （ 2-Legged OAuth ），两条腿的 OAuth 和三条腿的 OAuth 相比，因为没有用户的参与，所以在流程中就不会涉及用户授权的环节，而主要是通过 Consumer Key 和 Consumer Secret 来完成签名的，此时的 Consumer Key 和 Consumer Secret 基本等价于账号和密码的作用。

 

流程

 

§  A ：消费方请求 Request Token ( 请求令牌 )

§  B ：服务提供者授权 Request Token

§  C ：消费方定向用户到服务提供者

§  D ：获得用户授权后，服务提供者定向用户到消费方

§  E ：消费方请求 Access Token ( 访问令牌 )

§  F ：服务提供者授权 Access Token

§  G ：消费方访问受保护的资源

简单来说就是用 Request Token 换取 Access Token 的过程 .

 

 

OAuth和OpenID的区别

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

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

§  authentication: n. 证明；鉴定；证实

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

 

举例说明 :

 
此类应用属于×××明问题，本应该通过 OpenID 来实现，但因为错误的使用了 OAuth ，从而带来安全隐患：设想一下用户只是在网站上发表了评论而已，但却赋予了网站随意操作自己私有数据的权利！这就好比：快递员送包裹，为了证明收件人的身份，原本你只要给他看一下×××即可，可你却把防盗门钥匙都给他了！