學習參考資料
博文 學習前的預備知識
oauth 2.0 的乙個簡單解釋 和 oauth 2.0 的四種方式
這個博主的文非常適合做課後總結
因為以上的博文其實已經很詳細了，我也就記一下學習過程中老是誤解的部分。
oauth 2.0是乙個委託協議, 它可以讓那些控制資源的人允許某個應用以代表他們來訪問他們控制的資源。 這個應用從資源的所有者（使用者或第三方平台）那裡獲得到授權(authorization)和access token, 隨後就可以使用這個access token來訪問資源.
oauth 2.0是乙個開放的協議, 它允許使用簡單和標準的方法從web, 移動或桌面（例如asp.net core mvc, angular, wpf ）應用來進行安全的授權(authorization).
簡單點說授權就是我能做什麼。使用access token可以用來訪問資源，但是卻不能用來登入。登入這種操作叫做認證/身份驗證(authentication), 而openid connect則可以完成這項工作.
openid connect是建立在oauth2協議上的乙個簡單的身份標識層, 所以openid connect相容oauth2.
使用openid connect, 客戶端應用可以請求乙個叫identity token的token, 它會和access token一同返回給客戶端應用. 這個identity token就可以被用來登入客戶端應用程式, 而這個客戶端應用還可以使用access token來訪問api資源.
綜上,openid connect是更高階的協議, 它擴充套件並替代了oauth2. 儘管現在我們經常說我們在使用oauth2來保護api, 其實更準確的說, 大多數情況下, 我們使用的是openid connect.
關於為什麼不用oauth2.0來做身份認證的事
為什麼不使用 oauth 2.0 的 acess token 來解決身份認證的問題？
a：• access token 不含有身份認證的資訊
• access token 的生命週期有可能會很長，即使使用者離開了，它仍然有效
• access token 可能被其它客戶端借用
• access token 本來也不是為客戶端準備的，它對客戶端不透明，但是客戶端可以從 access token 裡得到一些使用者資訊。access token 的真正目標觀眾是被保護資源
authorization code是使用授權伺服器作為客戶端和資源所有者的中介來獲取的. 所以這裡不是採用直接從資源所有者獲得授權的方式, 而是採用授權伺服器作為中介的方式. 在授權伺服器把資源所有者送回到(重定向)客戶端的時候帶著這個臨時的憑據: authorization code (我暫時叫它授權碼吧), 它就代表著資源所有者委託給客戶端應用的許可權.
authorization code在安全方面有一些重要的優點: 可以對客戶端應用進行身份認證; access token是直接傳送到客戶端應用的, 不經過資源所有者的瀏覽器, 所以不會暴露access token給外界, 包括資源所有者.
implicit, 我叫它隱式授權吧. 它是authorization code的乙個簡化版本, 它針對瀏覽器內的客戶端應用(例如js, angular的應用)進行了優化. 在implicit流程裡, 沒有給客戶端傳送授權碼(authorization code), 而是直接給它傳送了access token. 之所以叫這種授權型別implicit, 是因為流程裡並沒有發行任何中間憑據.
在implicit流程裡發行access token的時候, 授權伺服器並沒有對客戶端應用進行身份認證. 某些情況下, 客戶端的身份可以通過帶著access token重定向回客戶端的uri來驗證. acces token可能會暴露給任何使用該瀏覽器的人或者應用.
implicit授權確實可以提高瀏覽器內應用的響應性和效率, 畢竟它減少了來回往返的次數. 但是方便可能會帶來風險, 建議如果可以的話盡量使用authorization code, 當然這個需要自己去權衡.
resource owner password credentials, 資源所有者密碼憑據. 顧名思義, 可以直接使用密碼憑據(使用者名稱和密碼)作為授權來獲得access token. 只有當資源所有者和客戶端之間高度信任的時候並且其它授權方式不可用的時候才可以使用這種授權方式.
這裡資源所有者的憑據只應該用於一次請求並用於交換access token. 這種授權方式可以讓客戶端免於儲存資源所有者的憑據(如果以後還需要使用的話), 通過交換乙個長期有效的access token或refresh token都可以達到這種效果.
client credentials. 有時候, 資源或者叫資源伺服器並不屬於某個終端使用者, 也就是沒有資源所有者對該資源負責. 但是客戶端應用肯定還是要訪問這些資源, 這時候就只能使用client credentials這種授權方式了.
事實上，弄清了1,2,4基本上就都懂了。主要是要區分瀏覽器，客戶端，授權伺服器，資源保護者四個的聯絡。
授權認證（IdentityServer4
區別 openid authentication 認證 oauth aurhorize 授權 輸入賬號密碼，qq確認輸入了正確的賬號密碼可以登入 認證 下面需要勾選的核取方塊 獲取暱稱 頭像 性別 授權 openid 當你需要訪問a 的時候,a 要求你輸入你的openid,即可跳轉到你的openid...
Identity Server4學習系列一
一 前言 這是官方文件的位址 二 簡介 1 常見的 的互動方式如下 1 瀏覽器與web應用程式互動。單站點應用程式,乙個站點搞定所有的東西,常見的有mvc webform等等,這類一般不存在多客戶端之說,因為頁面和後台處理程式是強耦合的,也就是說,這個時候我們的後台處理程式只處理對應的頁面,不能給其...
IdentityServer4 登入使用資料庫
業務場景 identityserver4 預設使用testuser和userstore，需要模擬和載入所有的使用者資料，正式環境肯定不能這樣實現，我們想從自己的資料庫中讀取使用者資訊，另外，因為 identityserver4 實現了 openid 協議，我們想在使用者登入的時候，在請求中新增使用者...