一、前言
這是官方文件的位址
二、簡介
1、常見的**的互動方式如下:
(1)、瀏覽器與web應用程式互動。單站點應用程式,乙個站點搞定所有的東西,常見的有mvc、webform等等,這類一般不存在多客戶端之說,因為頁面和後台處理程式是強耦合的,也就是說,這個時候我們的後台處理程式只處理對應的頁面,不能給其它的諸如ios、android等等裝置呼叫,所以沒有安全一說.
(2)、web應用程式(可能是本地的,也可能是遠端的)與webapi通訊(有時是自己的，有時代表使用者)。多站點應用程式,這個時候我們通過對業務的聚合提供一套完整的web api給外界呼叫,呼叫者可以是多種裝置,比如ios、andriod、h5站點等.這個時候就有安全一說,因為這個時候如果你的api公開,不做任何的安全措施,意味著所有知道你介面的應用程式都能呼叫.這個時候你必須考慮安全問題
(3)、webapi與webapi之間的呼叫,一般用於規模較大的**,因為當乙個站點達到一定規模,勢必要對業務進行拆分,將不同的業務通過webapi部署到不同的站點上,然後各個站點之間進行通訊,如果有必要可以進行分布式部署,用nginx進行負載均衡.這個時候,也必須考慮站點的安全性,因為不能讓你的核心業務信任外界任何的呼叫.
所以,webapi上的資源安全對我們來說是非常重要的問題,必須保證我門的api受我們的保護,只有經過我們的認證之後,才能進行安全的訪問.通常,一般性的解決方法是,首先使用者(可以是客戶端使用者、可以是服務端使用者)通過了我們的認證系統,然後我們通過授權的方式,把這個資格開發給它.比如說編寫部落格這個事情,只有註冊了並登陸,才會有這個資格,如果沒有註冊,那麼只能訪問的公共資源.當讓這個例子不是很確切.
2、關於認證
(1)、簡單的認證方式
常見的簡單的認證方式一般就是設計乙個註冊登陸系統,接著給我們的api介面繼承乙個基類,基類裡面有判斷使用者是否登陸的操作,這樣就確保了我們的api只有註冊並登陸了我們的系統的使用者才能訪問。但是api與api之間的訪問總不能也這麼設計吧?當然你可以給每個介面約定使用者名稱和密碼兩個引數,然後給api的呼叫者分配乙個賬號密碼,讓api在我們控制範圍內的接受呼叫,但是沒人會去這麼幹,而且會存在安全隱患,比如抓包等等,而且系統這麼設計也不夠優雅,當然你可以說用https加密,但是這不是本文的重點.
(2)、認證協議
關於為什麼要用認證協議請參考web應用的認證機制常見的認證協議有saml2p、ws-federation和openidconnect-saml2p，它們是最流行和部署最廣泛的。
(3)、oauth 2.0認證
oauth2是一種協議，允許應用程式從安全令牌服務請求訪問令牌，並使用它們與api通訊。此委託降低了客戶端應用程式和api的複雜性.
(4)、openid connect
openidconnect和oauth2.0非常相似-實際上openidconnect是oauth2.0之上的乙個擴充套件。兩個基本的安全問題，即身份驗證和api訪問，被組合成乙個單一的協議-通常是安全令牌服務進行一次往返。我們認為，openidconnect和oauth2.0的結合是在可預見的將來保護現代應用程式的最佳方法。identity yserver 4是這兩種協議的實現，並且經過高度優化以解決移動、本地和web應用程式的典型安全問題。
3、identity server4
(1)、簡介
identity server4是一種中介軟體，它將符合規範的openidconnect和oauth2.0端點新增到任意asp.netcore應用程式中。也就是說你的移動端、本地應用程式只要符合openidconnect和oauth2.0協議,且你的asp.netcore應用程式也符合,那麼他們之間就能進行互動.
(2)、實現認證的方式
ms提供的圖,下面簡要介紹下:
users:使用者
使用註冊客戶端並且想要訪問資源的人
client:客戶端
客戶端是一種軟體，它從identity server請求令牌,令牌兩種第一種請求身份令牌一驗證使用者身份的標識令牌(下面會介紹)、另一種是訪問令牌(下面會介紹)一要求訪問資源的令牌。客戶端在請求令牌之前必須先在identity server註冊。客戶端的示例包括web應用程式、本地移動或桌面應用程式、伺服器程序等。
resources:資源
資源是你希望使用identity保護的資源,一般有兩種:一是使用者資料、二是api資源
identity data:identity資料
關於使用者的身份資料標識資訊，例如姓名或電子郵件位址等使用者資訊.
identity token:驗證使用者身份的標識令牌
標識令牌表示身份驗證過程的結果。它至少包含乙個使用者識別符號(稱為subaka subject claimation)和關於使用者身份驗證的方式和時間的資訊。它可以包含其他身份資料。
access token:訪問令牌
訪問令牌允許訪問api資源。客戶端請求訪問令牌並將它們**給api。訪問令牌包含有關客戶端和使用者的資訊(如果存在的話)。api使用該資訊來授權對其資料的訪問。
那麼大致的流程就是這樣，首先使用者使用客戶端,接著客戶端註冊了identity,並向identity申請令牌,接著identity就開始驗證使用者資訊,通過將使用者的資訊儲存到identity data裡面,接著通過openidconnect協議與客戶端進行對話(向請求頭中新增一些必要資訊,並進行資料加密等操作),發放identity token,如果使用者需要訪問api資源,那麼去申請access token,通過將你的訪問令牌(並遵循通oauth2.0協議，向請求中新增一些必要資訊,並進行資料加加密等操作))的同時將你的令牌**給api,通過那麼就可以正常訪問api。
4、identity server4能幹的事
當然indentity能幹的事不只是在遵循安全協議的情況下,傳送安全令牌這麼簡單(當然也不簡單!).
它還能有效的保護您的資源，並提供會話管理和單點登入管理等等.
Identity Server4學習筆記
學習參考資料 博文 學習前的預備知識 oauth 2.0 的乙個簡單解釋 和 oauth 2.0 的四種方式 這個博主的文非常適合做課後總結 因為以上的博文其實已經很詳細了，我也就記一下學習過程中老是誤解的部分。oauth 2.0是乙個委託協議,它可以讓那些控制資源的人允許某個應用以代表他們來訪問他...
授權認證（IdentityServer4
區別 openid authentication 認證 oauth aurhorize 授權 輸入賬號密碼，qq確認輸入了正確的賬號密碼可以登入 認證 下面需要勾選的核取方塊 獲取暱稱 頭像 性別 授權 openid 當你需要訪問a 的時候,a 要求你輸入你的openid,即可跳轉到你的openid...
IdentityServer4 登入使用資料庫
業務場景 identityserver4 預設使用testuser和userstore，需要模擬和載入所有的使用者資料，正式環境肯定不能這樣實現，我們想從自己的資料庫中讀取使用者資訊，另外，因為 identityserver4 實現了 openid 協議，我們想在使用者登入的時候，在請求中新增使用者...