The OAuth 2.0 Authorization Protocol （第三章）

3    协议的端点

   授权过程中利用两个端点（HTTP资源）：

   Ø授权端点 - 用于向通过用户代理重定向的资源所有者获取授权。
   Ø令牌终点 - 用来交换权限授予访问令牌，通常随着客户端身份验证。

   并非每个授权授予类型采用两个端点。如有需要，扩展授予类型可以定义额外的端点。

3.1    授权端点

授权端点用来与资源所有者交互,获得权限的授予。授权服务器必须首先验证资源的所有者的身份。方式授权服务器验证资源所有者（如用户名和密码登录，会话cookies）超出范围本规范。

客户端透过何种途径获得授权端点的位置超出本规范的范围， 但位置通常在服务文档里被提供。

端点URI可能包括一个“application/x-www-form-urlencoded”格式化的查询组件，加入额外的查询参数时，必须保留。端点URI不能包含片段组件。

由于请求授权端点导致用户身份验证和明文凭据（HTTP响应）的传输，授权服务器必须要求在授权端点发送请求时使用的传输层安全机制。授权服务器必须支持TLS 1.0,应该支持TLS 1.2和它的以后的版本，可以支持额外的传输层机制以满足它的安全性需要。

授权服务器必须支持对授权断点的HTTP “GET” 方法的使用，也可以支持“POST”方法的使用。

没有赋值的参数必须当做它们是从请求中被忽略的。授权服务器必须忽视无法识别的请求参数。请求和回应参数必须不能被包含超过一次。

3.1.1   响应类型

    是被授权码授权类型和隐式授权类型流使用的。客户端通知需要授权类型的授权端点使用以下参数。

response_type

        REQUIRED.  它的值必须是请求授权码中一个码就像4.1.1结所描述，令牌就如4.2.1结描述的请求一个访问令牌（隐式授予），或者一个如8.4结描述的注册扩展值。如果响应类型包括一个或者更多空格字符（%x20）, 它被解释为一个空格分隔列表值，值的顺序没有关系（例如“a b”跟“b a”是一样的）

        如果一个授权响应丢失了“response_type”参数，授权服务器必须返回一个错误回复，就如4.1.2.1结所述。

3.1.2    重定向向端点

与资源的所有者完成互动后，授权服务器指示资源所有者的用户代理返回客户端。授权服务器重定向用户代理到客户端的重定向终点，重定向终点是先前客户端注册进程或者发出授权请求时由授权服务器建立的。
      重定向端点URI必须是一个绝对的URI，如4.3所述。终点 URI可能包含an

"application/x-www-form-urlencoded"格式化查询组件，加入额外的查询参数时，必须保留。端点URI不能包含片段组件。

3.1.2.1     端点要求保密
如果一个重定向请求将导致授权码的传输或者访问令牌通过一个开放网络

（在资源所有者的用户代理和客户端之间），客户端应需要使用传输层安全机

制。

     传输层安全性的缺乏可能对客户端的安全和受保护资源授权访问造成严重

影响。当客户端将授权过程当做一种委派最终用户身份验证时，传输层安全机制

的使用变得尤为关键。

3.1.2.2    注册要求

授权服务器应要求所有client用授权终端登记他们先前的重定向URI，并且

必须要求以下的client登记他们的重定向URI：

a)      public clients

b)      安全的clients 使用隐式的授权类型

授权服务器应要求客户端提供完整的重定向URI（客户端可以使用“state”的

请求参数来实现每个请求定制）。授权服务器允许客户端注册多个重定向URI. 如果要求完成重定向的URI注册登记是不可能的，授权服务器应要求URI方案，权限和路径（请求授权时，许客户端动态改变注册重定向URI的查询组件）的注册。

3.1.2.3    动态配置
如果已注册多个重定向的URI，如果只有部分 重定向URI已被注册，或如

