查閱了大多數相關資料，總結設計一個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 您可以隨意轉載、摘錄，但請在文章內注明作者和原文鏈接。
|
