The Oauth2.0 Authorization Framework翻译part2
第一部分
2.客户端注册Client Registration
在开始使用协议之前，客户端向认证服务器注册。客户端注册的方法超过了本规格的范围，不过通常是终端用户与html注册表交互
客户端注册不需要客户端与认证服务器之间的直接交互。
Client registration does not require a direct interaction between the client and the authorization server. When supported by the authorization server, registration can rely on other means for establishing trust and obtaining the required client properties (e.g., redirection URI, client type). For example, registration can be accomplished using a self-issued or third-party-issued assertion, or by the authorization server performing client discovery using a trusted channel.
客户端开发者在注册客户端时需要：
指明如2.1节中描述的客户端类型
提供如3.1.2节中描述的客户端跳转URIs
需要包含其他所有认证服务器需要的信息（例如，应用名称，主页，描述，logo）
2.1 客户端的类型
Oauth基于客户端与认证服务器验证的能力定义了两种客户端类型（以及，维护客户端认证信息的能力）
获信的
客户端有能力保证他们认证信息的安全（比如，客户端应用在安全的服务器，客户端认证信息具有受限的访问权限），或者有能力使用其他手段保护客户端认证
公开的
客户端没有能力保证认证信息的安全性（比如，客户端运行在资源拥有者使用的设备上，像本地应用或者基于浏览器的应用），而且没有能力使用其他手段保护客户端认证
客户单类型设定基于认证服务器对认证安全的定义和它可接受暴露的客户端认证信息等级。认证服务器不应该对客户端类型做任何假定
一个客户端可能会被实现为一组分布式的组件，每个有不同的客户端类型和安全环境（比如，一个客户端既有获信的server-based组件，也有公开的基于浏览器的组件）。如果认证服务器不对这样的客户端提供支持，客户端需要把每个组件注册为独立的客户端。
本规格针对以下客户端配置进行设计：
web应用：
web应用是一个运行在web服务器上的受信客户端。资源拥有者通过所使用的用户代理渲染html界面来访问客户端。客户端认证信息和分发给客户端的访问令牌一样存储于web服务器，并且不向资源拥有者暴露
浏览器应用：
一个基于浏览器的应用是一个从web服务器下载code并运行在浏览器之中的公开客户端。协议信息和认证信息很容易被资源拥有者访问。这样的应用在请求认证的时候可以无缝的使用浏览器的功能。
本地应用：
本地应用是一个安装并运行在资源拥有者所持有的设备上的公开客户端。协议数据和认证信息对资源拥有者来说是可访问的，如果假定任何本地应用包含的任何认证信息都是可以被抽取出来的话。另一方面，动态的下发像访问令牌或刷新令牌这样的认证信息可以获得可接受的保护等级。最低限度，these credentials are protected from hostile servers with which the application may interact,在一些平台上，这些认证信息对于其他属于相同设备的应用可能是受保护的
2.2客户端标识
认证服务器给客户端下发客户端标识--一个代表了注册信息的唯一字符串。客户端标识不是秘密；它被暴露给资源拥有者，并且不能单独用来客户端验证。客户端标识对认证服务器来说是唯一的。
客户端标识字符串的长度并不在本规格书中定义。客户端应该避免对标识大小做假定。认证服务器应该将它下发的标识大小写入文档
2.3 客户端验证
如果客户端类型是受信的，客户端和认证服务器建立适合于认证服务器安全需要的客户端验证方法。认证服务器可以接受任何形式的客户端认证查看他的安全需要。
受信客户端通常建立一个用来与认证服务器认证的客户端认证信息结合（如，密码，公有/私有 键值对）
认证服务器可以与公开客户端机建立一个客户端认证方法，然而，认证服务器不可以依赖公开客户端认证进行客户端身份识别。
客户端在每次请求中不可以使用超过一次认证方法
2.3.1客户端密码
客户端可以使用http基本认证来与认证服务器进行认证。客户端标识使用urlencoded进行编码；客户端密码使用相同的编码方式。认证服务器必须对被下发了客户端密码的认证客户端提供HTTP基本认证。
例如（额外的换行符只是为了格式更好看）
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
作为一种选择，认证服务器可以提供使用以下参数的方式在请求体中包含客户端认证信息：
client_id
必需的。是在注册过程中下发给客户端的客户端标识。描述与2.2节
client_secret
必需的。客户端密钥。如果客户端密钥是空串，可以省略这个参数
将客户端认证信息包含在请求体中是不被推荐的，适用场合应该限制于客户端不能直接利用HTTP基本认证的情况下。参数只能在请求体而不是请求url中传输。
例子：请求刷新访问令牌，并将参数包含在请求体中：
POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA &client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw
认证服务器在使用密码发送认证请求时必需使用TLS（见1.6节）
既然客户端认证方法包含了密码，认证服务器必需保护任何终端免受暴力攻击
2.3.2其他认证方法
认证服务器可以支持任何满足安全需要的HTTP认证方案。当使用其他认证方法，认证服务器必需定义客户端标识与认证方法之间的对应关系。
2.4 未注册的客户端
本规格书并没有排除未注册客户单的的使用，然而，这样的客户端超出了本规格的范围而且需要额外的安全分析和检查交互。
3协议接口
认证过程需要使用两个认证服务器接口：
- 授权接口--客户端用来获取授权，授权者是资源拥有者，通过用户代理重定向。
- 令牌接口--客户端用来通过授权码交换一个访问令牌，通常也需要客户端验证
还需要一个客户端接口：
- 重定向接口--由认证服务器使用，返回一个包含了授权认证信息的响应给客户端，通过资源拥有者的用户代理实现
不是所有的授权类型都需要使用所有的接口。另外扩展的授权类型可能会按照需要定义额外的接口
3.1 授权接口
授权接口用来与资源拥有者交互并获取一个授权。认证服务器必须首先核实资源拥有者的身份。认证服务器验证资源拥有者身份的方式超出了本规格书的范围（比如，用户名密码登陆，session cookies）
客户端获取认证接口地址的方式超出了本规格的范围，不过通常地址在服务文档中提供。
接口uri可以包含"application/x-www-form-urlencoded"格式查询组件，添加额外参数的时候必须保留。接口uri必须不能包含不完整的组件。
因为请求授权接口的时候导致进行用户验证并传输明文的认证信息，所以在请求授权接口的时候授权服务器需要使用TLS。
授权服务器必须提供对get方式的支持，也可能需要支持post方式。
没有值的参数必须被假定为请求里面忽略了它们。授权服务器必须忽略不被承认的请求参数。请求和相应的参数必须不能包含多于一次。
3.1.1响应类型
授权接口被授权码类型和隐式授权类型使用。客户端通过以下参数通知认证服务器它想要的授权类型：
响应类型
必需的。它的值必须是4.1.1节中描述的请求授权码中的一种“code”，“token”是用来请求访问令牌（隐式授权），被描述于4.2.1节，或者是8.4节中描述的注册扩展值
扩展的响应类型可以包含返回值的空间列表，值的顺序没什么关系。这样的复合响应类型的意义被定义于他们各自的规格中。
如果一个认证请求缺失了“response_type”参数，或者响应类型不可理解，认证服务器必须返回一个错误响应(描述于4.1.2.1节)
3.1.2重定向接口
在完成了与资源拥有者的交互后，认证服务器把资源拥有者的用户代理导向回客户端。认证服务器重定向用户代理到之前注册应用或是发起授权请求时确定的客户端重定向接口。
重定向接口uri必须符合4.3节的定义。接口uri可能包含"application/x-www-form-urlencoded"格式查询组件（3.4节），在添加额外查询参数时它必须被保留。接口URI不可以包含不完整的组件。
3.1.2.2接口请求加密
重定向接口在请求响应类型为“code”和“token”时或是重定向请求会导致名门传输认证信息时需要使用1.6节中描述的TLS，本规格不强制要求使用TLS，因为在此规格编写时，要求客户端部署TLS对许多开发者来说是一个障碍。如果TLS不可用，认证服务器应该警告资源拥有者关于接口重定向的不安全性。（比如在认证请求过程中显示一个提示信息）
缺乏传输层的安全性会对客户端和客户端访问的受保护资源的安全性产生严重的影响。在认证过程的形式为委托最终用户验证客户端时安全传输层的用处特别重要。（比如第三方登录服务）
3.1.2.2 注册要求
认证服务器必须要求以下客户端注册他们的重定向接口：
- 公开客户端
- 使用隐式授权的受信客户端
认证服务器应该需要所有使用认证接口的客户端注册重定向接口。
认证服务器应该需要客户端提供完整的重定向uri（客户端可能使用“state”请求参数达到请求的客户化）。如果不可能要求注册完整的重定向URI，the
authorization server SHOULD require the registration of the URI
scheme, authority, and path (allowing the client to dynamically vary
only the query component of the redirection URI when requesting
authorization).
认证服务器可能允许客户端注册多个重定向接口。
缺乏重定向接口需要的重定向URI注册可能引起攻击者把认证接口当成公开的转向器进行攻击（描述与10.15节）
3.1.2.3动态配置
如果注册了多个重定向uri，或者只有部分重定向uri被注册，或者没有重定向接口被注册，客户端必须在认证请求中柏寒“redirect_uri”请求参数。
当重定向uri包含在认证请求中，认证服务器必须把参数与被注册的重定向uri进行比较匹配（描述与6节），当有任何一个重定向uri被注册过的时候。如果客户端注册包含了完整的重定向uri，认证服务器必须使用简单字符串比较来比较两个uri（描述于[RFC3986] Section 6.2.1.）3.1.2.4.无效接口
如果一个认证请求无效，认证服务器应该通知资源拥有者，而且不能自动重定向用户代理到失效的重定向uri。
3.1.2.5 接口内容
对客户端接口的重定向请求通常导致由用户代理处理的HTML响应。如果html响应直接由重定向请求服务，任何包含在html中的脚本都可以执行重定向接口和它包含的认证信息。
客户端不应该在重定向响应中包含任何第三方脚本。代替的，它应该从uri中提取认证信息并再次重定向用户代理到另外一个不会暴露认证信息的接口（在uri和任何地方）。如果包含了第三方脚本，客户端必须保证它自己的脚本会先执行（用来提取和从uri中删除认证信息的脚本）。
3.2令牌接口
客户端通过呈现它的授权信息或是刷新令牌使用令牌接口获取访问令牌。除了隐式授权类型（因为访问令牌被直接下发）之外所有的认证授权都需要使用令牌接口。
客户端获取令牌接口的手段超出了本规格的范围，但通常由服务的文档中提供。
The endpoint URI MAY include an "application/x-www-form-urlencoded" formatted (per Appendix B) query component ([RFC3986] Section 3.4), which MUST be retained when adding additional query parameters. The endpoint URI MUST NOT include a fragment component.
Since requests to the token endpoint result in the transmission of clear-text credentials (in the HTTP request and response), the authorization server MUST require the use of TLS as described in Section 1.6 when sending requests to the token endpoint. The client MUST use the HTTP "POST" method when making access token requests. Parameters sent without a value MUST be treated as if they were omitted from the request. The authorization server MUST ignore unrecognized request parameters. Request and response parameters MUST NOT be included more than once.
3.2.1.客户端验证
在发起对令牌接口的请求时，受信客户端或是其他被下发了客户端认证信息的客户端必须与认证服务器进行认证。客户端验证被用来：
- 把刷新令牌和授权码强制绑定于被下发的客户端。当授权码在一个不安全的通道上明文传输或是重定向uri没有完整注册时，客户端验证是危险的。
- 可以让一个客户端失效或改变它的认证信息，因此可以防御攻击者滥用偷到的刷新令牌。改变一个单独的用户信息集合显然比撤销整个刷新令牌集合更快
- 实现了认证管理的最佳实践， which require periodic credential rotation.Rotation of an entire set of refresh tokens can be challenging, while rotation of a single
set of client credentials is significantly easier.
一个客户端可以使用“client_id”参数在发起令牌接口时识别自己的身份。在“授权码”请求令牌接口时，一个未经验证的客户端必须发送它的“client_id”来避免接受了另一个客户端。这代替了授权码保护了客户端（它并不会给受保护资源提供额外保护）
3.3访问令牌范围
The authorization and token endpoints allow the client to specify the
scope of the access request using the "scope" request parameter. In
turn, the authorization server uses the "scope" response parameter to
inform the client of the scope of the access token issued.
The value of the scope parameter is expressed as a list of space-
delimited, case-sensitive strings. The strings are defined by the
authorization server. If the value contains multiple space-delimited
strings, their order does not matter, and each string adds an
additional access range to the requested scope.
scope = scope-token *( SP scope-token )
scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
The authorization server MAY fully or partially ignore the scope
requested by the client, based on the authorization server policy or
the resource owner's instructions. If the issued access token scope
is different from the one requested by the client, the authorization
server MUST include the "scope" response parameter to inform the
client of the actual scope granted.
If the client omits the scope parameter when requesting
authorization, the authorization server MUST either process the
request using a pre-defined default value or fail the request
indicating an invalid scope. The authorization server SHOULD
document its scope requirements and default value (if defined).
4获取授权
为了请求一个访问令牌，客户端从资源拥有者获取授权。授权被表示为一种可以用来请求访问令牌的形式。Oauth定义了四种授权类型“认证码，隐式，资源拥有者密码认证，和客户端认证信息。它也为额外的授权类型提供了扩展机制
4.1认证码授权
Authorization Code Grant
The authorization code grant type is used to obtain both access
tokens and refresh tokens and is optimized for confidential clients.
Since this is a redirection-based flow, the client must be capable of
interacting with the resource owner's user-agent (typically a web
browser) and capable of receiving incoming requests (via redirection)
from the authorization server.
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
Note: The lines illustrating steps (A), (B), and (C) are broken into
two parts as they pass through the user-agent.
Figure 3: Authorization Code Flow
示例图包含了一下步骤：
（A）客户端通过引导资源拥有者的用户代理到验证终端启动过程。客户端包含它的客户端标识，请求范围，localstate，和一个重定向URI，当访问被授权时，认证服务器会把这个重定向URI发回。
（B）认证服务器验证资源拥有者（通过用户代理），无论资源拥有者是否授权访问请求
（C）假设资源拥有者授权了访问，认证服务器把用户代理重定向回之前客户端提供的重定向URI。重定向URI包含认证码和任何客户端之前提供的本地状态。
（D）客户端通过认证服务器的令牌终端请求一个访问令牌，请求中包含了之前获得的认证码。发起这个请求时，客户端与认证服务器验证。客户端包含的重定向URI用来获得认证码。
（E）认证服务器验证客户端，验证认证码，并确保收到的重定向URI匹配步骤C中的URI。如果有效，认证服务器响应回一个访问令牌。也可以选择返回一个刷新令牌。
(D) The client requests an access token from the authorization
server's token endpoint by including the authorization code
received in the previous step. When making the request, the
client authenticates with the authorization server. The client
includes the redirection URI used to obtain the authorization
code for verification.
(E) The authorization server authenticates the client, validates the
authorization code, and ensures that the redirection URI
received matches the URI used to redirect the client in
step (C). If valid, the authorization server responds back with
an access token and, optionally, a refresh token.
