OAuth2.0指南

引言

OAuth2.0是一种应用之间彼此访问数据的开源授权协议。比如，一个游戏应用可以访问Facebook的用户数据，或者一个基于地理的应用可以访问Foursquare的用户数据等。下面是一张阐述该概念的图：

OAuth2.0怎么通过应用共享数据的例子，用户访问web游戏应用，该游戏应用要求用户通过Facebook登录。用户登录到了Facebook,再重定向会游戏应用， 游戏应用就可以访问用户在Facebook的数据了，并且该应用可以代表用户向Facebook调用函数(如发送状态更新)。

OAuth2.0实用案例

OAuth2.0要么用来创建一个能够从其他应用读取用户信息的应用(如上面图表中的游戏应用)，要么创建一个使其他应用访问自己的用户数据的应用(如上面例子中的Facebook)。OAuth2.0是OAuth1.0的替代品，OAuth1.0更加复杂。OAuth1.0涉及到了证书等，而OAuth2.0更简单，它不需要任何证书，仅仅就SSL/TLS。

OAuth2.0规范

该指南的目标是提供一个OAuth2.0的很容易理解的概述，但是不会描述规范的每一个细节。如果你想实现OAuth2.0, 你将很有可能要全面学习该规范，你可以在这里找到该规范：http://tools.ietf.org/html/draft-ietf-oauth-v2-23

OAuth2.0综述

如引言所说的，OAuth2.0是一个能够使应用彼此访问数据的开放授权协议。这里我们将阐述该协议是怎么工作的，和规范中提到的概念。该图说明了整个授权过程：

OAuth2.0怎样被用来在应用间共享数据的例子

第一步，用户访问客户端web应用。应用中的按钮”通过Facebook登录”(或者其他的系统，如Google或Twitter)。

第二步，当用户点击了按钮后，就被重定向到授权的应用(如Facebook)， 然后用户登录，并被询问是否要授权应用中的数据给客户端应用，用户接受后。

第三步，授权应用将用户重定向到客户端应用提供的URI，提供这种重定向的URI通常是通过注册客户端应用程序与授权应用程序完成。在注册中，客户端应用的拥有者组注册该重定向URI，在注册过程中认证应用也会给客户端应用客户端标识和密码。在URI后追加一个认证码。该认证码代表了授权。

第四步，用户在客户端应用访问网页被定位到重定向的URI。在背后客户端应用连接授权应用，并且发送在重定向请求参数中接收到的客户端标识，客户端密码和认证码。授权应用将返回一个访问口令。

一旦客户端有了访问口令，该口令便可以被发送到Facebook, Google, Twitter等来访问登录用户的资源。

• OAuth2.0角色

OAuth2.0定义了下面用户和应用的角色：

• 资源拥有者
• 资源服务器
• 客户端应用
• 授权服务器

这些角色在下图中表示为：

OAuth2.0规范中的角色定义

资源拥有者是指拥有共享数据的人或应用。比如，在Facebook或Google的用户可以是资源拥有者。他们拥有的资源就是数据。资源拥有者在表中被描述为人，这可能是最常见的情况。但资源拥有者也可以是一个应用。OAuth2.0提到了这两种可能性。

资源服务器是指托管资源的服务器。比如，Facebook或Google就是资源服务器(或者有一个资源服务器)。

客户端应用是指请求访问存储在资源服务器的资源的应用。资源被资源拥有者所拥有。客户端应用可是一个请求访问用户的Facebook账号的游戏。

授权服务器是指授权客户端应用能够访问资源拥有者所拥有的资源。授权服务器和资源服务器可以是同一个服务器，但不是必须的。如果这两个服务器是分开的，OAuth2.0没有讨论这个两个服务器应该如何通信。这是由资源服务器和授权服务器开发者自己设计决定的。

• OAuth2.0客户端类型

OAuth2.0客户端角色被细分为一系列类型和配置。本节将阐述这些类型和配置。

OAuth2.0规范定义了两种客户端类型：

• 保密的
• 公有的

保密的客户端能够对外部保持客户端密码保密。该客户端密码是由授权服务器分配给客户端应用的。为了避免欺骗，该密码是授权服务器用来识别客户端的。例如一个保密的客户端可以是web应用，除了管理员，没有任何人能够访问服务器和看到该密码。

公有的客户端不能使客户端密码保密。比如移动手机应用或桌面应用会将密码嵌入在内部。这样的应用可能被破解，并且泄漏密码。这同于在用户的浏览器上运行的Javascript应用。用户可以使用一个Javascript调试器来寻找到应用程序，并查看客户端密码。

客户端配置

OAuth2.0规范也提到了一系列客户端配置文件。这些配置文件是具体类型的应用程序，这可以是保密或公开的。这些配置文件有：

• web应用
• 用户代理
• 原生

Web应用

web应用是指运行在web服务器内的应用。实际上，web应用典型地由浏览器部分和服务端部分组成。如果web应用需要访问资源服务器(如Facebook账号)，然后客户端密码被保存在服务器上。因此密码是保密的。

这里阐释了一个保密的客户端应用：

保密的客户端：web应用

用户代理应用

用户代理应用比如运行在浏览器上的的Javascript应用。浏览器是用户代理。用户代理应用可以保存在web服务器上，但应用程序只运行一次下载的用户代理。一个例子就像一个Javascript游戏只能运行在浏览器里。

这里阐释了一个客户端用户代理应用：

