OAuth 安全协议docx - Google Code.doc

OAuth简介
OAuth是由BlaineCook、ChrisMessina、LarryHalff及DavidRecordon共同发起的，目的在于为API访问授权提供一个安全、开放的标准。
基于OAuth认证授权具有以下特点：
安全。OAuth与别的授权方式不同之处在于：OAuth的授权不会使消费方（Consumer）触及到用户的帐号信息（如用户名与密码），也是是说，消费方无需使用用户的用户名与密码就可以申请获得该用户资源的授权。
开放。任何消费方都可以使用OAuth认证服务，任何服务提供方(ServiceProvider)都可以实现自身的OAuth认证服务。
简单。不管是消费方还是服务提供方，都很容易于理解与使用。
OAuth的解决方案如下图所示。
图1.OAuthSolution
如图1所示OAuth解决方案中用户、消费方及其服务提供方之间的三角关系：当用户需要Consumer为其提供某种服务时，该服务涉及到需要从服务提供方那里获取该用户的保护资源。OAuth保证：只有在用户显式授权的情况下（步骤4），消费方才可以获取该用户的资源，并用来服务于该用户。
从宏观层次来看，OAuth按以下方式工作：
消费方与不同的服务提供方建立了关系。
消费方共享一个密码短语或者是公钥给服务提供方，服务提供方使用该公钥来确认消费方的身份。
消费方根据服务提供方将用户重定向到登录页面。
该用户登录后告诉服务提供方该消费方访问他的保护资源是没问题的。
HYPERLINK"http://www.ibm.com/developerworks/cn/java/j-lo-oauth/index.html"\l"ibm-pcon"回页首
OAuth认证授权流程
在了解OAuth认证流程之前，我们先来了解一下OAuth协议的一些基本术语定义：
ConsumerKey：消费方对于服务提供方的身份唯一标识。
ConsumerSecret：用来确认消费方对于ConsumerKey的拥有关系。
RequestToken：获得用户授权的请求令牌，用于交换AccessToken。
AccessToken：用于获得用户在服务提供方的受保护资源。
TokenSecret：用来确认消费方对于令牌（RequestToken和AccessToken）的拥有关系。
图2.OAuth授权流程（摘自OAuth规范）
对于图2具体每一执行步骤，解释如下：
消费方向OAuth服务提供方请求未授权的RequestToken。
OAuth服务提供方在验证了消费方的合法请求后，向其颁发未经用户授权的RequestToken及其相对应的TokenSecret。
消费方使用得到的RequestToken，通过URL引导用户到服务提供方那里，这一步应该是浏览器的行为。接下来，用户可以通过输入在服务提供方的用户名/密码信息，授权该请求。一旦授权成功，转到下一步。
服务提供方通过URL引导用户重新回到消费方那里，这一步也是浏览器的行为。
在获得授权的RequestToken后，消费方使用授权的RequestToken从服务提供方那里换取AccessToken。
OAuth服务提供方同意消费方的请求，并向其颁发AccessToken及其对应的TokenSecret。
消费方使用上一步返回的AccessToken访问用户授权的资源。
总的来讲，在OAuth的技术体系里，服务提供方需要提供如下基本的功能：
第1、实现三个Serviceendpoints，即：提供用于获取未授权的RequestToken服务地址，获取用户授权的RequestToken服务地址，以及使用授权的RequestToken换取AccessToken的服务地址。
第2、提供基于Form的用户认证，以便于用户可以登录服务提供方做出授权。
第3、授权的管理，比如用户可以在任何时候撤销已经做出的授权。
而对于消费方而言，需要如下的基本功能：
第1、从服务提供方获取CustomerKey/CustomerSecret。
第2、提供与服务提供方之间基于HTTP的通信机制，以换取相关的令牌。
我们具体来看一个使用OAuth认证的例子。
在传统的网站应用中，如果您想在网站A导入网站B的联系人列表，需要在网站A输入您网站B的用户名、密码信息。例如，您登陆Plaxo(https://www.plaxo.com)，一个联系人管理网站，当您想把GMail的联系人列表导入到Plaxo，您需要输入您的GMail用户名/密码，如图3所示：
图3.在Plaxo获得GMail联系人
在这里，Plaxo承诺不会保存您在Gmail的密码。
如果使用OAuth认证，情况是不同的，您不需要向网站A（扮演Consumer角色）暴露您网站B（扮演ServicePro