果没有重定向URI已注册，客户端必须包括重定向URI，在授权请求时使用

“redirect_uri”请求参数。

     当一个重定向URI 被包含在授权请求中时，授权服务器必须比较和匹配最

少一个接受到的已注册的重定向URI（或者URI组件）就如第6章定义的，如果

任何重定向URI被注册了，授权服务器必须使用简单的字符串比较对比两个URI，

就如6.2.1结所述。

    如果授权服务器准许client动态的改变重定向URI的查询组件，client 必须

确保操作查询组件时不被攻击者滥用重定向终点，就如10.15结所述。

3.1.2.4    无效端点

如果授权请求验证失败是由于丢失，无效，或者重定向URI不匹配，授权服务器必须通知资源所有者错误信息，必须不能自动重定向用户代理到无效的重定向URI。

授权服务器不应该重定向用户代理到未注册或者不信任的URI ，以防止授权终端被公开的重定向者利用。

3.1.2.4    端点内容

到客户端点的重定向请求通常结果是一个HTML的文档响应，被用户代理所有。如果HTML响应被直接服务为重定向响应的结果，任何脚本包括HTML文档会带着全部重定向URI访问和它自带的凭证执行。

Client 必须不能包含任何不受信任第三方脚本在重定向端点响应中（比如 第三方分析器，社区插件，网络服务），第三方脚本没有第一次保证 它自己被用来提取和删除在URI的凭证的脚本将首次执行。

Client 不应该包含任何第三方脚本在重定向端点响应中。相反的，它应该从URI和重定向用户代理中提取凭证，并在没有凭证的URI里重定向用户代理到另外的端点。

3.2   令牌端点

令牌端点被client用来接受一个介绍他权限授予或者刷新令牌的访问令牌。令牌端点被每一个权限授予使用，除了隐式授予类型（应为访问令牌被直接分发）。

客户端透过何种途径获得令牌的位置 端点超出本规范的范围，但通常在服务文档里提供。

没有赋值的参数必须当做它们是从请求中被忽略的。授权服务器必须忽视无法识别的请求参数。请求和回应参数必须不能被包含超过一次。

3.2.1   客户端身份验证

保密的客户，分发客户凭证的客户，或者交办其它授权请求的客户必须被授权服务器验证身份在产生对令牌端点的请求时，就如2.3所述。客户端身份验证被用来：

(a) 执行客户端分发的刷新令牌和授权码到客户端的绑定。当一个授权码通过不安全的通道或者当重定向URI还没有被全部注册时，授权码传送到重定向端点的关键是客户端验证。

(b) 通过禁用客户端或改变其凭据来从受影响的客户端恢复，从而防止攻击者滥用被盗刷新令牌。改变一个单一的客户端凭据集合显然比撤销整套刷新令牌的更快。

(c) 实施认证管理的最佳做法，需要定期凭据轮换。整套刷新令牌的轮换可能是具有挑战性，而一个单一的客户端凭据的轮换显然比较容易。

在给令牌端点传送请求时，一个没有被分发客户密码的公共客户可能使用

“client_id”请求参数来认证它自己。

准许公共客户到令牌端点的未认证访问的安全后果，如同到公共客户的不安全的刷新令牌必须被考虑。

3.3   Access Token Scope

身份认真和令牌端点准许客户使用“scope”请求参数指定访问请求的范围。反过来，授权服务器使用的“范围”的响应参数通知客户端发出的访问令牌的范围。

范围参数值表示为空间分隔，大小写敏感的字符串列表。这个字符串被授权服务器定义。如果值包含过个空间分隔字符串，他们的顺序没关系，每个字符增加一个额外的访问边界给请求边界。

授权服务器可能全部或者部分忽视客户端请求的边界，该客户请求时根据授权服务器政策或资源所有者的指。如果分发访问令牌边界与客户端请求的不同，授权服务器应该包括“scope”响应参数去通知客户端实际被授予的边界。