4. Obtaining Authorization

4. 获得授权

   为了请求访问令牌, 客户端从资源所有者获得授权. 该授权以授权许可 (authorization grant) 的形式表示, 客户端使用该授权许可请求访问令牌. OAuth 定义了四种许可类型: 授权码, 隐式, 资源所有者密码凭据和客户端凭据. OAuth 还提供了一种扩展机制, 用于定义额外许可类型.

4.1. 授权码许可

授权码许可类型用于获得访问令牌和刷新令牌, 并针对机密客户端进行了优化. 由于这是基于重定向的流程, 客户端必须能够与资源所有者的用户代理 (通常是 Web 浏览器) 交互, 并且能够接收来自授权服务器的传入请求 (通过重定向).

+----------+
| 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)

注意: 表示步骤 (A), (B) 和 (C) 的线条在经过用户代理时被分成两段.

                Figure 3: Authorization Code Flow

图 3 所示流程包括以下步骤:

(A) 客户端通过将资源所有者的用户代理定向到授权端点来启动流程. 客户端包含其客户端标识符, 请求的作用域, 本地状态, 以及一个重定向 URI, 授权服务器将在授予 (或拒绝) 访问后把用户代理送回该 URI.

(B) 授权服务器认证资源所有者 (通过用户代理), 并确定资源所有者是授予还是拒绝客户端的访问请求.

(C) 假设资源所有者授予访问, 授权服务器使用先前提供的重定向 URI (在请求中或客户端注册期间提供) 将用户代理重定向回客户端. 重定向 URI 包含授权码以及客户端先前提供的任何本地状态.

(D) 客户端通过在请求中包含上一步收到的授权码, 向授权服务器的令牌端点请求访问令牌. 发起请求时, 客户端向授权服务器认证. 客户端包含用于获得授权码的重定向 URI 以供验证.

(E) 授权服务器认证客户端, 验证授权码, 并确保接收到的重定向 URI 与步骤 (C) 中用于重定向客户端的 URI 匹配. 如果有效, 授权服务器返回访问令牌, 并且可以选择返回刷新令牌.

4.1.1. 授权请求

客户端按照 Appendix B 的 "application/x-www-form-urlencoded" 格式, 将以下参数添加到授权端点 URI 的查询组件中, 从而构造请求 URI:

response_type 必需. 值必须设置为 "code".

client_id 必需. 第 2.2 节所述的客户端标识符.

redirect_uri 可选. 如第 3.1.2 节所述.

scope 可选. 第 3.3 节所述的访问请求作用域.

state 推荐. 客户端用于在请求与回调之间维护状态的不透明值. 授权服务器在将用户代理重定向回客户端时会包含该值. 该参数应当用于防止第 10.12 节所述的跨站请求伪造.

客户端使用 HTTP 重定向响应, 或通过用户代理可用的其他方式, 将资源所有者定向到构造出的 URI.

例如, 客户端引导用户代理使用 TLS 发起以下 HTTP 请求 (为便于展示加入了额外换行):

    GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

授权服务器验证请求, 确保所有必需参数均存在且有效. 如果请求有效, 授权服务器认证资源所有者并获得授权决定 (通过询问资源所有者, 或通过其他方式建立批准).

一旦作出决定, 授权服务器使用 HTTP 重定向响应, 或通过用户代理可用的其他方式, 将用户代理定向到提供的客户端重定向 URI.

4.1.2. 授权响应

如果资源所有者授予访问请求, 授权服务器会签发授权码, 并按照 Appendix B 的 "application/x-www-form-urlencoded" 格式, 通过向重定向 URI 的查询组件添加以下参数将授权码交付给客户端:

code 必需. 授权服务器生成的授权码. 授权码必须在签发后很短时间内过期, 以降低泄漏风险. 推荐的最长授权码生命周期为 10 分钟. 客户端禁止多次使用授权码. 如果某个授权码被使用多次, 授权服务器必须拒绝该请求, 并且应当在可能时撤销所有先前基于该授权码签发的令牌. 授权码绑定到客户端标识符和重定向 URI.

