标签:自己 href 请求 选择 布局 访问 res 输入 完成
接着IdentityServer4的授权模式继续聊,这篇来说说 Resource Owner Password Credentials授权模式,这种模式在实际应用场景中使用的并不多,只怪其太开放啦,直接在客户端上拿着用户名和密码就去授权服务器获取AccessToken,这样容易被客户端拿着用户名和密码搞坏事;接下来就详细说说。
Resource Owner Password Credentials授权模式与上一节说到的客户端凭据模式不同,这是有用户参与的,用户就是资源拥有者;通过允许在客户端使用用户名和密码的方式向授权服务器获取AccessToken,AccessToken和用户相关,即不同的用户获取到的AccessToken不一样。
流程简要说明:
结合流程,看看代码如何实现,步伐跟上哦;
这里资源服务器和授权服务器就拷贝之前客户端模式的代码(这样每种模式的代码区分开,方便查看),在原有基础上修改代码即可;
代码地址:https://github.com/zyq025/IDS4Demo
模拟在授权服务器中备案用户,方便测试效果,就在内存中模拟;
备案新的客户端,指定其授权方式;
好啦,到这授权服务器的修改就完成啦,用postman先测试一下;
新建一个Winform窗体程序,简单布局安排上;并引入IdentityModel包;
编写获取AccessToken逻辑,在GetAccessToken按钮点击事件中增加代码,如下:
先启动授权服务器,看看access_token运行效果,如下:
获取到AccessToken之后就可以访问受保护的API啦,在调用API按钮点击事件中进行逻辑编写,如下:
授权服务器、资源服务器、客户端启动运行看效果,如下:
以上就是Resource Owner Password Credentials的使用,流程是不是很简单。接下来聊聊这种模式的其他话题;
在oauth2.0中如果使用这种模式,规定是不允许客户端存储资源所有者的用户名和密码的,但如果是第三方客户端想搞事情,就把用户信息先存一把,这样就导致间接泄露用户信息的风险很高(如果第三方客户端被攻击了),这也是这种模式在实际应用场景使用比较少的原因,如果有其他模式选择,不建议使用此模式;
通常以下情况,可以考虑使用:
之前客户端凭据模式的截图:
资源所有者密码模式的截图:
小伙伴肯定看出来不止多一个,但其中比较重要的就是sub这个claim,如果sub存在,调用API的access_token就能区分是代表用户的,否则就是代表客户端的。即有用户参与获取的acess_token是代表用户的,每个用户的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综艺圈",跟我一起学~
IdentityServer4 之 Resource Owner Password Credentials 其实有点尴尬
标签:自己 href 请求 选择 布局 访问 res 输入 完成
原文地址:https://www.cnblogs.com/zoe-zyq/p/14260564.html