前言
接著IdentityServer4的授權(quán)模式繼續(xù)聊磷箕，這篇來說說 Resource Owner Password Credentials授權(quán)模式菱肖，這種模式在實際應(yīng)用場景中使用的并不多乏沸，只怪其太開放啦野揪，直接在客戶端上拿著用戶名和密碼就去授權(quán)服務(wù)器獲取AccessToken游昼，這樣容易被客戶端拿著用戶名和密碼搞壞事仪缸；接下來就詳細說說。
正文
Resource Owner Password Credentials授權(quán)模式與上一節(jié)說到的客戶端憑據(jù)模式不同痴荐，這是有用戶參與的血柳，用戶就是資源擁有者；通過允許在客戶端使用用戶名和密碼的方式向授權(quán)服務(wù)器獲取AccessToken蹬昌，AccessToken和用戶相關(guān)混驰，即不同的用戶獲取到的AccessToken不一樣。
術(shù)語解釋：
- Resource Owner：資源所有者皂贩，即擁有資源的用戶栖榨； 絕大對數(shù)小伙伴都應(yīng)該有自己的QQ，如果沒特殊情況明刷，相信每一個小伙伴的QQ空間中都有自己曾經(jīng)覺得很酷或很有紀念意義的照片婴栽，這里的照片就是資源，而小伙伴就是資源所有者辈末。 QQ服務(wù)器就是資源服務(wù)器愚争。
Resource Owner Password Credentials 流程
流程簡要說明：
- 首先用戶和客戶端需要提前在授權(quán)服務(wù)器上備案過的，用戶沒有備案挤聘，在資源服務(wù)器肯定就沒有對應(yīng)的資源轰枝，客戶端沒有備案就不能隨意去授權(quán)服務(wù)器獲取AccessToken；
- 用戶在客戶端上輸入用戶名和密碼组去，并帶上備案過的客戶端憑據(jù)一起請求授權(quán)服務(wù)器獲取AccessToken;
- 授權(quán)服務(wù)器驗證用戶憑據(jù)和客戶端憑據(jù)鞍陨，成功之后直接返回代表該用戶的AccessToken；
- 用戶在操作時从隆，帶上AccessToken訪問資源服務(wù)器诚撵；
- 資源服務(wù)器正常返回結(jié)果，如果沒有AccessToken是不能訪問受保護資源的键闺；
結(jié)合流程寿烟，看看代碼如何實現(xiàn)，步伐跟上哦辛燥；
這里資源服務(wù)器和授權(quán)服務(wù)器就拷貝之前客戶端模式的代碼(這樣每種模式的代碼區(qū)分開筛武，方便查看)，在原有基礎(chǔ)上修改代碼即可挎塌；
代碼地址：https://github.com/zyq025/IDS4Demo
>>在原有的授權(quán)服務(wù)器上增加代碼
-
模擬在授權(quán)服務(wù)器中備案用戶徘六，方便測試效果，就在內(nèi)存中模擬勃蜘；
image-20210106132546239 -
備案新的客戶端硕噩，指定其授權(quán)方式；
image-20210106133339652 -
好啦缭贡，到這授權(quán)服務(wù)器的修改就完成啦炉擅，用postman先測試一下辉懒；
image-20210106135112325
>>授權(quán)服務(wù)器修改完啦，資源服務(wù)器不用動谍失，那就到客戶端啦
-
新建一個Winform窗體程序眶俩，簡單布局安排上；并引入IdentityModel包快鱼；
image-20210106142213334 -
編寫獲取AccessToken邏輯颠印，在GetAccessToken按鈕點擊事件中增加代碼，如下：
image-20210106150232248 -
先啟動授權(quán)服務(wù)器抹竹，看看access_token運行效果线罕，如下：
image-20210106150619514 -
獲取到AccessToken之后就可以訪問受保護的API啦，在調(diào)用API按鈕點擊事件中進行邏輯編寫窃判，如下：
image-20210106151317975 -
授權(quán)服務(wù)器钞楼、資源服務(wù)器、客戶端啟動運行看效果袄琳，如下：
image-20210106151654463
以上就是Resource Owner Password Credentials的使用询件，流程是不是很簡單。接下來聊聊這種模式的其他話題唆樊；
Resource Owner Password Credentials的尷尬之處
在oauth2.0中如果使用這種模式宛琅，規(guī)定是不允許客戶端存儲資源所有者的用戶名和密碼的，但如果是第三方客戶端想搞事情逗旁，就把用戶信息先存一把嘿辟，這樣就導(dǎo)致間接泄露用戶信息的風(fēng)險很高(如果第三方客戶端被攻擊了)，這也是這種模式在實際應(yīng)用場景使用比較少的原因痢艺，如果有其他模式選擇仓洼，不建議使用此模式介陶；
通常以下情況堤舒，可以考慮使用：
- 客戶端是可高度信任的，且安全性要有保障哺呜；
- 遺留應(yīng)用舌缤，沒有其他好的解決方案，可以使用某残；
有用戶參與獲取的accessToken和客戶端憑據(jù)獲取到的有什么區(qū)別
之前客戶端憑據(jù)模式的截圖：
資源所有者密碼模式的截圖：
小伙伴肯定看出來不止多一個国撵，但其中比較重要的就是sub這個claim，如果sub存在玻墅，調(diào)用API的access_token就能區(qū)分是代表用戶的介牙，否則就是代表客戶端的。即有用戶參與獲取的acess_token是代表用戶的澳厢，每個用戶的token都不一樣环础。
refresh_token得補上
refresh_token是為了給access_token進行延長有效期而存在的囚似，為了安全和降低風(fēng)險，access_token的有效期一般設(shè)置的比較短线得，通常會是兩個小時(根據(jù)需要設(shè)置)饶唤，當(dāng)access_token失效時，常規(guī)的做法就是讓其跳轉(zhuǎn)到登錄頁重新登錄獲取贯钩，這樣頻繁的跳轉(zhuǎn)到登錄頁募狂，用戶體驗及其不好，為避免這種情況角雷，需對access_token進行在線續(xù)命祸穷，即延長有效期；實現(xiàn)的方案各種各樣勺三，比如有在前端定時檢測的粱哼，也有在后端做有效判斷的，但用的相對比較多還是使用refresh_token的形式檩咱，當(dāng)access_token失效時揭措，會采用refresh_token去請求新的access_token，保證用戶正常操作刻蚯。
如果需要在獲取access_token的時候同時返回refresh_token绊含，需要在授權(quán)服務(wù)器上備案客戶端時將AllowOfflineAccess設(shè)置為true，如下所示：
refresh_token具體使用炊汹，在后續(xù)的案例單獨說吧躬充。
總結(jié)
關(guān)于Resource Owner Password Credentials 就簡單說這么多，主要是看看如何使用讨便，相信小伙伴在新的項目中應(yīng)該會很少用到充甚，畢竟拿著用戶名和密碼直接在第三方客戶端搞事情，始終還是有風(fēng)險霸褒；下一篇說說Implicit(簡化模式)伴找。
一個被程序搞丑的帥小伙，關(guān)注"Code綜藝圈"废菱，跟我一起學(xué)~