state 如果客户端授权请求中存在 "state" 参数, 则为必需. 其值必须是从客户端接收到的精确值.

例如, 授权服务器通过发送以下 HTTP 响应来重定向用户代理:

     HTTP/1.1 302 Found
     Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
               &state=xyz

客户端必须忽略无法识别的响应参数. 本规范未定义授权码字符串大小. 客户端应避免对代码值大小作出假设. 授权服务器应当记录其签发的任何值的大小.

4.1.2.1. 错误响应

如果请求因缺少, 无效或不匹配的重定向 URI 而失败, 或客户端标识符缺失或无效, 授权服务器应当告知资源所有者该错误, 并且禁止自动将用户代理重定向到无效的重定向 URI.

如果资源所有者拒绝访问请求, 或请求由于缺少或无效重定向 URI 之外的原因失败, 授权服务器会按照 Appendix B 的 "application/x-www-form-urlencoded" 格式, 通过向重定向 URI 的查询组件添加以下参数来通知客户端:

error 必需. 下列单个 ASCII [USASCII] 错误代码:

     invalid_request
           请求缺少必需参数, 包含无效参数值, 某个参数出现多次, 或者格式有误.

     unauthorized_client
           客户端无权使用此方法请求授权码.

     access_denied
           资源所有者或授权服务器拒绝了该请求.

     unsupported_response_type
           授权服务器不支持使用此方法获得授权码.

     invalid_scope
           请求的作用域无效, 未知或格式有误.

     server_error
           授权服务器遇到意外情况, 无法完成请求. (需要此错误代码是因为无法通过 HTTP 重定向向客户端返回 500 Internal Server Error HTTP 状态码.)

     temporarily_unavailable
           授权服务器当前由于临时过载或服务器维护而无法处理请求. (需要此错误代码是因为无法通过 HTTP 重定向向客户端返回 503 Service Unavailable HTTP 状态码.)

     "error" 参数的值禁止包含集合 %x20-21 / %x23-5B / %x5D-7E 之外的字符.

error_description 可选. 人类可读的 ASCII [USASCII] 文本, 提供额外信息, 用于帮助客户端开发者理解发生的错误. "error_description" 参数的值禁止包含集合 %x20-21 / %x23-5B / %x5D-7E 之外的字符.

error_uri 可选. 一个 URI, 标识包含错误相关信息的人类可读网页, 用于向客户端开发者提供关于该错误的额外信息. "error_uri" 参数的值必须符合 URI-reference 语法, 因而禁止包含集合 %x21 / %x23-5B / %x5D-7E 之外的字符.

state 如果客户端授权请求中存在 "state" 参数, 则为必需. 其值必须是从客户端接收到的精确值.

例如, 授权服务器通过发送以下 HTTP 响应来重定向用户代理:

   HTTP/1.1 302 Found
   Location: https://client.example.com/cb?error=access_denied&state=xyz

4.1.3. 访问令牌请求

客户端按照 Appendix B 的 "application/x-www-form-urlencoded" 格式, 使用 UTF-8 字符编码在 HTTP 请求实体主体中发送以下参数, 从而向令牌端点发起请求:

grant_type 必需. 值必须设置为 "authorization_code".

code 必需. 从授权服务器收到的授权码.

redirect_uri 如果授权请求中包含第 4.1.1 节所述的 "redirect_uri" 参数, 则为必需, 并且两者的值必须完全相同.

client_id 如果客户端未按第 3.2.1 节所述向授权服务器认证, 则为必需.

如果客户端类型为机密客户端, 或客户端已获发客户端凭据 (或被分配了其他认证要求), 客户端必须按第 3.2.1 节所述向授权服务器认证.

例如, 客户端使用 TLS 发起以下 HTTP 请求 (为便于展示加入了额外换行):

     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
     &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

