查閱了大多數相關資料，總結設計一個IdentityServer4認證授權方案，我們先看理論，後設計方案。
1、快速理解認證授權
我們先看一下網站發起QQ認證授權，授權通過後獲取使用者頭像，暱稱的流程。
1、輸入賬號密碼，QQ確認輸入了正確的賬號密碼可以登入 --->認證
2、下面需要勾選的核取方塊（獲取暱稱、頭像、性別）----->授權
點選授權並登入後，登入後就可以憑藉QQ授權的授權碼去獲取暱稱、頭像、性別了。
是不是看起來流程很簡單？對，就是這麼簡單，換成我們自己的網站也是一樣的。
比如公司開發出很多業務網站，網站1、網站2、網站3......，然後我們想使用同一個賬號登入後，其他網站開啟也是登入狀態。
這個時候只需要有一個統一認證登入平臺（類似於QQ認證授權），然後就可以實現了，避免了一個網站一個賬號，每次都需要輸入賬號密碼的情況了。
2、IdentityServer4的概念？
IdentityServer4是基於ASP.NET Core實現的認證和授權框架，是對OpenID Connect和OAuth 2.0協議的實現。
看下面這張圖理解一下這個概念，看不懂？沒關係，不影響你敲程式碼的速度，接著往下看。
對上圖各個節點的解釋：
IdentityServer
身份認證伺服器是一個實現了OpenID Connect和OAuth 2.0協議的身份提供者，它負責向客戶端釋出安全令牌
User
使用註冊客戶端訪問資源的使用者
Client
客戶端從標識伺服器請求令牌，要麼用於認證使用者（請求身份令牌），要麼用於訪問資源（請求訪問令牌）
客戶端必須首先在身份伺服器上註冊，然後才能請求令牌
這裡的客戶端可以是web應用程式、native mobile， desktop applications, SPA 等程式Resource
資源是你想要用身份認證伺服器保護的東西，如：使用者的身份資料或api
每個資源都有一個惟一的名稱，客戶端使用這個名稱來指定他們想要訪問的資源
關於使用者的身份資料標識（也稱為claim），例如姓名或電子郵件地址Identity Token
身份令牌代表身份驗證過程的結果Access Token
訪問令牌授權客戶端以允許訪問哪些API資源，訪問令牌包含客戶端和使用者的資訊
2.1、OpenID Connect（認證）
OpenID Connect由OpenID基金會於2014年釋出的一個開放標準, 是建立在OAuth 2.0協議上的一個簡單的身份標識層, OpenID Connect 相容 OAuth 2.0. 實現身份認證（Authentication）
參考資料：https://openid.net/connect/
OpenID Connect文件：https://openid.net/specs/openid-connect-discovery-1_0.html
這裡用JSON Web Token（JWT：RFC7519），它包含一組關於使用者身份的宣告（claim），如：使用者的標識（sub）、頒發令牌的提供程式的識別符號（iss）、建立此標識的Client標識（aud），還包含token的有效期以及其他相關的上下文資訊。
2.2、OAuth2.0（授權）
OAuth2.0是一個開放的工業標準的授權協議（Authorization），它允許使用者授權讓第三方應用直接訪問使用者在某一個服務中的特定資源，但不提供給第三方賬號及密碼資訊。
參考資料：https://www.cnblogs.com/xiandnc/p/9763121.html
OAuth2.0 文件：https://tools.ietf.org/html/rfc6749#page-73
OAuth2.0四種授權方式：http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html
認證是身份識別，鑑別你是誰；
授權是授權許可，告訴你可以做什麼。
如上圖的網站發起QQ認證授權，登入QQ是認證身份，鑑別你是誰，勾選核取方塊授權是授權許可，告訴你可以做什麼（讀取頭像，暱稱、性別）。
具體概念就不展開了，大家點選上面的參考資料可以瞭解詳細內容，OAuth整體流程如下：
客戶端必須得到使用者的授權，才能獲取令牌。
OAuth2.0定義了四種授權方式（除了這是四種，可以自定義授權模式，如：簡訊模式、郵箱模式等）：
- 授權碼模式（authorization code）
- 簡化模式（implicit）
- 密碼模式（resource owner password credentials）
- 客戶端模式（client credentials）
2.3、IdentityServer4功能特性
使用者認證服務
基於OpenID Connect實現的獨立的認證服務實現對多平臺（web, native, mobile, services）的集中認證
API訪問授權
為各種型別的客戶機頒發api訪問令牌，例如伺服器到伺服器、web應用程式、spa和native/mobile程式
聯合身份認證
支援外部身份提供者，如Azure Active Directory、Google、Facebook等
定製化的實現
IdentityServer4的許多方面可以定製以滿足您的需要,因為它是一個框架，而不是SaaS服務，所以可以通過編寫程式碼來調整實現，以適應不同的場景
成熟的開原方案
使用許可的Apache2開源協議，允許在其之上構建商業產品，也作為.NET基金會支援的專案 （https://dotnetfoundation.org/projects?type=project&ps=10&pn=6）
提供免費的商業支援
官方可以對使用者提供部分的免費商業支援
3、場景演示：認證授權系統架構設計方案
電商場景設計方案（初稿）
系統架構圖如下：
這張架構圖缺點：
- 釋出頻繁，釋出影響整個系統；
- 很難做到敏捷開發；
- 維護性可能會存在一定的弊端，主要看內部架構情況；
大多數對於多客戶端登入授權來說可能已經實現了Oauth 2.0 的身份授權驗證，但是是和業務整合在一個閘道器裡面，這樣不是很好的方式；
我們可以把裡面的很多業務單獨建立一個獨立的閘道器（比如代理商業務，或者其他比較頻繁操作的業務以及第三方業務），並且把授權服務一併獨立出來，調整後的系統架構圖如下：
身份授權從業務系統中獨立出來後，有了如下的優勢：
- 授權服務不受業務的影響，如果業務閘道器當機了，那至少不會影響代理商閘道器的業務授權系統的使用；
- 授權服務一旦建立，一般就很難進行升級，除非特殊情況；
- 在敏捷開發中，業務系統可能釋出頻繁（升級更新），這樣也不至於影響了授權系統服務導致代理商業務受到影響；
代理商業務獨立後，代理商可能會增加秒殺活動，秒殺時支付訂單集中在某一時刻翻了十幾倍，這時候整個API閘道器可能扛不住，
如果資料過多，增加幾臺負載伺服器可能也有點吃力，以至於整個業務系統受到影響；
這個時候把支付業務從系統中拆分出成獨立的支付閘道器，並做了一定的負載，這時候系統架構圖就演變成如下：
支付業務獨立後的優勢：
- 支付閘道器服務更新不會太頻繁，減少整個系統因為釋出導致的一系列問題，增強穩定性；
- 支付系統出現當機不影響整個系統的使用，使用者還可以使用其他操作，技術和運維人員也比較好排查定位問題所在；
授權中心單獨一個閘道器，訪問API閘道器、支付業務閘道器、代理商業務閘道器都需要先通過授權中心獲得授權拿到訪問令牌AccessToken 才能正常的訪問這些閘道器，
這樣授權模組就不會受任何的業務影響，同時各個業務閘道器也不需要寫同樣的授權業務的程式碼；
業務閘道器僅僅只需關注本身的業務即可，授權中心僅僅只需要關注維護授權；
經過這樣升級改造後整個系統維護性得到很大的提高，相關的業務也可以針對具體情況進行選擇性的擴容。
參考文獻
Asp.Net Core IdentityServer4 中的基本概念：https://www.cnblogs.com/jlion/p/12437441.html
IdentityServer4+Vue+asp.netcore開源專案地址：https://www.cnblogs.com/WQLBlog/p/12356853.html
Asp.Net Core 中IdentityServer4 授權中心之應用實戰：https://www.cnblogs.com/jlion/p/12447081.html
基於IdentityServer4 實現.NET Core的認證授權：https://www.cnblogs.com/xiandnc/p/10150814.html
|
歡迎關注訂閱微信公眾號【熊澤有話說】，更多好玩易學知識等你來取
作者：熊澤-學習中的苦與樂 公眾號：熊澤有話說 出處： https://www.cnblogs.com/xiongze520/p/15543795.html 您可以隨意轉載、摘錄，但請在文章內註明作者和原文連結。
|
