标签：Resource AccessToken 用户 token 授权 Owner 服务器 IdentityServer4 客户端
前言
接着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
>>在原有的授权服务器上增加代码
-
模拟在授权服务器中备案用户，方便测试效果，就在内存中模拟；
-
备案新的客户端，指定其授权方式；
-
好啦，到这授权服务器的修改就完成啦，用postman先测试一下；
>>授权服务器修改完啦，资源服务器不用动，那就到客户端啦
-
新建一个Winform窗体程序，简单布局安排上；并引入IdentityModel包；
-
编写获取AccessToken逻辑，在GetAccessToken按钮点击事件中增加代码，如下：
-
先启动授权服务器，看看access_token运行效果，如下：
-
获取到AccessToken之后就可以访问受保护的API啦，在调用API按钮点击事件中进行逻辑编写，如下：
-
授权服务器、资源服务器、客户端启动运行看效果，如下：
以上就是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综艺圈"，跟我一起学~
标签：Resource,AccessToken,用户,token,授权,Owner,服务器,IdentityServer4,客户端 来源： https://www.cnblogs.com/zoe-zyq/p/14260564.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。