IdentityServer4 之 Resource Owner Password Credentials 其实有点尴尬

时间:2024-01-27 22:01:25

前言

接着IdentityServer4的授权模式继续聊,这篇来说说 Resource Owner Password Credentials授权模式,这种模式在实际应用场景中使用的并不多,只怪其太开放啦,直接在客户端上拿着用户名和密码就去授权服务器获取AccessToken,这样容易被客户端拿着用户名和密码搞坏事;接下来就详细说说。

正文

Resource Owner Password Credentials授权模式与上一节说到的客户端凭据模式不同,这是有用户参与的,用户就是资源拥有者;通过允许在客户端使用用户名和密码的方式向授权服务器获取AccessToken,AccessToken和用户相关,即不同的用户获取到的AccessToken不一样。

术语解释:
  • Resource Owner:资源所有者,即拥有资源的用户; 绝大对数小伙伴都应该有自己的QQ,如果没特殊情况,相信每一个小伙伴的QQ空间中都有自己曾经觉得很酷或很有纪念意义的照片,这里的照片就是资源,而小伙伴就是资源所有者。 QQ服务器就是资源服务器。

Resource Owner Password Credentials 流程

image-20210106122921243

流程简要说明:

  1. 首先用户和客户端需要提前在授权服务器上备案过的,用户没有备案,在资源服务器肯定就没有对应的资源,客户端没有备案就不能随意去授权服务器获取AccessToken;
  2. 用户在客户端上输入用户名和密码,并带上备案过的客户端凭据一起请求授权服务器获取AccessToken;
  3. 授权服务器验证用户凭据和客户端凭据,成功之后直接返回代表该用户的AccessToken;
  4. 用户在操作时,带上AccessToken访问资源服务器;
  5. 资源服务器正常返回结果,如果没有AccessToken是不能访问受保护资源的;

结合流程,看看代码如何实现,步伐跟上哦;

这里资源服务器和授权服务器就拷贝之前客户端模式的代码(这样每种模式的代码区分开,方便查看),在原有基础上修改代码即可;

代码地址:https://github.com/zyq025/IDS4Demo

>>在原有的授权服务器上增加代码
  1. 模拟在授权服务器中备案用户,方便测试效果,就在内存中模拟;

    image-20210106132546239

  2. 备案新的客户端,指定其授权方式;

    image-20210106133339652

  3. 好啦,到这授权服务器的修改就完成啦,用postman先测试一下;

    image-20210106135112325

>>授权服务器修改完啦,资源服务器不用动,那就到客户端啦
  1. 新建一个Winform窗体程序,简单布局安排上;并引入IdentityModel包;

    image-20210106142213334

  2. 编写获取AccessToken逻辑,在GetAccessToken按钮点击事件中增加代码,如下:

    image-20210106150232248

  3. 先启动授权服务器,看看access_token运行效果,如下:

    image-20210106150619514

  4. 获取到AccessToken之后就可以访问受保护的API啦,在调用API按钮点击事件中进行逻辑编写,如下:

    image-20210106151317975

  5. 授权服务器、资源服务器、客户端启动运行看效果,如下:

    image-20210106151654463

以上就是Resource Owner Password Credentials的使用,流程是不是很简单。接下来聊聊这种模式的其他话题;

Resource Owner Password Credentials的尴尬之处

在oauth2.0中如果使用这种模式,规定是不允许客户端存储资源所有者的用户名和密码的,但如果是第三方客户端想搞事情,就把用户信息先存一把,这样就导致间接泄露用户信息的风险很高(如果第三方客户端被攻击了),这也是这种模式在实际应用场景使用比较少的原因,如果有其他模式选择,不建议使用此模式;

通常以下情况,可以考虑使用:

  • 客户端是可高度信任的,且安全性要有保障;
  • 遗留应用,没有其他好的解决方案,可以使用;

有用户参与获取的accessToken和客户端凭据获取到的有什么区别

之前客户端凭据模式的截图:

image-20201231154747613

资源所有者密码模式的截图:

image-20210106162450204

小伙伴肯定看出来不止多一个,但其中比较重要的就是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,如下所示:

image-20210107100506699

refresh_token具体使用,在后续的案例单独说吧。

总结

关于Resource Owner Password Credentials 就简单说这么多,主要是看看如何使用,相信小伙伴在新的项目中应该会很少用到,毕竟拿着用户名和密码直接在第三方客户端搞事情,始终还是有风险;下一篇说说Implicit(简化模式)

一个被程序搞丑的帅小伙,关注"Code综艺圈",跟我一起学~