引用（http://www.cnblogs.com/artech/p/oauth-01.html）
OAuth 2.0的角色
获得资源拥有者授权的第三方应用请求受保护的资源采用的不是授权者的凭证，所有一个被称为Access Token的安全令牌。Access Token颁发过程会涉及到若干不同的“实体”，它们在这个过程中扮演者不同的角色，我们通过一个具体的场景来认识一下该过程中涉及到的几种角色。
假设我们开发了一个集成了新浪微博认证的用于发布打折商品消息的App，经过用户授权之后它可以调用新浪微博的Web API获取用户的电子邮箱地址并发布相应的打折消息。那么OAuth 2.0在这个场景中的作用就在于：用户授权该应用以自己的名义调用新浪微博的Web API获取自己的电子邮箱地址，整个过程涉及到如下4种角色。
- 资源拥有者（RO：Resource Owner）：资源的拥有者也是授权者，如果它是一个“人”，一般就是指最终用户。由于“资源”在这个场景中表示为用户的电子邮箱地址，所以资源拥有者自然就是指最终用户。
- 客户端应用（Client）：需要取得资源拥有者授权并最终访问受保护资源的应用，对于我们的场景来说，就是我们创建的App。
- 资源服务器（Resource Server）：最终承载资源的服务器，它一般体现为一个可被调用的Web API。对于我们提供的场景来说，客户端通过调用新浪微博得Web API获得用户的电子邮箱地址，所以新浪微博就是资源服务器。
- 授权服务器（Authorization Server）：它对用户（一般情况下为资源拥有者）和客户端应用实施认证，并在用户授权的情况下向客户端应用颁发Access Token。在我们提供的场景中，资源服务器和认证服务器合二为一，均为新浪微博。
客户端凭证
一般来说，如果我们需要针对某种类型的第三方认证服务来开发我们自己的应用，我们需要向采用的认证服务提供商对该应用进行注册，注册成功之后会得到一个唯一标识该应用的ClientID和对应的ClientSecret（ClientID/ClientSecret是Windows Live Connect 的说法，Twitter和Facebook分别叫做ConsumerKey/ComsumerSecret和AppID/AppSecret。如果采用Google提供的OAuth 2.0 API，ClientID和ClientSecret是不需要的。）。它们相当于客户端应用的凭证，认证服务利用它们来确定其真实身份。
接下来我们简单演示一下如何为集成Windows Live Connect API的应用注册一个ClientID。我们利用浏览器直接访问https://account.live.com/developers/applications，如果当前用户尚未登录，浏览器会自动重定向到登录窗口。当我们采用某个Windows Live帐号完成登录之后，如下图所示的“Windows Live Developer Center”页面会呈现出来。
然后我们直接点击“Create application”连接创建一个新的应用。我们只需要在显示页面的“Application name”文本框中为创建的应用设置一个名称，同时在“Language”下拉框中选择适合的语言。如下图所示，我们为创建的应用取名为“AppDemo”。
当我们点击“I accept”按钮之后，应用被成功创建，相应的ClientID和ClientSecret也被生成出来。如下图所示，ClientID和ClientSecret的值分别为“000000004410A2A5”和“HeIrRmGyHHtMqhBDJipfGiauQnSHtYUX”。除此之外，我们要需要设置重定向地址的域名，Windows Live向客户端应用发送Access Token，以及其他数据采用的URI必须采用此域名，我们在下图中指定的域名为“https://www.artech.com”。域名成功设置之后，点击“Save”按钮之后整个注册工作结束。
处理流程
然OAuth 2.0具体采用的执行流程因采用不同类型的授权方式而有所不同，但是整个流程大体上由客户端应用分别与资源拥有者、授权服务器和资源服务器进行的3轮交互来完成。这个过程基本上体现在下图中，这被称为经典的“Three-Legged OAuth”。
客户端应用试图获取某个受保护的资源，首先得取得资源拥有者的授权，所以第一轮消息交换旨在让客户端获得资源拥有者（即用户）的授权。客户端应用得到授权之后会得到一个被称为Authorization Grant的对象，该对象实际上就是一个简单的字符串用以表示成功取得了用户的授权。接下来客户端应用利用此Authorization Grant向授权服务取获取用于访问受保护资源所需的Access Token。在成功获得Access Token之后，客户端应用将其附加到针对资源服务器的请求中以获取它所需要的目标资源。
Authorization Grant
OAuth 2.0的执行流程有点类似于的Kerberos认证：客户端先获得“认购权证”TGT（Ticket Granting Ticket），再利用TGT购买“入场券”ST（Service Ticket），最后凭借ST进行服务调用。对于OAuth 2.0来说，Access Token相当于Kerberos的ST，而Authorization Grant则与TGT具有相同的作用。
OAuth 2.0中的Authorization Grant代表一种中间凭证（Intermediate Credential），它代表了资源拥有者针对客户端应用获取目标资源的授权。OAuth 2.0定义了如下4种Authorization Grant类型，我们也可以利用定义其中的扩展机制定制其他类型的Authorization Grant。Authorization Grant的类型体现了授权采用的方式以及Access Token的获取机制。
- Implicit：它代表一种“隐式”授权方式，即客户端在取得资源拥有者（最终用户）授权的情况下直接获取Access Token，而不是间接地利用获取的Authorization Grant来取得Access Token。换句话说，此种类型的Authorization Grant代表根本不需要Authorization Grant，那么上面介绍的“Three-Legged OAuth”变成了“Two-Legged OAuth”。
- Authorization Code：这是最为典型的Authorization Grant，客户端应用在取得资源拥有者授权之后会从授权服务器得到一个Authorization Code作为Authorization Grant。在它获取寄宿于资源服务器中的目标资源之前，需要利用此Authorization Code从授权服务器获取Access Token。
- Resource Owner Password Credentials：资源拥有者的凭证直接作为获取Access Token的Authorization Grant。这种Authorization Grant类型貌似与OAuth设计的初衷向违背（OAuth的主要目的在于让客户端应用在不需要提供资源拥有者凭证的情况下能够以他的名义获取受保护的资源），但是如果客户端程序是值得被信任的，用户（资源拥有者）向其提供自己的凭证也是可以接受的。
- Client Credentials：客户端应用自身的凭证直接作为它用于获取Access Token的Authorization Grant。这种类型的Authorization Grant适用于客户端应用获取属于自己的资源，换句话说客户端应用本身相当于资源的拥有者。