前言
接着IdentityServer4的授权模式继续聊，这篇来说说 Resource Owner Password Credentials授权模式，这种模式在实际应用场景中使用的并不多，只怪其太开放啦，直接在客户端上拿着用户名和密码就去授权服务器获取AccessToken，这样容易被客户端拿着用户名和密码搞坏事；接下来就详细说说。
正文
Resource Owner Password Credentials授权模式与上一节说到的客户端凭据模式不同，这是有用户参与的，用户就是资源拥有者；通过允许在客户端使用用户名和密码的方式向授权服务器获取AccessToken，AccessToken和用户相关，即不同的用户获取到的AccessToken不一样。
术语解释：
- Resource Owner：资源所有者，即拥有资源的用户； 绝大对数小伙伴都应该有自己的QQ，如果没特殊情况，相信每一个小伙伴的QQ空间中都有自己曾经觉得很酷或很有纪念意义的照片，这里的照片就是资源，而小伙伴就是资源所有者。 QQ服务器就是资源服务器。
Resource Owner Password Credentials 流程
流程简要说明：
- 首先用户和客户端需要提前在授权服务器上备案过的，用户没有备案，在资源服务器肯定就没有对应的资源，客户端没有备案就不能随意去授权服务器获取AccessToken；
- 用户在客户端上输入用户名和密码，并带上备案过的客户端凭据一起请求授权服务器获取AccessToken;
- 授权服务器验证用户凭据和客户端凭据，成功之后直接返回代表该用户的AccessToken；
- 用户在操作时，带上AccessToken访问资源服务器；
- 资源服务器正常返回结果，如果没有AccessToken是不能访问受保护资源的；
结合流程，看看代码如何实现，步伐跟上哦；
这里资源服务器和授权服务器就拷贝之前客户端模式的代码(这样每种模式的代码区分开，方便查看)，在原有基础上修改代码即可；
代码地址：https://github.com/zyq025/IDS4Demo
>>在原有的授权服务器上增加代码
-
模拟在授权服务器中备案用户，方便测试效果，就在内存中模拟；
image-20210106132546239 -
备案新的客户端，指定其授权方式；
image-20210106133339652 -
好啦，到这授权服务器的修改就完成啦，用postman先测试一下；
image-20210106135112325
>>授权服务器修改完啦，资源服务器不用动，那就到客户端啦
-
新建一个Winform窗体程序，简单布局安排上；并引入IdentityModel包；
image-20210106142213334 -
编写获取AccessToken逻辑，在GetAccessToken按钮点击事件中增加代码，如下：
image-20210106150232248 -
先启动授权服务器，看看access_token运行效果，如下：
image-20210106150619514 -
获取到AccessToken之后就可以访问受保护的API啦，在调用API按钮点击事件中进行逻辑编写，如下：
image-20210106151317975 -
授权服务器、资源服务器、客户端启动运行看效果，如下：
image-20210106151654463
以上就是Resource Owner Password Credentials的使用，流程是不是很简单。接下来聊聊这种模式的其他话题；
Resource Owner Password Credentials的尴尬之处
在oauth2.0中如果使用这种模式，规定是不允许客户端存储资源所有者的用户名和密码的，但如果是第三方客户端想搞事情，就把用户信息先存一把，这样就导致间接泄露用户信息的风险很高(如果第三方客户端被攻击了)，这也是这种模式在实际应用场景使用比较少的原因，如果有其他模式选择，不建议使用此模式；
通常以下情况，可以考虑使用：
- 客户端是可高度信任的，且安全性要有保障；
- 遗留应用，没有其他好的解决方案，可以使用；
有用户参与获取的accessToken和客户端凭据获取到的有什么区别
之前客户端凭据模式的截图：
资源所有者密码模式的截图：
小伙伴肯定看出来不止多一个，但其中比较重要的就是sub这个claim，如果sub存在，调用API的access_token就能区分是代表用户的，否则就是代表客户端的。即有用户参与获取的acess_token是代表用户的，每个用户的token都不一样。
refresh_token得补上
refresh_token是为了给access_token进行延长有效期而存在的，为了安全和降低风险，access_token的有效期一般设置的比较短，通常会是两个小时(根据需要设置)，当access_token失效时，常规的做法就是让其跳转到登录页重新登录获取，这样频繁的跳转到登录页，用户体验及其不好，为避免这种情况，需对access_token进行在线续命，即延长有效期；实现的方案各种各样，比如有在前端定时检测的，也有在后端做有效判断的，但用的相对比较多还是使用refresh_token的形式，当access_token失效时，会采用refresh_token去请求新的access_token，保证用户正常操作。
如果需要在获取access_token的时候同时返回refresh_token，需要在授权服务器上备案客户端时将AllowOfflineAccess设置为true，如下所示：
refresh_token具体使用，在后续的案例单独说吧。
总结
关于Resource Owner Password Credentials 就简单说这么多，主要是看看如何使用，相信小伙伴在新的项目中应该会很少用到，毕竟拿着用户名和密码直接在第三方客户端搞事情，始终还是有风险；下一篇说说Implicit(简化模式)。
一个被程序搞丑的帅小伙，关注"Code综艺圈"，跟我一起学~
