如何使用widget获取AccessToken？

范围（选修）

您的服务可以支持分配客户端凭据的不同范围。事实上，真正支持这一点的服务并不多。

客户端身份验证（必需）

客户端必须对此请求进行身份验证。通常，服务将允许附加请求参数 client_id 和 client_secret 或接受 HTTP 基本身份验证标头中的客户端 ID 和密码。

示例

以下是服务收到的授权代码的示例。

POST /token HTTP/1.1
Host: authorization-server.com

grant_type=client_credentials
&client_id=xxxxxxxxxx
&client_secret=xxxxxxxxxx

access-token-response 访问令牌

成功响应

如果访问令牌请求有效，则身份验证服务器必须生成访问令牌（以及可选的刷新令牌）并将其返回给客户端，通常与以及一些有关授权的附加属性。

带有访问令牌的响应必须包含以下属性：

• access_token（必需）授权服务器颁发的访问令牌字符串。
• token_type（必需）这是令牌的类型，通常只是字符串“Bearer”。
• expires_in（推荐）如果访问令牌过期，服务器应使用分配的访问令牌的持续时间进行响应。
• refresh_token（可选）如果访问令牌即将过期，则返回刷新令牌非常有用，应用程序可以使用该刷新令牌来获取另一个访问令牌。但是，对于使用隐式授权颁发的令牌，无法颁发刷新令牌。
• scope（可选）如果用户分配的范围与应用程序请求的范围相同，则此参数是可选的。如果分配的范围与请求的范围不同，例如，如果用户更改了范围，则需要此参数。

当使用访问令牌进行响应时，服务器还必须包含额外的 Cache-Control: no-storeHTTP 标头，以确保客户端不会缓存此请求。

例如，成功的令牌响应可能如下所示：

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "access_token":"MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3",
  "token_type":"Bearer",
  "expires_in":3600,
  "refresh_token":"IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk",
  "scope":"create"
}

访问令牌

OAuth 2.0 承载令牌的格式实际上在单独的规范 RFC 6750 中进行了描述。规格。定义的结构，以便您可以生成字符串并根据需要部署令牌。不记名令牌中的有效字符是字母数字和以下标点符号：

不记名令牌的一个简单实现是生成随机字符串并将其与关联的用户和范围信息一起存储在数据库中，或者更高级的系统可以使用自编码令牌，其中令牌字符串本身包含所有必要的信息。

失败的响应

如果访问令牌请求无效，例如重定向 URL 与身份验证期间使用的 URL 不匹配，服务器必须返回错误响应。

错误响应返回 HTTP 400 状态代码（除非另有指定），参数为 error 和 error_description。参数error将始终是以下值之一。

• invalid_request – 请求缺少参数，因此服务器无法继续处理该请求。如果请求包含不支持的参数或重复的参数，也可能返回此信息。
• invalid_client – 客户端身份验证失败，例如，请求包含无效的客户端 ID 或密码。在这种情况下，将发送 HTTP 401 响应。
• invalid_grant – 授权代码（或密码授予类型的用户密码）无效或已过期。如果授权授予中指定的重定向 URL 与此访问令牌请求中指定的 URL 不匹配，这也是您将返回的错误。
• invalid_scope – 对于包含范围（密码或 client_credentials 授予）的访问令牌请求，此错误表示请求中的范围值无效。
• unauthorized_client – 该客户端无权使用所请求的授权类型。如果你例如限制哪些应用程序可以使用隐式身份验证，如果您为其他应用程序返回此错误。
• unsupported_grant_type – 如果您请求授权服务器无法识别的授权类型，请使用此代码。请注意，未知的授权类型也使用此特定错误代码，而不是使用上面的 invalid_request 代码。

返回带有两个可选参数的错误响应：error_description 和 error_uri。这些旨在向开发人员提供有关错误的更多信息，而不是向最终用户展示提供信息。但是，请记住，无论您如何警告许多开发人员，许多开发人员都会将此错误文本直接传递给最终用户，因此最好确保它至少对最终用户也有一定帮助。

参数error_description 只能是 ASCII 字符，最多只能是一到两句话描述错误情况。这个 error_uri 是链接到 API 文档的好地方，以获取有关如何修复遇到的特定错误的信息。

整个错误响应以 JSON 字符串形式返回，与成功响应类似。以下是错误响应的示例。

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store

{
  "error": "invalid_request",
  "error_description": "Request was missing the 'redirect_uri' parameter.",
  "error_uri": "See the full API docs at https://authorization-server.com/docs/access_token"
}