公有客户端：用户代理应用

原生应用

原生应用比如桌面应用或移动手机应用。原生应用典型地被安装在用户计算机或设备(手机，平板等)上。因此客户端密码也被存储在用户计算机或设备上。

这里阐释了客户端原生应用：

公有客户端：本地应用

混合应用

有些应用是这些配置的混合使用。比如本地应用也可以有服务器部分，来做一些工作(如数据存储)。OAuth2.0规范没有提及这种混合型。然而，在大多数情况下，混合型将能够使用这些配置文件的认证模型。

• OAuth2.0授权

当一个客户单应用想要访问资源拥有者托管在资源服务器的资源时，它必须先获得授权，本节将讲述客户端授权怎么获取。

客户端标识，客户端密钥和重定向URI

在客户端应用能请求访问资源服务器的资源之前，客户端应用程序必须先注册与资源服务器相关联的授权服务器。

注册一个典型的一次性任务。一旦注册了，除非客户端注册被取消了，注册将持续有效。

注册后客户端应用将由授权服务器分配客户端标识和密钥。在授权服务器上，客户端标识和密钥是唯一标识客户端应用的。如果客户端应用注册了多个授权服务器(如Facebook, Twitter和Google等)，每一个授权服务器将发出唯一的标识给该客户端应用。

无论什么时候客户端应用想要访问同样资源服务器上的资源，它都需要通过发送客户端标识和密钥到授权服务器来验证自己。

在注册过程中，客户端应用也注册了一个重定向URI，当资源拥有者授权给客户端应用时，该重定向URI会被使用。当资源拥有者成功的通过授权服务器授权给客户端应用时，资源拥有者被重定向回客户端应用，再到该重定向URI。

• 授权批准

授权批准由资源服务器，及与其相关的授权服务器，给予客户端应用。

OAuth2.0列举四种不同类型授权批准，每一种类型都有不同的安全特性。这些授权批准类型为：

• 授权码
• 契约
• 资源拥有者密钥证书
• 客户端证书

每种授权批准再下文都会提到。

授权码

用授权码来授权批准原理如下：

资源拥有者(用户)访问客户端应用。客户端应用告诉用户通过授权服务器(如Facebook, Google和Twitter等)来登录到客户端应用。

为了通过授权服务器登录，用户通过客户端应用被重定向到授权服务器。客户端应用发送它的客户端标识给授权服务器，那么授权服务器就知道是哪个应用尝试访问受保护的资源。当被重定向回客户端应用时，授权服务器发送给用户特定的重定向URI,  即客户端已经提前与授权服务器注册。随着重定向，授权服务器发送一个代表授权的授权码。

当在客户端应用的重定向URI被访问时，客户端应用直接连接授权服务器。客户端应用发送授权码，客户端标识及密钥，如果客户端应用能接受这些值，那么授权服务器返回一个访问令牌。

现在客户端应用就可以用该访问令牌请求资源服务器的资源了。该访问令牌可作为客户端授权和授权访问资源。

下面是当用授权码授权客户端应用时的授权过程：

通过授权码授权

契约

契约授权类似于授权码授权，除了用户完成授权后，访问令牌返回给客户端应用外。当用户代理被重定向到重定向URI时，访问令牌因此被返回。

当然这意味着访问令牌可以被用户代理访问，或者在契约授权过程中参与的原生应用。访问令牌在web服务器上不是安全存储的。

进一步说，客户端应用可以只发送它的客户端标识给授权服务器。如果客户端也发送它的密钥，那么客户端密钥将不得不保存在用户代理或原生应用里。那将使得它很容易被破解。

契约授权大多数用在用户代理或原生应用中。用户代理或原生应用将收到来授权服务器的访问令牌。

下面是阐释契约授权的图：

契约授权

资源拥有者密钥证书

资源拥有者证书授权方法通过客户端应用访问资源拥有者证书来工作。比如，用户可以在客户端应用输入他的Twitter用户名及密钥(证书)。该客户端应用就可以用着用户名和密钥访问用户在Twitter的资源。

用资源拥有者密钥证书要求客户端应用很多信任。你不想在那些你怀疑会滥用证书的客户端应用中输入证书。

资源拥有者密钥证书通常被用在用户代理或原生应用中。

客户端证书

客户端证书授权对于客户端需要在资源服务器访问资源或调用函数的情形使用，与特定的资源拥有者无关(如用户)。比如，从Foursquare获取场地列表，这并没有必要通过某个Foursquare用户才能做。

• OAuth2.0端点

OAuth2.0定义了一系列端点。端点典型的就是web服务器上的URI。比如，一个Java Servlet, JSP page, PHP page, ASP.NET网页等等。

这些端点定义有：

• 授权端点
• 令牌端点
• 重定向端点

授权端点和令牌端点都位于授权服务器上，重定向端点位于客户端应用上。每个端点都会在下面讲述。

这些端点在下图中阐释为：

OAuth2.0端点

OAuth2.0规范没有描述这些端点怎么被发现或记录。这取决于咩哥实现者来决定。大多数网站都有一个子网站来的开发人员来记录这些端点。

授权端点

授权端点是资源拥有者所登录的授权服务器，并授权给客户端应用的端点。

令牌端点

令牌端点是在授权服务器上为了一个访问令牌，客户端应用要交换授权码，客户端标识和客户端密钥的端点。

重定向端点

重定向端点是在授权端点授权以后，资源拥有者被重定向到客户端应用的端点。