OAuth机制原理（开放授权机制）

1、简述

OAuth（Open Authorization，开放授权）是为用户资源的授权定义了一个安全、开放及简单的标准，第三方无需知道用户的账号及密码，就可获取到用户的授权信息，并且这是安全的。

国内外已经有很多的公司开发了自己的开放平台，Facebook、Twitter、腾讯、新浪微博、人人网，它们用户规模大、技术实力强，为第三方提供了一整套自成体系、纷繁复杂的“开放API”。通过开放平台，网站不仅能提供对Web 网页的简单访问，还可以进行复杂的数据交互，允许第三方开发者利用其资源开发复杂的应用，既丰富自身网站应用，为用户提供更好的服务，逐步建立起一个服务完备的网络社会，也为第三方连接的网站带来更多的用户。开放平台迅速成为互联网发展的趋势。

开放平台的核心问题在于用户验证和授权。对于服务提供商来说，一般不会希望第三方直接使用用户名和密码来验证用户身份，除非双方具有很强的信任关系。OAuth协议正是为了解决服务整合时“验证和授权”这一根本问题而产生的，具有同样认证功能的协议还有Openid。

2、案例：

如果一个用户拥有两项服务：一项服务是图片在线存储服务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访问授权提供一个开放的标准。

3、概述：

OAuth是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。

OAuth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的网站（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息。

4、特点：

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

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

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

5、核心工作流程：

OAuth为客户端提供了一种代表资源拥有者访问受保护资源的方法。在客户端访问受保护资源之前，它必须先从资源拥有者获取授权（访问许可），然后用访问许可交换访问令牌（Access Token，包含许可的作用域、持续时间和其它属性等信息）。客户端通过向资源服务器出示访问令牌来访问受保护资源。

6、OAuth1.0主要流程是四步骤：

1、获取未授权的Request Token

2、请求用户授权Request Token

3、使用授权后的Request Token换取Access Token

4、使用 Access Token 访问或修改受保护资源。

7、1.0的缺陷：

1、oauth1.0对手机客户端，移动设备等非server第三方的支持不好。是因为oauth1.0将多种流程合并成了一种，而事实证明，这种合并的流程体验性非常差。

2、oauth1.0的三步认证过程比较繁琐和复杂，对第三方开发者增加了极大的开发难度。

3、oauth1.0的加密需求过于复杂，第三方开发者使用oauth之前需要花费精力先实现oauth1.0的加密算法。

4、oauth1.0生成的access_token要求是永久有效的，这导致的问题是网站的安全性和破坏网站的架构。

8、oauth2.0针对1.0的各种问题提供了解决方法：

1、oauth2.0提出了多种流程，各个客户端按照实际情况选择不同的流程来获取access_token。这样就解决了对移动设备等第三方的支持，也解决了拓展性的问题

2、oauth2.0删除了繁琐的加密算法。利用了https传输对认证的安全性进行了保证

3、oauth2.0的认证流程一般只有2步，对开发者来说，减轻了负担

4、oauth2.0提出了access_token的更新方案，获取access_token的同时也获取refresh_token, access_token是有过期时间的，refresh_token的过期时间较长，这样能随时使用refresh_token对access_token进行更新

9、客户端的授权模式

客户端必须得到用户的授权（authorization grant），才能获得令牌（access token）。OAuth 2.0定义了四种授权方式。

授权码模式（authorization code）：功能最完整、流程最严密的授权模式。其特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。

简化模式（implicit）

密码模式（resource owner password credentials）

客户端模式（client credentials）

10、Oauth2.0根据授权方式和客户端状态的不同对应不一样的实现方式。

10.1 Webserver方式

适用场景：

Web Server子态适用于有能力与终端用户的user-agent（通常是浏览器）交互并能够从授权服务器接收（通过重定向）请求（即有能力担当HTTP服务器的角色）的客户端。

10.2 userAgent方式

适用场景：

Web Server子态适用于有能力与终端用户的user-agent（通常是浏览器）交互并能够从授权服务器接收（通过重定向）请求（即有能力担当HTTP服务器的角色）的客户端，典型的例子是用诸如JavaScript语言编写并运行在浏览器的程序。这些客户端不能保存客户端私有证书，并且客户端的验证基于user-agent的同源策略。

说明：