授权服务器必须:

o 对机密客户端或任何已获发客户端凭据的客户端 (或有其他认证要求的客户端) 要求客户端认证,

o 如果请求中包含客户端认证, 则认证客户端,

o 确保授权码签发给了已认证的机密客户端; 如果客户端是公共客户端, 则确保代码签发给了请求中的 "client_id",

o 验证授权码有效,

o 如果初始授权请求中包含第 4.1.1 节所述的 "redirect_uri" 参数, 则确保 "redirect_uri" 参数存在; 如果存在, 则确保其值完全相同.

4.1.4. 访问令牌响应

如果访问令牌请求有效且已获授权, 授权服务器按第 5.1 节所述签发访问令牌和可选的刷新令牌. 如果请求客户端认证失败或请求无效, 授权服务器按第 5.2 节所述返回错误响应.

成功响应示例:

     HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     \{
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
     \}

4.2. 隐式许可

隐式许可类型用于获得访问令牌 (不支持签发刷新令牌), 并针对已知会操作特定重定向 URI 的公共客户端进行了优化. 这些客户端通常使用 JavaScript 等脚本语言在浏览器中实现.

由于这是基于重定向的流程, 客户端必须能够与资源所有者的用户代理 (通常是 Web 浏览器) 交互, 并且能够接收来自授权服务器的传入请求 (通过重定向).

与授权码许可类型不同, 后者中客户端分别发起授权请求和访问令牌请求; 在隐式许可中, 客户端会作为授权请求的结果收到访问令牌.

隐式许可类型不包含客户端认证, 而是依赖资源所有者的存在以及重定向 URI 的注册. 由于访问令牌编码在重定向 URI 中, 它可能暴露给资源所有者以及同一设备上的其他应用程序.

+----------+
| Resource |
|  Owner   |
|          |
+----------+
     ^
     |
    (B)
+----|-----+          Client Identifier     +---------------+
|         -+----(A)-- & Redirection URI --->|               |
|  User-   |                                | Authorization |
|  Agent  -|----(B)-- User authenticates -->|     Server    |
|          |                                |               |
|          |<---(C)--- Redirection URI -----|               |
|          |          with Access Token     +---------------+
|          |            in Fragment
|          |                                +---------------+
|          |----(D)--- Redirection URI ---->|   Web-Hosted  |
|          |          without Fragment      |     Client    |
|          |                                |    Resource   |
|     (F)  |<---(E)------- Script ----------|               |
|          |                                +---------------+
+-|--------+
  |    |
 (A)  (G) Access Token
  |    |
  ^    v
+---------+
|         |
|  Client |
|         |
+---------+

注意: 表示步骤 (A) 和 (B) 的线条在经过用户代理时被分成两段.

                   Figure 4: Implicit Grant Flow

图 4 所示流程包括以下步骤:

(A) 客户端通过将资源所有者的用户代理定向到授权端点来启动流程. 客户端包含其客户端标识符, 请求的作用域, 本地状态, 以及一个重定向 URI, 授权服务器将在授予 (或拒绝) 访问后把用户代理送回该 URI.

(B) 授权服务器认证资源所有者 (通过用户代理), 并确定资源所有者是授予还是拒绝客户端的访问请求.

(C) 假设资源所有者授予访问, 授权服务器使用先前提供的重定向 URI 将用户代理重定向回客户端. 重定向 URI 在 URI 片段中包含访问令牌.

(D) 用户代理按照重定向指令向 Web 托管的客户端资源发起请求 (根据 [RFC2616], 该请求不包含片段). 用户代理在本地保留片段信息.

(E) Web 托管的客户端资源返回一个网页 (通常是包含嵌入式脚本的 HTML 文档), 该网页能够访问完整重定向 URI, 包括用户代理保留的片段, 并提取片段中包含的访问令牌 (以及其他参数).

(F) 用户代理在本地执行 Web 托管客户端资源提供的脚本, 该脚本提取访问令牌.

