【IdentityServer4文檔】- 整體情況
整體概況
大多數現代應用程序看起來或多或少像這樣：
最常見的交互是：
- 瀏覽器與 Web 應用程序進行通信
- Web 應用程序與 Web API 進行通信（有時是Web應用程序自己發起，有時代表用戶發起）
- 基於瀏覽器的應用程序與 Web API 進行通信
- 本機應用程序與Web API進行通信
- 基於服務器的應用程序與Web API進行通信
- Web API與Web API進行通信（有時是他們自己發起，有時代表用戶發起）
通常，每個層（前端、中間層和後端）都必須保護資源並實現身份驗證/或授權——通常是針對同一用戶存儲。
將這些基本安全功能外包給安全令牌服務，可防止在這些應用程序和端點之間復制該功能。
重構應用程序以支持安全令牌服務，會演變成以下體系結構和協議：
這樣的設計將安全問題分為兩部分：
身份驗證
當應用程序需要知道當前用戶的身份時需要身份驗證。 通常，這些應用程序代表該用戶管理數據，並且需要確保該用戶只能訪問允許他訪問的數據。 最常見的例子是（經典的）Web 應用程序——但是本機和基於 js 的應用程序也需要認證。
最常見的身份驗證協議是SAML2p，WS-Federation和OpenID Connect - 但 SAML2p 是最流行和最廣泛應用的。
OpenID Connect 是三者中最新的，但它被現代應用程序認為是未來最有潛力的。因為它從一開始就被構建為對移動應用場景提供友好 API 訪問。
API 訪問
應用程序有兩種與 API 通信的基本方式 - 使用應用程序標識，或委托用戶的身份。 有時兩種方法需要結合起來使用。
OAuth2 是一種協議，它允許應用程序從安全令牌服務請求訪問令牌並使用它們與 API 進行通信。這種機制降低了客戶端應用程序與 API 通信的復雜性，因為身份驗證和授權可以是集中式的。
OpenID Connect 和 OAuth 2.0 結合
OpenID Connect 和 OAuth 2.0 非常相似 - 實際上，OpenID Connect 是在 OAuth 2.0 之上的一個擴展。 身份認證和 API 訪問這兩個基本的安全問題被合並為一個協議 - 通常只需一次往返安全令牌服務。
我們認為 OpenID Connect 和 OAuth 2.0 的組合，是可預見在未來是保護現代應用程序的最佳方法。IdentityServer4 是這兩種協議的實現，並且被高度優化以解決當今移動應用、本地應用和 Web 應用的典型安全問題。
IdentityServer4 可以幫你做什麽
IdentityServer 是一個可將符合規範的 OpenID Connect 和 OAuth 2.0 端點添加到任意的 ASP.NET Core 應用程序中的中間件。通常，您構建（或重新使用）包含登錄和註銷頁面的應用程序（也許可能同意 - 取決於您的需求），IdentityServer 中間件會向其添加必要的協議頭，以便客戶端應用程序可以使用這些標準協議與之通信。
托管應用程序可以像您希望的那樣復雜，但我們通常建議通過包含僅與認證相關的 UI 來盡可能減小攻擊面。
備註：原文地址：https://github.com/ganqiyin/IdentityServer4/blob/dev/docs_cn/intro/big_picture.rst
【IdentityServer4文檔】- 整體情況