原文地址：http://www.ibm.com/developerworks/cn/java/j-lo-oauth/index.html

參考博客：http://www.cnblogs.com/wangkewei/archive/2011/01/14/1935858.html

OAuth 简单介绍

OAuth 是由 Blaine Cook、Chris Messina、Larry Halff 及 David Recordon 共同发起的，目的在于为 API 訪问授权提供一个安全、开放的标准。

基于 OAuth 认证授权具有下面特点：

• 安全。

  OAuth 与别的授权方式不同之处在于：OAuth 的授权不会使消费方（Consumer）触及到用户的帐号信息（如username与password）。也是是说。消费方无需使用用户的username与password就能够申请获得该用户资源的授权。

• 开放。

  不论什么消费方都能够使用 OAuth 认证服务，不论什么服务提供方 (Service Provider) 都能够实现自身的 OAuth 认证服务。

• 简单。

  无论是消费方还是服务提供方，都非常easy于理解与使用。

• OAuth 的解决方式例如以下图所看到的。

如图 1 所看到的 OAuth 解决方式中用户、消费方及其服务提供方之间的三角关系：当用户须要 Consumer 为其提供某种服务时，该服务涉及到须要从服务提供方那里获取该用户的保护资源。OAuth 保证：仅仅有在用户显式授权的情况下（步骤 4）。消费方才干够获取该用户的资源。并用来服务于该用户。

从宏观层次来看。OAuth 按下面方式工作：

1. 消费方与不同的服务提供方建立了关系。

2. 消费方共享一个password短语或者是公钥给服务提供方，服务提供方使用该公钥来确认消费方的身份。
3. 消费方依据服务提供方将用户重定向到登录页面。
4. 该用户登录后告诉服务提供方该消费方訪问他的保护资源是没问题的

在了解 OAuth 认证流程之前，我们先来了解一下 OAuth 协议的一些基本术语定义：

• Consumer Key：消费方对于服务提供方的身份唯一标识。

• Consumer Secret：用来确认消费方对于 Consumer Key 的拥有关系。
• Request Token：获得用户授权的请求令牌，用于交换 Access Token。
• Access Token：用于获得用户在服务提供方的受保护资源。
• Token Secret：用来确认消费方对于令牌（Request Token 和 Access Token）的拥有关系。

OAuth 认证授权流程

1. 消费方向 OAuth 服务提供方请求未授权的 Request Token。

2. OAuth 服务提供方在验证了消费方的合法请求后，向其颁发未经用户授权的 Request Token 及其相相应的 Token Secret。
3. 消费方使用得到的 Request Token，通过 URL 引导用户到服务提供方那里，这一步应该是浏览器的行为。接下来。用户能够通过输入在服务提供方的username / password信息。授权该请求。

   一旦授权成功，转到下一步。

4. 服务提供方通过 URL 引导用户又一次回到消费方那里。这一步也是浏览器的行为。
5. 在获得授权的 Request Token 后，消费方使用授权的 Request Token 从服务提供方那里换取 Access Token。
6. OAuth 服务提供方允许消费方的请求。并向其颁发 Access Token 及其相应的 Token Secret。

7. 消费方使用上一步返回的 Access Token 訪问用户授权的资源。

总的来讲，在 OAuth 的技术体系里，服务提供方须要提供例如以下主要的功能：

• 第 1、实现三个 Service endpoints，即：提供用于获取未授权的 Request Token 服务地址，获取用户授权的 Request Token 服务地址，以及使用授权的 Request Token 换取 Access Token 的服务地址。
• 第 2、提供基于 Form 的用户认证，以便于用户能够登录服务提供方做出授权。

• 第 3、授权的管理，比方用户能够在不论什么时候撤销已经做出的授权。

而对于消费方而言，须要例如以下的基本功能：

• 第 1、从服务提供方获取 Customer Key/Customer Secret。

• 第 2、提供与服务提供方之间基于 HTTP 的通信机制，以换取相关的令牌。

我们详细来看一个使用 OAuth 认证的样例

        在传统的站点应用中，假设您想在站点 A 导入站点 B 的联系人列表。须要在站点 A 输入您站点 B 的username、password信息。比如，您登陆 Plaxo (https://www.plaxo.com )，一个联系人管理站点，当您想把 GMail 的联系人列表导入到 Plaxo，您须要输入您的 GMail username / password。如图 所看到的：

在这里。Plaxo 承诺不会保存您在 Gmail 的password。

假设使用 OAuth 认证。情况是不同的，您不须要向站点 A（扮演 Consumer 角色）暴露您站点 B（扮演 Service Provider 角色）的username、password信息。比如。您登录 http://lab.madgex.com/oauth-net/googlecontacts/default.aspx 站点， 如图所看到的：

点击“Get my Google Contacts”，浏览器将会重定向到 Google。引导您登录 Google。如图

登录成功后，将会看到图

在您登录 Google。点击“Grant access”。授权 lab.madgex.com 后，lab.madgex.com 就能获得您在 Google 的联系人列表。

在上面的的样例中，站点 lab.madgex.com 扮演着 Consumer 的角色，而 Google 是 Service Provider，lab.madgex.com 使用基于 OAuth 的认证方式从 Google 获得联系人列表。