(G) 用户代理将访问令牌传递给客户端.

有关使用隐式许可的背景, 参见第 1.3.2 节和第 9 节. 有关使用隐式许可时的重要安全考虑, 参见第 10.3 节和第 10.16 节.

4.2.1. 授权请求

客户端按照 Appendix B 的 "application/x-www-form-urlencoded" 格式, 将以下参数添加到授权端点 URI 的查询组件中, 从而构造请求 URI:

response_type 必需. 值必须设置为 "token".

client_id 必需. 第 2.2 节所述的客户端标识符.

redirect_uri 可选. 如第 3.1.2 节所述.

scope 可选. 第 3.3 节所述的访问请求作用域.

state 推荐. 客户端用于在请求与回调之间维护状态的不透明值. 授权服务器在将用户代理重定向回客户端时会包含该值. 该参数应当用于防止第 10.12 节所述的跨站请求伪造.

客户端使用 HTTP 重定向响应, 或通过用户代理可用的其他方式, 将资源所有者定向到构造出的 URI.

例如, 客户端引导用户代理使用 TLS 发起以下 HTTP 请求 (为便于展示加入了额外换行):

    GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

授权服务器验证请求, 确保所有必需参数均存在且有效. 授权服务器必须验证其将重定向访问令牌到达的重定向 URI 与客户端按第 3.1.2 节注册的重定向 URI 相匹配.

如果请求有效, 授权服务器认证资源所有者并获得授权决定 (通过询问资源所有者, 或通过其他方式建立批准).

一旦作出决定, 授权服务器使用 HTTP 重定向响应, 或通过用户代理可用的其他方式, 将用户代理定向到提供的客户端重定向 URI.

4.2.2. 访问令牌响应

如果资源所有者授予访问请求, 授权服务器会签发访问令牌, 并按照 Appendix B 的 "application/x-www-form-urlencoded" 格式, 通过向重定向 URI 的片段组件添加以下参数将访问令牌交付给客户端:

access_token 必需. 授权服务器签发的访问令牌.

token_type 必需. 第 7.1 节所述的已签发令牌类型. 值不区分大小写.

expires_in 推荐. 访问令牌的生命周期, 以秒为单位. 例如, 值 "3600" 表示访问令牌将在响应生成后一小时过期. 如果省略, 授权服务器应当通过其他方式提供过期时间或记录默认值.

scope 如果与客户端请求的作用域相同, 则为可选; 否则为必需. 第 3.3 节所述的访问令牌作用域.

state 如果客户端授权请求中存在 "state" 参数, 则为必需. 其值必须是从客户端接收到的精确值.

授权服务器禁止签发刷新令牌.

例如, 授权服务器通过发送以下 HTTP 响应来重定向用户代理 (为便于展示加入了额外换行):

     HTTP/1.1 302 Found
     Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
               &state=xyz&token_type=example&expires_in=3600

开发者应注意, 某些用户代理不支持在 HTTP "Location" 响应头字段中包含片段组件. 这类客户端将需要使用 3xx 重定向响应以外的方法来重定向客户端, 例如返回一个 HTML 页面, 其中包含一个操作链接到重定向 URI 的 "continue" 按钮.

客户端必须忽略无法识别的响应参数. 本规范未定义访问令牌字符串大小. 客户端应避免对值大小作出假设. 授权服务器应当记录其签发的任何值的大小.

4.2.2.1. 错误响应

如果请求因缺少, 无效或不匹配的重定向 URI 而失败, 或客户端标识符缺失或无效, 授权服务器应当告知资源所有者该错误, 并且禁止自动将用户代理重定向到无效的重定向 URI.

如果资源所有者拒绝访问请求, 或请求由于缺少或无效重定向 URI 之外的原因失败, 授权服务器会按照 Appendix B 的 "application/x-www-form-urlencoded" 格式, 通过向重定向 URI 的片段组件添加以下参数来通知客户端:

error 必需. 下列单个 ASCII [USASCII] 错误代码:

     invalid_request
           请求缺少必需参数, 包含无效参数值, 某个参数出现多次, 或者格式有误.

     unauthorized_client
           客户端无权使用此方法请求访问令牌.

     access_denied
           资源所有者或授权服务器拒绝了该请求.

     unsupported_response_type
           授权服务器不支持使用此方法获得访问令牌.

     invalid_scope
           请求的作用域无效, 未知或格式有误.

     server_error
           授权服务器遇到意外情况, 无法完成请求. (需要此错误代码是因为无法通过 HTTP 重定向向客户端返回 500 Internal Server Error HTTP 状态码.)

     temporarily_unavailable
           授权服务器当前由于临时过载或服务器维护而无法处理请求. (需要此错误代码是因为无法通过 HTTP 重定向向客户端返回 503 Service Unavailable HTTP 状态码.)

     "error" 参数的值禁止包含集合 %x20-21 / %x23-5B / %x5D-7E 之外的字符.

error_description 可选. 人类可读的 ASCII [USASCII] 文本, 提供额外信息, 用于帮助客户端开发者理解发生的错误. "error_description" 参数的值禁止包含集合 %x20-21 / %x23-5B / %x5D-7E 之外的字符.

error_uri 可选. 一个 URI, 标识包含错误相关信息的人类可读网页, 用于向客户端开发者提供关于该错误的额外信息. "error_uri" 参数的值必须符合 URI-reference 语法, 因而禁止包含集合 %x21 / %x23-5B / %x5D-7E 之外的字符.

state 如果客户端授权请求中存在 "state" 参数, 则为必需. 其值必须是从客户端接收到的精确值.

例如, 授权服务器通过发送以下 HTTP 响应来重定向用户代理:

   HTTP/1.1 302 Found
   Location: https://client.example.com/cb#error=access_denied&state=xyz

4.3. 资源所有者密码凭据许可

资源所有者密码凭据许可类型适用于资源所有者与客户端之间存在信任关系的场景, 例如设备操作系统或高权限应用程序. 授权服务器在启用这种许可类型时应格外谨慎, 并且只应在其他流程不可行时允许使用.

这种许可类型适用于能够获得资源所有者凭据 (用户名和密码, 通常通过交互式表单) 的客户端. 它也用于将使用直接认证方案 (例如 HTTP Basic 或 Digest 认证) 的现有客户端迁移到 OAuth, 方法是将已保存的凭据转换为访问令牌.

+----------+
| Resource |
|  Owner   |
|          |
+----------+
     v
     |    Resource Owner
    (A) Password Credentials
     |
     v
+---------+                                  +---------------+
|         |>--(B)---- Resource Owner ------->|               |
|         |         Password Credentials     | Authorization |
| Client  |                                  |     Server    |
|         |<--(C)---- Access Token ----------|               |
|         |    (w/ Optional Refresh Token)   |               |
+---------+                                  +---------------+

        Figure 5: Resource Owner Password Credentials Flow

图 5 所示流程包括以下步骤:

(A) 资源所有者向客户端提供其用户名和密码.

(B) 客户端通过在请求中包含从资源所有者收到的凭据, 向授权服务器的令牌端点请求访问令牌. 发起请求时, 客户端向授权服务器认证.

(C) 授权服务器认证客户端并验证资源所有者凭据, 如果有效, 则签发访问令牌.

4.3.1. 授权请求和响应

客户端获得资源所有者凭据的方法不在本规范范围内. 客户端在获得访问令牌后必须丢弃这些凭据.

4.3.2. 访问令牌请求

客户端按照 Appendix B 的 "application/x-www-form-urlencoded" 格式, 使用 UTF-8 字符编码在 HTTP 请求实体主体中添加以下参数, 从而向令牌端点发起请求:

grant_type 必需. 值必须设置为 "password".

username 必需. 资源所有者用户名.

