OAuth 2教程
原文：http://tutorials.jenkov.com/oauth2/index.html
OAuth 2.0是一种开放式授权协议，该协议使得应用程序可以访问彼此的数据。例如：一个游戏应用可以访问Facebook中的用户数据，或者基于位置的应用程序可以访问Foursquare应用程序的用户数据（user data）等。
OAuth 2.0被用于通过应用程序共享数据的示例如上图。
首先用户进入游戏的web应用，该应用要求用户通过Facebook账户登录，并定向到Facebook的登录界面，用户登录Facebook后，会重定向到之前的游戏应用。此时该应用就访问到了用户在Facebook的用户数据以及授权信息，并代表用户在Facebook中调用功能（例如发布状态更新）。
OAuth 2.0 用例
OAuth 2.0既可以用于在某个应用内访问其它应用的用户信息（比如上例中的游戏应用），又可以提供用户授权服务供其它应用调用（比如上例中的Facebook）。
OAuth 2.0是OAuth 1.0的替代，因为OAuth 1.0太复杂了，比如OAuth 1.0要求使用证书等。OAuth 2.0更加简单，不要求使用证书，仅使用SSL/TLS。
OAuth 2.0 规范
这个教程的目的是提供一个OAuth 2.0协议的概览以帮助理解，而不是涵盖此协议的所有细节。
如果你计划实现一个OAuth 2.0协议，最好是去阅读规范的详细内容，规范的地址：http://tools.ietf.org/html/draft-ietf-oauth-v2-23
OAuth 2.0 概述
在之前的介绍中我们提到，OAuth 2.0是一个开放标准，其允许某个应用程序访问其它应用程序的用户授权的数据。现在我们来介绍这个协议是如何工作的，以及规范中提到的各种概念。
OAuth 2.0 提供了不同的方式使得客户端应用获得权限去访问存储在资源服务器中的资源。现在介绍其中最安全和最常用的使用方式：一个web应用请求访问另一个web应用的资源。
下面的示例图描述了整个认证过程：
首先，用户访问客户端Web应用程序，在这个应用程序里有“通过Facebook登录”（或谷歌或Twitter等其他系统）的按钮。
第二步，当用户点击这个按钮时，用户被重定向到认证服务器（比如Facebook）。然后用户登录认证应用程序，登录成功后会被询问客户端应用是否可以使用他的用户信息。用户点击确认按钮。
OAuth 2.0 应用角色
OAuth 2.0定义了以下应用角色：
Resource Owner （资源所有者）
Resource Server （资源服务器）
Client Application （客户端应用）
Authorization Server （认证服务器）
Resource Owner ：资源所有者是拥有要共享的数据的人或应用程序。例如，facebook或google上的用户可能是资源所有者。他们拥有的资源是他们的数据。图中将资源所有者描述为一个人，这可能是最常见的情况。资源所有者也可以是应用程序。OAuth2.0规范提到了这两种可能性。
Resource Server ：资源服务器是承载资源的服务器。例如，facebook或google是资源服务器（或有一个资源服务器）。
Client Application ：客户端应用程序是请求访问存储在资源服务器上的资源的应用程序。这些资源是资源所有者拥有的资源。
Authorization Server：认证服务器是授权客户端应用访问资源所有者的资源的服务器。认证服务器和资源服务器可以是同一个服务器，也可以是独立的服务器。OAuth2.0规范没有说明这两个服务器应该如何通信（如果它们是独立的）。这是由资源服务器+认证服务器开发人员做出的内部设计决策。
OAuth 2.0 客户端类型
OAuth 2.0规范定义了2种客户端类型：
私密型
公开型
私密型客户端会保存client password。认证服务器会给每一个客户端应用生成一个client password，认证服务器通过该client password来识别该客户端应用是一个注册过的应用，而不是其它的欺诈程序。一个web应用可以是私密性客户端，只有系统管理员可以登录这个应用的服务器和查看client password。
公开型客户端不会保存client password。例如移动APP或桌面程序，如果client password被保存在此类应用中，就可以通过破解手段拿到client password，这是非常不安全的。在用户浏览器中运行的javascript应用程序也是如此。用户可以使用JavaScript调试器来查看应用程序，并查看client password。
客户端应用表现形式
Web Application （web应用）
User Agent （富web客户端）
Native （原生应用）
Web Application（web应用）
web应用程序运行在web服务器上。web应用做认证时用到的client password是保存在服务器上的，因此是私密的。下面是一个web应用的示例图：
User Agent Application（富web客户端）
富web客户端应用是指由javascript构建的web应用，浏览器是客户端代理。这类应用的特点是，程序是存放在web服务器上的，但是运行时，浏览器下载javascript程序到本地，直接在浏览器中执行，例如那些用javascript开发的网页版游戏。下面是一个富web客户端的示例图：
Native（原生应用）
（注：这里指没有后端服务器的应用，一次所有的数据和配置只能存放在客户端程序中）
原生应用包括移动APP和桌面程序。原生应用直接安装在用户的设备上（电脑或手机、平板），client password会保存在用户的设备里。下面是一个原生应用的示例图：
Hybrid（混合应用）
这类应用通常是将原生应用和web应用的开发技术混合在一起，也会有对应的后端服务器。OAuth 2.0规范中并没有提及此类应用，此类应用可以灵活选用上述三种认证类型中的任何一种。
OAuth 2.0 认证
Client ID, Client Secret and Redirect URI
Authorization Grant
Authorization Code
Implicit
Resource Owner Password Credentials
Client Credentials
当一个客户端应用要访问资源服务器上的资源时，需要先获取到认证授权（authorization grant）（也就是要先向认证服务器注册）。下面展示这个过程：
Client ID, Client Secret and Redirect URI
认证授权
资源所有者会给客户端应用认证授权，认证授权时需要认证服务器和资源服务器进行配合。
OAuth 2.0规范列举了4中认证授权方式，每种方式都有不同的安全特点：
Authorization Code（授权码模式）
Implicit（简化模式）
Resource Owner Password Credentials（用户密码模式）
Client Credentials
下面来对每一种授权方式进行解释。
Authorization Code（授权码模式）
Authorization Code（授权码）的认证过程如下：
1：资源所有者（用户）进入客户端应用。
2：客户端应用让用户通过认证服务器进行登录。
3：登录之前，客户端应用会把用户重定向到认证服务器的登录页面，同时客户端应用把自己的client id发送到认证服务器，这样认证服务器就知道是哪一个客户端应用在请求认证授权。
4：用户在认证服务器上进行登录，登录成功后，会提示用户是否要对客户端应用进行授权，用户选择同意后，会被重定向回客户端应用。
5：当重定向回客户端应用时，使用的是客户端应用在认证服务器上注册时填写的重定向URL，同时认证服务器会发送一个代表此次认证过程的一个授权码（authorization code）。
6：当成功重定向到客户端应用后，客户端应用会在后台与认证服务器进行交互，将上个步骤中获取到的授权码，连同client id,client password发送给认证服务器。
7：认证服务器对收到的数据进行校验，通过后发送access token给客户端应用。
10：这时客户端应用就可以用接收到的access token去资源服务器访问相关资源。下面是一个示例图：
Implicit（简化模式）
Implicit（简化模式）与Authorization Code（授权码模式）类似，区别仅在于当用户成功登录之后(登录认证服务器，完成授权)，重定向到客户端应用时，access token会直接返回给客户端应用。
这意味着access token在浏览器中是可见的。而Authorization Code（授权码模式），access token是在web服务器中的，对浏览器来说不可见。这是这两种模式的最大区别。
并且，客户端应用只发送client id到认证服务器。如果连同client password一起发送的话，client password需要存储在浏览器中，这会是一个安全隐患，很容易通过破解手段拿到存放在客户端应用程序中的client password。下面是一个示例图：
Resource Owner Password Credentials（用户密码模式）资源所有者密码模式
Resource Owner Password Credentials（密码模式）允许客户端应用直接使用资源所有者的用户名和密码。例如用户可以直接在客户端应用中录入Twitter的用户名和密码，然后客户端应用可以使用该用户名和密码访问Twitter中的资源。
只有在充分信任客户端应用的情况下，才能使用密码模式。（因为用户名和密码是在客户端应用中录入的，因此客户端应用可以获取并保存用户的用户名和密码）。
密码模式一般在富web客户端应用和原生应用中使用。
Client Credentials（客户端模式）
Client Credentials模式用于访问跟用户无关的资源，因此不需要用户授权。
OAuth 2.0 节点
OAuth 2.0定义了节点集合。一个节点一般是web服务器上的一个URL。例如，Java Servlet、JSP页面、PHP页面、ASP.NET页面等的地址(所谓的节点就是实现各自功能的页面)。具体包括：
认证节点
Token节点
重定向节点
认证节点和Token节点在认证服务器上，重定向节点在客户端应用上。示例图如下：
OAuth 2.0规范并没有对节点的URL做出明确的定义，不同的实现会提供不同的URL。
认证节点
认证节点是位于认证服务器的，让资源所有者登录并且授权给客户端应用。
Token节点
Token节点是认证服务器提供的，让客户端应用使用authorization code，client ID和client password交换获取access token的地址。
重定向节点
重定向节点在客户端应用中，当资源所有者在认证节点获得授权之后，会被重定向到此地址。
OAuth 2.0 请求和响应
当客户端应用请求认证和请求access token时，会发送http请求到认证节点和token节点。不同的认证授权类型会有不同的请求和响应内容。认证授权类型有4种：
Authorization Code（授权码模式）
Implicit（简化模式）
Resource Owner Password Credentials（用户密码模式）
Client Credentials
每种类型的请求和响应内容会在后续的内容中详细解释。
然而，以下文本中的信息主要是一个摘要。为了获得所有细节，您可能需要参考OAuth2.0规范，或者您试图集成的系统文档（Facebook、Twitter、Foursquare等）。
OAuth 2.0 Authorization Code（授权码模式）的请求和响应
授权码模式有2个请求和2个响应：
认证请求＋响应
access token请求＋响应。
认证请求
认证请求发送到认证服务器，然后会获取到一个授权码（ authorization code）。
以下是request中的参数：
response_type 必选项，且必须是固定值为 "code"
client_id 必选项, 客户端应用在认证服务器注册时生成的client id.
redirect_uri 可选项. 客户端应用在认证服务器注册时填写的重定向URL地址.（以为注册时候可能已经有写上了，所以这里是可选项）
scope 可选项. 请求的权限范围.
state 可选项 (建议提供). 客户端应用的请求URL中的参数，可以是任意值.
认证响应
认证响应含有授权码，这个授权码在后续获取access token时需要提供。
code 必选项. 认证服务器返回的授权码.
state 必选项, 如果客户端应用的请求中有这个参数，既为这个参数的值.
认证错误响应
授权错误的情形有2种。
第一种是客户端应用验证失败，例如认证请求中发送的重定向URL与客户端应用在认证服务器中注册时填写的URL不一致。在这种情况下，认证服务器不能将资源所有者重定向到重定向URI。相反，它应该将错误通知资源所有者。
第二种情况是客户端你应用被正确地认证，但是其他事情失败了。此时下面的错误信息会返回给客户端应用：
error Required. Must be one of a set of predefined error codes. See the specification for the codes and their meaning.
error_description Optional. A human-readable UTF-8 encoded text describing the error. Intended for a developer, not an end user.
error_uri Optional. A URI pointing to a human-readable web page with information about the error.
state Required, if present in authorization request. The same value as sent in the state parameter in the request.
Token请求
客户端应用获取到授权码后，可以用此授权码去获取access token。请求参数如下：
client_id Required. The client application's id. 客户端应用的client id
client_secret Required. The client application's client secret .客户端应用的client password
grant_type Required. Must be set to authorization_code .固定值authorization_code
code Required. The authorization code received by the authorization server. 授权码
redirect_uri Required, if the request URI was included in the authorization request. Must be identical then.
Token 响应
access token的响应内容是json格式的：
{ "access_token" : "...",
"token_type" : "...",
"expires_in" : "...",
"refresh_token" : "...",
}
access_token : 访问令牌,
token_type : 令牌类型，一般是bearer,
expires_in : 以秒为单位的令牌失效时间,
refresh_token : 当访问令牌失效时，可以用更新令牌获取一个新的访问令牌
OAuth 2.0 简化模式的请求和响应
简化模式只有一个请求和一个响应。
简化模式授权请求
该请求的参数如下：
response_type Required. Must be set to token .固定值token
client_id Required. The client identifier as assigned by the authorization server, when the client was registered.
redirect_uri Optional. The redirect URI registered by the client.
scope Optional. The possible scope of the request.
state Optional (recommended). Any client state that needs to be passed on to the client request URI.
简化模式授权响应
响应包含以下参数，注意该响应的格式不是json的。
access_token Required. The access token assigned by the authorization server.
token_type Required. The type of the token
expires_in Recommended. A number of seconds after which the access token expires.
scope Optional. The scope of the access token.
state Required, if present in the autorization request. Must be same value as state parameter in request.
简化模式授权错误响应
有2种情况会导致错误：
第一种是客户端应用验证失败，例如授权请求中发送的重定向URL与客户端应用在认证服务器中注册时填写的URL不一致。
第二种是产生了其它错误，此时下面的错误信息会返回给客户端应用：包含在重定向URL中
error Required. Must be one of a set of predefined error codes. See the specification for the codes and their meaning.
error_description Optional. A human-readable UTF-8 encoded text describing the error. Intended for a developer, not an end user.
error_uri Optional. A URI pointing to a human-readable web page with information about the error.
state Required, if present in authorization request. The same value as sent in the state parameter in the request.
用户密码模式的请求和响应
用户密码模式只有一个请求和响应。
用户密码模式的请求
请求包含以下参数：
grant_type 必选项. 固定值 "password"
username 必选项. UTF-8编码的用户名.用户名是资源所有者的用户名
password 必选项. UTF-8编码的密码. 密码是资源所有者的密码
scope 可选项. 请求的权限范围.
用户密码模式的响应
响应的内容是json格式：
{ "access_token" : "...",
"token_type" : "...",
"expires_in" : "...",
"refresh_token" : "...",
}
access_token : 访问令牌,
token_type : 令牌类型,
expires_in : 以秒为单位的令牌失效时间,
refresh_token : 当访问令牌失效时，可以用更新令牌获取一个新的访问令牌
客户端模式的请求和响应
客户端模式的请求
请求包含以下参数：
grant_type 必选项. 固定值 "client_credentials".
scope 可选项. 请求的权限范围.
客户端模式的响应
响应包含以下参数：
{ "access_token" : "...",
"token_type" : "...",
"expires_in" : "...",
}
access_token : 访问令牌,
token_type : 令牌类型,
expires_in : 以秒为单位的令牌失效时间,
注意，此种授权类型没有refresh_token
OAuth 2.0是一种开放式授权协议，该协议使得应用程序可以访问彼此的数据。例如：一个游戏应用可以访问Facebook中的用户数据，或者基于位置的应用程序可以访问Foursquare应用程序的用户数据（user data）等。
OAuth 2.0被用于通过应用程序共享数据的示例如上图。
首先用户进入游戏的web应用，该应用要求用户通过Facebook账户登录，并定向到Facebook的登录界面，用户登录Facebook后，会重定向到之前的游戏应用。此时该应用就访问到了用户在Facebook的用户数据以及授权信息，并代表用户在Facebook中调用功能（例如发布状态更新）。
OAuth 2.0 用例
OAuth 2.0既可以用于在某个应用内访问其它应用的用户信息（比如上例中的游戏应用），又可以提供用户授权服务供其它应用调用（比如上例中的Facebook）。
OAuth 2.0是OAuth 1.0的替代，因为OAuth 1.0太复杂了，比如OAuth 1.0要求使用证书等。OAuth 2.0更加简单，不要求使用证书，仅使用SSL/TLS。
OAuth 2.0 规范
这个教程的目的是提供一个OAuth 2.0协议的概览以帮助理解，而不是涵盖此协议的所有细节。
如果你计划实现一个OAuth 2.0协议，最好是去阅读规范的详细内容，规范的地址：http://tools.ietf.org/html/draft-ietf-oauth-v2-23
OAuth 2.0 概述
在之前的介绍中我们提到，OAuth 2.0是一个开放标准，其允许某个应用程序访问其它应用程序的用户授权的数据。现在我们来介绍这个协议是如何工作的，以及规范中提到的各种概念。
OAuth 2.0 提供了不同的方式使得客户端应用获得权限去访问存储在资源服务器中的资源。现在介绍其中最安全和最常用的使用方式：一个web应用请求访问另一个web应用的资源。
下面的示例图描述了整个认证过程：
首先，用户访问客户端Web应用程序，在这个应用程序里有“通过Facebook登录”（或谷歌或Twitter等其他系统）的按钮。
第二步，当用户点击这个按钮时，用户被重定向到认证服务器（比如Facebook）。然后用户登录认证应用程序，登录成功后会被询问客户端应用是否可以使用他的用户信息。用户点击确认按钮。
第三步，认证服务器将用户重定向到客户端应用提供的URI。这个重定向URI一般会在客户端应用在向认证服务器进行注册的时候提供给认证服务器的，在注册期间，客户端应用程序的所有者注册重定向URI。在这个注册过程中，认证服务器会生成一个client id和client password给客户端应用，向URI附加一个身份验证的code参数（authentication code），该参数是此次认证的一个标识。
第四步，重定向完成后，用户会进入重定向后的页面，同时客户端应用会在后台与认证服务器进行通讯，发送client id,client password和上一步获取到的code参数到认证服务器，认证服务器返回access token给客户端应用。
一旦客户端应用拿到了access token，就可以用这个token去访问Facebook提供的相关资源。
OAuth 2.0 应用角色
OAuth 2.0定义了以下应用角色：
Resource Owner （资源所有者）
Resource Server （资源服务器）
Client Application （客户端应用）
Authorization Server （认证服务器）
Resource Owner ：资源所有者是拥有要共享的数据的人或应用程序。例如，facebook或google上的用户可能是资源所有者。他们拥有的资源是他们的数据。图中将资源所有者描述为一个人，这可能是最常见的情况。资源所有者也可以是应用程序。OAuth2.0规范提到了这两种可能性。
Resource Server ：资源服务器是承载资源的服务器。例如，facebook或google是资源服务器（或有一个资源服务器）。
Client Application ：客户端应用程序是请求访问存储在资源服务器上的资源的应用程序。这些资源是资源所有者拥有的资源。
Authorization Server：认证服务器是授权客户端应用访问资源所有者的资源的服务器。认证服务器和资源服务器可以是同一个服务器，也可以是独立的服务器。OAuth2.0规范没有说明这两个服务器应该如何通信（如果它们是独立的）。这是由资源服务器+认证服务器开发人员做出的内部设计决策。
OAuth 2.0 客户端类型
OAuth 2.0规范定义了2种客户端类型：
私密型
公开型
私密型客户端会保存client password。认证服务器会给每一个客户端应用生成一个client password，认证服务器通过该client password来识别该客户端应用是一个注册过的应用，而不是其它的欺诈程序。一个web应用可以是私密性客户端，只有系统管理员可以登录这个应用的服务器和查看client password。
公开型客户端不会保存client password。例如移动APP或桌面程序，如果client password被保存在此类应用中，就可以通过破解手段拿到client password，这是非常不安全的。在用户浏览器中运行的javascript应用程序也是如此。用户可以使用JavaScript调试器来查看应用程序，并查看client password。
客户端应用表现形式
Web Application （web应用）
User Agent （富web客户端）
Native （原生应用）
Web Application（web应用）
web应用程序运行在web服务器上。web应用做认证时用到的client password是保存在服务器上的，因此是私密的。下面是一个web应用的示例图：
User Agent Application（富web客户端）
富web客户端应用是指由javascript构建的web应用，浏览器是客户端代理。这类应用的特点是，程序是存放在web服务器上的，但是运行时，浏览器下载javascript程序到本地，直接在浏览器中执行，例如那些用javascript开发的网页版游戏。下面是一个富web客户端的示例图：
Native（原生应用）
（注：这里指没有后端服务器的应用，一次所有的数据和配置只能存放在客户端程序中）
原生应用包括移动APP和桌面程序。原生应用直接安装在用户的设备上（电脑或手机、平板），client password会保存在用户的设备里。下面是一个原生应用的示例图：
Hybrid（混合应用）
这类应用通常是将原生应用和web应用的开发技术混合在一起，也会有对应的后端服务器。OAuth 2.0规范中并没有提及此类应用，此类应用可以灵活选用上述三种认证类型中的任何一种。
OAuth 2.0 认证
Client ID, Client Secret and Redirect URI
Authorization Grant
Authorization Code
Implicit
Resource Owner Password Credentials
Client Credentials
当一个客户端应用要访问资源服务器上的资源时，需要先获取到认证授权（authorization grant）（也就是要先向认证服务器注册）。下面展示这个过程：
Client ID, Client Secret and Redirect URI
客户端应用要访问资源服务器的资源之前，必须向与资源服务器关联的认证服务器注册。
注册通常是一次性任务，一旦注册，注册将保持有效，除非客户端应用注册被撤销。注册完成后，认证服务器会生成这个应用的client id和client password。client_id和client_password在同一个认证服务器中是唯一的，不会重复。客户端应用可以在多个认证服务器中进行注册（如分别在Facebook和Google中注册），不同的认证服务器会为客户端应用生成不同的client_id和client_password。
注册通常是一次性任务，一旦注册，注册将保持有效，除非客户端应用注册被撤销。注册完成后，认证服务器会生成这个应用的client id和client password。client_id和client_password在同一个认证服务器中是唯一的，不会重复。客户端应用可以在多个认证服务器中进行注册（如分别在Facebook和Google中注册），不同的认证服务器会为客户端应用生成不同的client_id和client_password。
当客户端应用需要访问资源服务器上的资源时，首选要通过认证服务器进行认证，认证时要发送对应的client_id和client_password到认证服务器。
客户端应用在向认证服务器进行注册时，需要填写一个重定向URL。当资源所有者对客户端应用进行授权成功后，资源所有者（可简单理解为系统用户）会被重定向到重定向URL所指定的页面。
认证授权
资源所有者会给客户端应用认证授权，认证授权时需要认证服务器和资源服务器进行配合。
OAuth 2.0规范列举了4中认证授权方式，每种方式都有不同的安全特点：
Authorization Code（授权码模式）
Implicit（简化模式）
Resource Owner Password Credentials（用户密码模式）
Client Credentials
下面来对每一种授权方式进行解释。
Authorization Code（授权码模式）
Authorization Code（授权码）的认证过程如下：
1：资源所有者（用户）进入客户端应用。
2：客户端应用让用户通过认证服务器进行登录。
3：登录之前，客户端应用会把用户重定向到认证服务器的登录页面，同时客户端应用把自己的client id发送到认证服务器，这样认证服务器就知道是哪一个客户端应用在请求认证授权。
4：用户在认证服务器上进行登录，登录成功后，会提示用户是否要对客户端应用进行授权，用户选择同意后，会被重定向回客户端应用。
5：当重定向回客户端应用时，使用的是客户端应用在认证服务器上注册时填写的重定向URL，同时认证服务器会发送一个代表此次认证过程的一个授权码（authorization code）。
6：当成功重定向到客户端应用后，客户端应用会在后台与认证服务器进行交互，将上个步骤中获取到的授权码，连同client id,client password发送给认证服务器。
7：认证服务器对收到的数据进行校验，通过后发送access token给客户端应用。
10：这时客户端应用就可以用接收到的access token去资源服务器访问相关资源。下面是一个示例图：
Implicit（简化模式）
Implicit（简化模式）与Authorization Code（授权码模式）类似，区别仅在于当用户成功登录之后(登录认证服务器，完成授权)，重定向到客户端应用时，access token会直接返回给客户端应用。
这意味着access token在浏览器中是可见的。而Authorization Code（授权码模式），access token是在web服务器中的，对浏览器来说不可见。这是这两种模式的最大区别。
并且，客户端应用只发送client id到认证服务器。如果连同client password一起发送的话，client password需要存储在浏览器中，这会是一个安全隐患，很容易通过破解手段拿到存放在客户端应用程序中的client password。下面是一个示例图：
Resource Owner Password Credentials（用户密码模式）资源所有者密码模式
Resource Owner Password Credentials（密码模式）允许客户端应用直接使用资源所有者的用户名和密码。例如用户可以直接在客户端应用中录入Twitter的用户名和密码，然后客户端应用可以使用该用户名和密码访问Twitter中的资源。
只有在充分信任客户端应用的情况下，才能使用密码模式。（因为用户名和密码是在客户端应用中录入的，因此客户端应用可以获取并保存用户的用户名和密码）。
密码模式一般在富web客户端应用和原生应用中使用。
Client Credentials（客户端模式）
Client Credentials模式用于访问跟用户无关的资源，因此不需要用户授权。
OAuth 2.0 节点
OAuth 2.0定义了节点集合。一个节点一般是web服务器上的一个URL。例如，Java Servlet、JSP页面、PHP页面、ASP.NET页面等的地址(所谓的节点就是实现各自功能的页面)。具体包括：
认证节点
Token节点
重定向节点
认证节点和Token节点在认证服务器上，重定向节点在客户端应用上。示例图如下：
OAuth 2.0规范并没有对节点的URL做出明确的定义，不同的实现会提供不同的URL。
认证节点
认证节点是位于认证服务器的，让资源所有者登录并且授权给客户端应用。
Token节点
Token节点是认证服务器提供的，让客户端应用使用authorization code，client ID和client password交换获取access token的地址。
重定向节点
重定向节点在客户端应用中，当资源所有者在认证节点获得授权之后，会被重定向到此地址。
OAuth 2.0 请求和响应
当客户端应用请求认证和请求access token时，会发送http请求到认证节点和token节点。不同的认证授权类型会有不同的请求和响应内容。认证授权类型有4种：
Authorization Code（授权码模式）
Implicit（简化模式）
Resource Owner Password Credentials（用户密码模式）
Client Credentials
每种类型的请求和响应内容会在后续的内容中详细解释。
然而，以下文本中的信息主要是一个摘要。为了获得所有细节，您可能需要参考OAuth2.0规范，或者您试图集成的系统文档（Facebook、Twitter、Foursquare等）。
OAuth 2.0 Authorization Code（授权码模式）的请求和响应
授权码模式有2个请求和2个响应：
认证请求＋响应
access token请求＋响应。
认证请求
认证请求发送到认证服务器，然后会获取到一个授权码（ authorization code）。
以下是request中的参数：
response_type 必选项，且必须是固定值为 "code"
client_id 必选项, 客户端应用在认证服务器注册时生成的client id.
redirect_uri 可选项. 客户端应用在认证服务器注册时填写的重定向URL地址.（以为注册时候可能已经有写上了，所以这里是可选项）
scope 可选项. 请求的权限范围.
state 可选项 (建议提供). 客户端应用的请求URL中的参数，可以是任意值.
认证响应
认证响应含有授权码，这个授权码在后续获取access token时需要提供。
code 必选项. 认证服务器返回的授权码.
state 必选项, 如果客户端应用的请求中有这个参数，既为这个参数的值.
认证错误响应
授权错误的情形有2种。
第一种是客户端应用验证失败，例如认证请求中发送的重定向URL与客户端应用在认证服务器中注册时填写的URL不一致。在这种情况下，认证服务器不能将资源所有者重定向到重定向URI。相反，它应该将错误通知资源所有者。
第二种情况是客户端你应用被正确地认证，但是其他事情失败了。此时下面的错误信息会返回给客户端应用：
error Required. Must be one of a set of predefined error codes. See the specification for the codes and their meaning.
error_description Optional. A human-readable UTF-8 encoded text describing the error. Intended for a developer, not an end user.
error_uri Optional. A URI pointing to a human-readable web page with information about the error.
state Required, if present in authorization request. The same value as sent in the state parameter in the request.
Token请求
客户端应用获取到授权码后，可以用此授权码去获取access token。请求参数如下：
client_id Required. The client application's id. 客户端应用的client id
client_secret Required. The client application's client secret .客户端应用的client password
grant_type Required. Must be set to authorization_code .固定值authorization_code
code Required. The authorization code received by the authorization server. 授权码
redirect_uri Required, if the request URI was included in the authorization request. Must be identical then.
Token 响应
access token的响应内容是json格式的：
{ "access_token" : "...",
"token_type" : "...",
"expires_in" : "...",
"refresh_token" : "...",
}
access_token : 访问令牌,
token_type : 令牌类型，一般是bearer,
expires_in : 以秒为单位的令牌失效时间,
refresh_token : 当访问令牌失效时，可以用更新令牌获取一个新的访问令牌
OAuth 2.0 简化模式的请求和响应
简化模式只有一个请求和一个响应。
简化模式授权请求
该请求的参数如下：
response_type Required. Must be set to token .固定值token
client_id Required. The client identifier as assigned by the authorization server, when the client was registered.
redirect_uri Optional. The redirect URI registered by the client.
scope Optional. The possible scope of the request.
state Optional (recommended). Any client state that needs to be passed on to the client request URI.
简化模式授权响应
响应包含以下参数，注意该响应的格式不是json的。
access_token Required. The access token assigned by the authorization server.
token_type Required. The type of the token
expires_in Recommended. A number of seconds after which the access token expires.
scope Optional. The scope of the access token.
state Required, if present in the autorization request. Must be same value as state parameter in request.
简化模式授权错误响应
有2种情况会导致错误：
第一种是客户端应用验证失败，例如授权请求中发送的重定向URL与客户端应用在认证服务器中注册时填写的URL不一致。
第二种是产生了其它错误，此时下面的错误信息会返回给客户端应用：包含在重定向URL中
error Required. Must be one of a set of predefined error codes. See the specification for the codes and their meaning.
error_description Optional. A human-readable UTF-8 encoded text describing the error. Intended for a developer, not an end user.
error_uri Optional. A URI pointing to a human-readable web page with information about the error.
state Required, if present in authorization request. The same value as sent in the state parameter in the request.
用户密码模式的请求和响应
用户密码模式只有一个请求和响应。
用户密码模式的请求
请求包含以下参数：
grant_type 必选项. 固定值 "password"
username 必选项. UTF-8编码的用户名.用户名是资源所有者的用户名
password 必选项. UTF-8编码的密码. 密码是资源所有者的密码
scope 可选项. 请求的权限范围.
用户密码模式的响应
响应的内容是json格式：
{ "access_token" : "...",
"token_type" : "...",
"expires_in" : "...",
"refresh_token" : "...",
}
access_token : 访问令牌,
token_type : 令牌类型,
expires_in : 以秒为单位的令牌失效时间,
refresh_token : 当访问令牌失效时，可以用更新令牌获取一个新的访问令牌
客户端模式的请求和响应
客户端模式的请求
请求包含以下参数：
grant_type 必选项. 固定值 "client_credentials".
scope 可选项. 请求的权限范围.
客户端模式的响应
响应包含以下参数：
{ "access_token" : "...",
"token_type" : "...",
"expires_in" : "...",
}
access_token : 访问令牌,
token_type : 令牌类型,
expires_in : 以秒为单位的令牌失效时间,
注意，此种授权类型没有refresh_token
评论
发表评论