在其它子态中，客户端对于终端用户的授权和访问令牌使用分开的不同请求来完成，而与之不同的是，在user-agent子态中，客户端以HTTP重定向的方式在终端用户授权请求的结果中获取到访问令牌。客户端请求授权服务器将user-agent重定向到另一个web服务器或user-agent能访问到的本地资源，而且user-agent有能力从响应信息中提取出访问令牌并传给客户端。

10.3 原生程序方式

适用场景：

原生程序方式适用于作为原生代码运行在终端用户计算机或移动设备上的客户端。这些客户端通常有能力与终端用户的user-agent交互（或嵌入user-agent）。

10.4 基于不同的需求和期望的终端用户体验，原生程序客户端可以有三种方式实现：

外部启用一个user-agent；

内嵌一个user-agent；

直接要求用户输入用户名和密码。

11、优缺点：

外部浏览器可能会提高完成效率，因为终端用户可能已经登录过了而不需要重新进行身份验证。

嵌入的user-agent通常能提供更好的用户流程，因为它不必切换上下文并打开新窗口。

但嵌入的user-agent对安全提出了挑战，因为用户在一个无法辨别的窗口之中进行身份验证，而不像很多user-agent那样能提供可视化的保护。

第三种方式，实现起来最简单，但它将终端用户的密码直接交给了第三方客户端，而客户端不得不用明文存储密码，所以它要求客户端和认证服务方有很强的信任关系。

12、刷新令牌

OAuth2.0引入刷新令牌的方式重新获取访问令牌。访问令牌的生命周期通常比资源拥有者授予的要短一些。当分发一个访问令牌时，授权服务器可以同时传回一个刷新令牌，在当前访问令牌超时后，客户端可以用这个刷新令牌重新获取一个访问令牌。当请求新的访问令牌时，刷新令牌担当起访问许可的角色。使用刷新令牌，不再需要再次与资源拥有者交互，也不需要存储原始的访问许可来获得访问令牌和刷新令牌。

注：可以使用刷新令牌也可以直接使用客户端的私有证书

13、说明：

本文提出的OAuth使用方式是基于2.0协议，只对OAuth2.0 最核心的工作流程进行设计，即获取Access Token 的过程。

14、客户端设计

15、服务端设计

15.1 服务器端的数据存储方案

OAuth2.0 机制的核心工作流程，大部分信息，如APP 信息、用户和APP 之间的授权关系、Access Token等，需要永久性存储，存储在数据库中。一些不需要永久存储的信息，如临时授权码，只使用一次，而且，在很短的时间内就要使其失效，就没有必要存储在数据库之中，可存储在譬如memcached 等缓存系统中，即提高了系统的处理速度，又减少了数据库压力。

15.2 数据库表结构设计

客户端要先注册一个应用，获取该应用的APPID和APPSECRET，应用的详细信息存储在数据表中，如下图所示：

15.3 用户授权信息表用来保存授权成功的访问令牌

16、OAuth和OpenID的比较

16.1 OpenID

OpenID 是一个以用户为中心的数字身份识别框架。

OpenID 的创建基于这样一个概念：我们可以通过 URI （又叫 URL 或网站地址）来认证一个网站的唯一身份，同理，我们也可以通过这种方式来作为用户的身份认证。由于URI 是整个网络世界的核心，它为基于URI的用户身份认证提供了广泛的、坚实的基础。

16.2 OAuth和Openid同为认证机制，但它们的侧重点不一样。

OAuth关注的授权，即：“用户能做什么” ；

而OpenID关注的是证明，即：“用户是谁”。

下面就分别来举例说明两者的功能。

a. OpenID

用户希望访问其在example.com的账户

example.com 提示用户输入他/她/它的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 允许用户访问其资源

b. OAuth

用户在使用example.com时希望从mycontacts.com导入他的联系人

example.com (在OAuth的黑话里面叫“Consumer”)把用户送往mycontacts.com (黑话是“Service Provider”)

用户在mycontacts.com 登录

mycontacts.com问用户是不是希望授权example.com访问他在mycontact.com的联系人

用户确定

mycontacts.com 把用户送回example.com

example.com 从mycontacts.com拿到联系人

example.com 告诉用户导入成功

http://wenku.baidu.com/link?url=IElvmFR6_QYq5liTdo6k8Moh6PugOcjPJDTdceYcCuw2BdkIHh2ctHZRy_QctqueCOLcwcFP1jifhHfZj0D78ksy332tAj4LLCHs8u9B4lq

http://www.cnblogs.com/linjiqin/p/4552727.html