OAuth（Open Authorization，開放授權）是爲用戶資源的授權定義了一個安全、開放及簡單的標準，通過這個標準，第三方無需知道用戶的賬號和密碼，就可獲取到用戶的授權信息。
OAuth2.0是OAuth協議的延續版本，但不向後兼容OAuth 1.0即完全廢止了OAuth1.0。
OpenID是一個去中心化的網上身份認證系統。對於支持OpenID的網站，用戶不需要記住像用戶名和密碼這樣的傳統驗證標記。取而代之的是，他們只需要預先在一個作爲OpenID身份提供者（identity provider, IdP）的網站上註冊。OpenID是去中心化的，任何網站都可以使用OpenID來作爲用戶登錄的一種方式，任何網站也都可以作爲OpenID身份提供者。OpenID既解決了問題而又不需要依賴於中心性的網站來確認數字身份。
老系統的現狀
每個老系統都起源自新系統，用的久了，就慢慢變老了！
剛開始設計網站的時候，僅僅是一個用戶登錄；然後加入了角色，最後加入了鑑權，後來又增加了限次密碼失敗，後來的後來，再增加白名單，最後，增加了二次驗證…，最後的最後，加入了第三方的賬號登錄。 等等，好像沒有最後，還有開發api呢，還有許多功能呢… …
是時候上統一登錄授權了吧，最好符合Oauth2.0… …
Oauth的授權四模式：
- 授權碼模式（authorization code）
是功能最完整、流程最嚴密的授權模式。它的特點就是通過客戶端的後臺服務器，與"服務提供商"的認證服務器進行互動。 - 簡化模式（implicit）
不通過第三方應用程序的服務器，直接在瀏覽器中向認證服務器申請令牌，跳過了"授權碼"這個步驟，因此得名。所有步驟在瀏覽器中完成，令牌對訪問者是可見的，且客戶端不需要認證。 - 密碼模式（resource owner password credentials）
用戶向客戶端提供自己的用戶名和密碼。客戶端使用這些信息，向"服務商提供商"索要授權。在這種模式中，用戶必須把自己的密碼給客戶端，但是客戶端不得儲存密碼。 - 客戶端模式（client credentials）
指客戶端以自己的名義，而不是以用戶的名義，向"服務提供商"進行認證。嚴格地說，客戶端模式並不屬於OAuth框架所要解決的問題。在這種模式中，用戶直接向客戶端註冊，客戶端以自己的名義要求"服務提供商"提供服務，其實不存在授權問題。
.net core的支持
ASP.NET Core 標識是支持用戶界面（UI）登錄功能的成員資格系統。 用戶可以創建一個具有存儲在標識中的登錄信息的帳戶，也可以使用外部登錄提供程序。 支持的外部登錄提供程序包括Facebook、Google、Microsoft 帳戶和 Twitter。
若要保護 web Api 和 Spa，請使用IdentityServer4。 IdentityServer4 是 ASP.NET Core 3.0 的 OpenID Connect 和 OAuth 2.0 framework。 IdentityServer4 支持以下安全功能：
- 身份驗證即服務 (AaaS)
- 跨多個應用程序類型的單一登錄/註銷 (SSO)
- API 的訪問控制
- Federation Gateway
再來看看IdentityServer4
OpenID Connect和OAuth 2.0非常相似-實際上，OpenID Connect是OAuth 2.0的擴展。身份驗證和API訪問這兩個基本的安全問題被組合成一個協議-通常只需一次往返於安全令牌服務。
我們相信OpenID Connect和OAuth 2.0的結合是在可預見的將來保護現代應用程序的最佳方法。IdentityServer4是這兩個協議的實現，並且經過高度優化，可以解決當今移動，本機和Web應用程序中的典型安全問題。
實際上，按照教程，花費2個小時，你就可以手擼一個登錄服務了。
搞定了登錄，但是授權怎麼辦呢？
相信擼到這一步的你也會有同樣的困惑。
拆分設計
先理解下概念：
- 授權（authorization）：授權，批准;批准（或授權）的證書；
- 認證（authentication）：認證;身份驗證;證明，鑑定;密押。
- 資源（Resource），在系統中定義的第一件事就是要保護的資源。這可能是您的用戶的身份信息，例如個人資料數據或電子郵件地址，或對API的訪問，id要求資源必須有 openid。
因此結合途中的5，6，7步驟，所做的下一步授權，應該結合資源服務進行設計。
當然可以設計用戶中心，資源中心等分開設計，主要是綜合業務的需求。
總結
擼一個登錄服務很easy，但想設計一套綜合舊項目的統一登錄認證鑑權授權平臺是比較複雜的過程，不可能是幾天搞定。但只要你分析清除每個環節，逐步實現，當可在1人月內完成設計和編碼。