有心栽花花不开，无心插柳柳成荫。本期图文咱们看一看表面上很鸡肋，曾经也非常鸡肋，后来应用非常广泛的一种授权模式：密码授权模式。密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。 在这种模式中，用户必须把自己的密码给客户端。

这个模式肯定就不适合小美使用了，因为她要把自己“图片仓库”的账号和密码提供给“美图羞羞”，这么弱智的事情用户肯定不会去做，我们不主动泄露自己的个人信息天天都能接到无数的垃圾短信和骚扰电话，更别说上赶子把自己的账号密码给别人了，哪怕再信任也不行，我们被公司或个人出卖个人信息出卖的还少吗？密码模式既然不适合这种场景，那它的使用场景是什么呢？如果要提供账号密码的话，我们通常都会提供给谁呢？这个使用场景似乎很熟悉对不对？是的，我们已经很接近答案了：“自家的客户端调用自家的服务器的 API 请求自家服务器中资源”。我们手机里的应用，前后端分离的单页应用都可以采取这种授权模式。本来密码模式设计之处是为了兼容那个让人想吐的 “OAuth 1.0” ，没想到最后却在移动互联网时代老树发新芽，重新绽放了青春。

密码模式的授权步骤如下：

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

（B）客户端将用户名和密码发给认证服务器，向后者请求令牌。

（C）认证服务器确认无误后，向客户端提供访问令牌。

这是大家熟知的流程，也是大家都操作过的流程，这个模式也最容易理解，授权的过程也最简单，所以简单的事情咱们简单处理，不浪费过多口舌。简单了解一下相关参数即可：

B 步骤中，客户端发出的HTTP请求，包含以下参数：

• grant_type：表示授权类型，此处的值固定为 "password"，必选项。
• username：表示用户名，必选项。
• password：表示用户的密码，必选项。
• scope：表示权限范围，可选项。

C 步骤中，认证服务器向客户端发送访问令牌：

这个返回结果大家应该是非常熟悉了，跟之前授权码那部分的内容一样，不再赘述。密码模式中有一条重要的规则就是所有流程中不得保存用户的用户名和密码，但是呢，这只是一种幻想性的建议而已。OK，这么模式就这么简单的结束吧，后续我也会在视频中演示如何使用这种模式开发我们的 API 并且为 API 授权的。