传送门

Oauth2系列1：初识Oauth2

Oauth2系列2：授权码模式

Oauth2系列3：接入前准备

在前面几节，对oauth2有了一个初步概念。这里重点讨论下密码模式

一点感想

今天看了下这几年写的文章（勉强称其为"文章"哈），发现从访问量看，访问比较多的都是一些基础文章，比如UML入门系列，mysql系列，及java的一些相关，比如字符串replace处理等。

从中觉得，其实程序员做技术的，经验到底重要不重要？其实应该是很重要的，所以面试的时候，对相关行业，业务的经验都有考察及做为加分项，比如拼夕夕前几年都是double挖某宝的人。但是呢，具体到某一项技术或者应用场景，了解的人就比较少了，但是这种反而是快速上手或者解决问题的关键：不盲目追求大而全，深入也很重要

要积累相关行业的经验，包括解决方案！

什么是密码模式

在前面介绍过密码模式，它是oauth2的4种标准协议之一

密码式（password）

如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）。

这里要注意几点：

• 密码式的目的，最终还是获取授权的令牌。后续所以的操作还是基于令牌来交互
• 密码式的应用主体，一般是应用，而不指某个用户。

举一个例子来说明一下，比如，有很多开放平台，或者APP应用商城。现在有一个系统A要来调用开放平台的API接口，因为在这个过程中，没有用户的参与（不需要用户授权），而且这个系统A恰好也是开放平台同一个公司甚至本身就是开放平台开发的，那么这种系统间的调用，其实只需要识别系统A的身份就行了，直接在调用时候验证一下系统A的账密就可以颁布停牌给到它，而不用授权码模式这么复杂的操作了。可以通过引用一个图来理解一下（图片来源）

通过这个图可以发现，第三方软件"小兔"拿到用户的账密，直接从授权服务获取了停牌token，再也没有授权码模式的来来回回重定向，流程也简化了很多，对业务系统来说理方便了

由此，就解释了上面提到的2点：

• 密码式的目的，最终还是获取授权的令牌：如果每次小兔都是拿着小明的用户名和密码来通过调用 Web API 的方式，来访问小明店铺的订单数据，甚至还有商品信息等，在调用这么多 API 的情况下，无疑增加了用户名和密码等敏感信息的攻击面。如果是使用了 token 来代替这些“满天飞”的敏感信息，不就能很大程度上保护敏感信息数据了吗？这样，小兔软件只需要使用一次用户名和密码数据来换回一个 token，进而通过 token 来访问小明店铺的数据，以后就不会再使用用户名和密码了。
• 密码式的应用主体，一般是应用，而不指某个用户：小兔此时就是京东官方出品的一款软件，小明也是京东的用户，那么小明其实是可以使用用户名和密码来直接使用小兔这款软件的。原因很简单，那就是这里不再有“第三方”的概念了。

密码模式流程

密码模式的流程其实就是上面的时序图中的流程，整个流程可以归纳为一种步骤：第三方系统通过账密获取令牌。那么对于系统接口设计来说，是不是一个API接口就可以满足呢？

其实是可以的，比如可以如下定义接口：

URL：http://oauth.x.com/token

请求方式：POST

请求参数：

字段	说明
grantType	password，固定值，表示密码模式
userName	用户名
password	用户密码
clientId	客户端 ID（client ID）
clientSecret	客户端密钥（client secret）

返回参数：

{ 
"access_token":"ACCESS_TOKEN", 
"expires_in":7200, 
"refresh_token":"REFRESH_TOKEN",
"scope":"SCOPE"
}

• 这个接口一般是从后端发起POST请求
• 出于安全，一般需要设置成HTTPS协议