这是我参与8月更文挑战的第5天，活动详情查看：8月更文挑战

密码式授权

密码式授权适合于用户与客户端具有信任关系的情况。

这种模式适合于能将获取用户(用户名和密码，通常使用的交互形式)的客户端。通过转换已存储的凭据至访问令牌，也用于迁移现存的使用HTTP基本或直接身份验证方案的客户端。

流程

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

（A）用户向客户端提供用户名和密码。

客户端一旦获取访问令牌，客户端必须丢弃用户名和密码。

（B）客户端将用户名和密码发给认证服务器，向后者请求令牌。当发起请求时，客户端与授权服务器进行身份验证。

参数说明：

参数	参数说明	是否必填	备注
grant_type	授权类型	必填	此处的值必须为password
username	用户名	必填
password	密码	必填
scope	申请的权限范围	可选项

客户端使用传输层安全发起如下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

授权服务器必须：

• 要求对的客户端进行身份验证，
• 若包括了客户端身份验证，验证客户端身份，并使用它现有的密码验证算法验证资源所有者的密码凭据。

（C）授权服务器对客户端身份验证，验证用户身份。如果有效，向客户端提供访问令牌。

如果访问令牌请求是有效的且被授权，授权服务器颁发访问令牌以及可选的刷新令牌。如果请求客户端身份验证失败或无效，授权服务器返回错误响应。

成功响应示例：

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"
}

使用场景

• 这种模式适用于用户对应用程序高度信任的情况。比如是用户操作系统的一部分。
• 认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。

注意

由于这种访问令牌请求使用了资源所有者的密码，授权服务器必须保护端点防止暴力攻击（例如，使用速率限制或生成警报）。