password 必需. 资源所有者密码.

scope 可选. 第 3.3 节所述的访问请求作用域.

如果客户端类型为机密客户端, 或客户端已获发客户端凭据 (或被分配了其他认证要求), 客户端必须按第 3.2.1 节所述向授权服务器认证.

例如, 客户端使用传输层安全发起以下 HTTP 请求 (为便于展示加入了额外换行):

     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=password&username=johndoe&password=A3ddj3w

授权服务器必须:

o 对机密客户端或任何已获发客户端凭据的客户端 (或有其他认证要求的客户端) 要求客户端认证,

o 如果请求中包含客户端认证, 则认证客户端,

o 使用其现有密码验证算法验证资源所有者密码凭据.

由于此访问令牌请求使用资源所有者的密码, 授权服务器必须保护该端点免受暴力破解攻击 (例如使用速率限制或生成告警).

4.3.3. 访问令牌响应

如果访问令牌请求有效且已获授权, 授权服务器按第 5.1 节所述签发访问令牌和可选的刷新令牌. 如果请求客户端认证失败或请求无效, 授权服务器按第 5.2 节所述返回错误响应.

成功响应示例:

     HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     \{
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
     \}

4.4. 客户端凭据许可

当客户端请求访问其控制下的受保护资源, 或请求访问另一个资源所有者且已事先与授权服务器约定的受保护资源 (约定方法不在本规范范围内) 时, 客户端可以仅使用其客户端凭据 (或其他受支持的认证方式) 请求访问令牌.

客户端凭据许可类型只能由机密客户端使用.

+---------+                                  +---------------+
|         |                                  |               |
|         |>--(A)- Client Authentication --->| Authorization |
| Client  |                                  |     Server    |
|         |<--(B)---- Access Token ----------|               |
|         |                                  |               |
+---------+                                  +---------------+

                 Figure 6: Client Credentials Flow

图 6 所示流程包括以下步骤:

(A) 客户端向授权服务器认证, 并从令牌端点请求访问令牌.

(B) 授权服务器认证客户端, 如果有效, 则签发访问令牌.

4.4.1. 授权请求和响应

由于客户端认证被用作授权许可, 因此不需要额外的授权请求.

4.4.2. 访问令牌请求

客户端按照 Appendix B 的 "application/x-www-form-urlencoded" 格式, 使用 UTF-8 字符编码在 HTTP 请求实体主体中添加以下参数, 从而向令牌端点发起请求:

grant_type 必需. 值必须设置为 "client_credentials".

scope 可选. 第 3.3 节所述的访问请求作用域.

客户端必须按第 3.2.1 节所述向授权服务器认证.

例如, 客户端使用传输层安全发起以下 HTTP 请求 (为便于展示加入了额外换行):

     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=client_credentials

授权服务器必须认证客户端.

4.4.3. 访问令牌响应

如果访问令牌请求有效且已获授权, 授权服务器按第 5.1 节所述签发访问令牌. 不应包含刷新令牌. 如果请求客户端认证失败或请求无效, 授权服务器按第 5.2 节所述返回错误响应.

成功响应示例:

     HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     \{
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "example_parameter":"example_value"
     \}

4.5. 扩展许可

客户端通过将一个绝对 URI (由授权服务器定义) 指定为令牌端点 "grant_type" 参数的值, 并添加任何必要的额外参数, 来使用扩展许可类型.

例如, 为了使用 [OAuth-SAML2] 定义的安全断言标记语言 (Security Assertion Markup Language, SAML) 2.0 断言许可类型请求访问令牌, 客户端可以使用 TLS 发起以下 HTTP 请求 (为便于展示加入了额外换行):

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded

     grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-
     bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU
     [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-

如果访问令牌请求有效且已获授权, 授权服务器按第 5.1 节所述签发访问令牌和可选的刷新令牌. 如果请求客户端认证失败或请求无效, 授权服务器按第 5.2 节所述返回错误响应.