Oauth2(3)授权端点

授权过程采用两种授权端点：

授权端点--客户端通过用户代理重定向从资源拥有者以获得授权

令牌端点--客户端使用授权许可交换访问令牌，通常伴有客户端认证

以及另一种客户端端点

重定向端点--授权服务器用于通过资源所有者用户代理向客户端返回含有授权凭据的响应。

不是每个授权类型都用所有的端点，扩展的授权类型可能会定义附加的端点

1授权端点

授权端点用于和资源拥有者交互并且获取一个授权许可。授权服务器首先必须验证资源拥有者身份。但该规范并为定义授权服务器验证资源拥有者的方式（比如账号密码，session cookies）。

获取授权端点位置同样未定义。

端点URI可能包含application/x-www-form-urlencoded格式的查询部分，添加额外查询参数时必须保留该部分。端点URI一定不能包含fragment部分。

由于向授权端点的请求会引起用于凭据的明文传输，因此授权服务器要求在向授权端点发送请求时必须使用TLS。

授权服务器对于授权端点必须支持使用HTTP
GET方法，可能会支持POST。

请求中无值参数和未识别参数必须被忽略。请求和响应参数不应该被包含超过一次。

1.1响应类型

授权端点用于授权码类型和隐式授权流程。客户端使用下列参数通知授权服务器期望的许可类型：

response_type

必须包含，值必须是code或者token或者注册扩展值

扩展响应类型可能包含空格分割的列表，这种复杂相应类型由他们自己定义。

如果一个授权请求没有response_type参数，或者不能理解相应类型，授权服务器必须返回error response

1.2重定向端点

完成与资源拥有者交互后，授权服务器引导资源拥有者的用户代理返回客户端。授权服务器重定向用户代理到在客户端注册时或者发出授权请求时预先建立的客户端重定向端点。

重定向端点URI必须是绝对URI。端点URI可能包含application/x-www-form-urlencoded格式的查询体，当添加额外查询参数时必须保留。端点URI一定不能包含fragment部分。

1.2.1端点请求的机密性

当响应类型是code或者token时或者重定向请求将导致敏感凭据通过开放网络传输时，重定向端点需要使用TLS。

缺乏传输层安全可能对客户端及它被授权访问的受保护资源的安全具有严重影响。当授权过程用作一种客户端委托的对最终用户认证（例如，第三方登录服务）的形式时，使用传输层安全尤其关键。

1.2.2注册要求

授权服务器必须要求下列客户端注册其重定向客户端“

公开客户端

使用隐式授权类型的机密客户端

授权服务器应该要求所有的客户端在使用授权端点前注册重定向端点

授权服务器应该要求客户端提供完整的重定向URI，如果不能注册完整重定向URI，那么应该要求注册URI scheme，authority和path。（请求授权时允许客户端动态变更查询部分）

授权服务器可能允许客户端注册多个重定向端点。

缺少重定向URI注册的要求，可能使攻击者将授权端点用作自由重定向端点。

1.2.3动态配置

如果注册多个重定向URI或者如果只有部分重定向URI被注册或者没有注册重定向URI。客户端都必须使用“redirect_uri”请求参数在授权请求中包含重定向URI。

当授权请求包含了一个重定向URI，授权服务器必须比较和匹配至少一个已注册URI。

1.2.4无效端点

如果由于缺失、无效或不匹配的重定向URI而验证失败，授权服务器应该通知资源所有者该错误且不能向无效的重定向URI自动重定向用户代理。

1.2.5端点内容

向客户端端点的重定向请求通常会引起由用户代理处理的HTML文档响应。如果HTML响应直接作为重定向请求的服务结果，任何包含在HTML文档中的脚本将执行，并具有对重定向URI和其包含的凭据的完全访问权限。

客户端不应该在重定向端点的响应中包含任何第三方的脚本（例如，第三方分析、社交插件、广告网络）。相反，它应该从URI中提取凭据并向另一个端点重定向用户代理而不暴露凭据（在URI中或其他地方）。如果包含第三方脚本，客户端必须确保它自己的脚本（用于从URI中提取凭据并从URI中删除）将首先执行。

2.token端点

token端点用于客户端通过展示授权许可或者可刷新token以获取访问token。token端点被用于除了隐式授权的其他所有方式。

这意味着客户端获取token端点的位置超出说明的范围，但是通常会在服务文档中提供。

端点URI可能包含application/x-www-form-urlencoded格式的查询请求部分，当添加额外查询参数时也必须保留。端点URI一定不能包含fragment部分。

由于对token端点的请求会导致明文凭据的传输，因此必须采用TLS。

客户端请求token时必须使用POST方法。

请求中无值参数和未识别参数必须被忽略。请求和响应参数不应该被包含超过一次。

2.1客户端认证

机密客户端或者其他被办法客户端凭据的客户端在请求token端点时必须与授权服务器进行验证。客户端验证用于：

执行刷新token以及授权码与客户端的绑定。当授权码在不安全通道上向重定向端点传输时，或者
当重定向URI没有被完全注册时，客户端身份验证是关键的。

通过禁用客户端或者改变其凭据恢复一个被盗用的客户端，因此组织了攻击者滥用被盗的刷新令牌。改变客户端凭据显然快于撤销所有的刷新令牌。

实现认证管理的最佳实践，要求定期凭证轮转。轮转一整套刷新令牌可能是艰巨的，而轮转单组客户端凭据显然更容易。

向token端点发送请求时，一个客户端可能使用client_id请求参数用来标志自身。向令牌端点的“authorization_code”和“grant_type”请求中，未经身份验证的客户端必须发送它的“client_id”，以防止自己无意中接受了本打算给具有另一个“client_id”的客户端的代码。这保护了客户端免于被替换认证码。

3.访问令牌范围
认证和令牌端点允许客户端通过scope请求参数指定访问请求的范围。反过来，认证服务器使用scope响应参数来通知客户端访问令牌被颁发的范围。

scope请求参数用空格分割，大小写敏感。该string由授权服务器定义。如果值包含了多个空格分割的字符串，他们的顺序并不重要，并且每个string为请求区域附加了一个额外的访问范围。
scope= scope-token *( SP scope-token )
scope-token = 1*( %x21 / %x23-5B / %x5D-7E )

授权服务器基于服务器策略或者资源拥有者的指令可能完全或部分的忽略客户端的scope请求。如果颁发的访问令牌范围与客户端的请求不同，服务器必须包含scope响应参数通知客户端实际的授权范围。

如果客户端在请求授权时忽略scope请求，授权服务器必须要么使用预定义的默认值或者使请求失败以指明无效范围。授权服务器应该在文档说明scope需求和默认值。