前言

接著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)存中模擬；

備案新的客戶端，指定其授權(quán)方式；

好啦，到這授權(quán)服務(wù)器的修改就完成啦，用postman先測試一下；

>>授權(quán)服務(wù)器修改完啦，資源服務(wù)器不用動，那就到客戶端啦

新建一個Winform窗體程序，簡單布局安排上；并引入IdentityModel包；

編寫獲取AccessToken邏輯，在GetAccessToken按鈕點擊事件中增加代碼，如下：

先啟動授權(quán)服務(wù)器，看看access_token運行效果，如下：

獲取到AccessToken之后就可以訪問受保護的API啦，在調(diào)用API按鈕點擊事件中進行邏輯編寫，如下：

授權(quán)服務(wù)器、資源服務(wù)器、客戶端啟動運行看效果，如下：

以上就是Resource Owner Password Credentials的使用，流程是不是很簡單。接下來聊聊這種模式的其他話題；

Resource Owner Password Credentials的尷尬之處

在oauth2.0中如果使用這種模式，規(guī)定是不允許客戶端存儲資源所有者的用戶名和密碼的，但如果是第三方客戶端想搞事情，就把用戶信息先存一把，這樣就導(dǎo)致間接泄露用戶信息的風險很高(如果第三方客戶端被攻擊了)，這也是這種模式在實際應(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進行延長有效期而存在的，為了安全和降低風險，access_token的有效期一般設(shè)置的比較短，通常會是兩個小時(根據(jù)需要設(shè)置)，當access_token失效時，常規(guī)的做法就是讓其跳轉(zhuǎn)到登錄頁重新登錄獲取，這樣頻繁的跳轉(zhuǎn)到登錄頁，用戶體驗及其不好，為避免這種情況，需對access_token進行在線續(xù)命，即延長有效期；實現(xiàn)的方案各種各樣，比如有在前端定時檢測的，也有在后端做有效判斷的，但用的相對比較多還是使用refresh_token的形式，當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)該會很少用到，畢竟拿著用戶名和密碼直接在第三方客戶端搞事情，始終還是有風險；下一篇說說Implicit(簡化模式)。

源碼地址：https://github.com/zyq025/IDS4Demo

一個被程序搞丑的帥小伙，關(guān)注"Code綜藝圈"，跟我一起學(xué)~

總結(jié)

以上是生活随笔為你收集整理的IdentityServer4 之 Resource Owner Password Credentials 其实有点尴尬的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。