大多數現代應用程序或多或少看起來像這樣：
最常見的互動是：
- 瀏覽器與Web應用程序通信
- Web應用程序與Web API進行通信（Web應用程序自身 或 代表用戶 與 Web API 通信）
- 基於瀏覽器的應用程序與Web API通信
- 本地應用程序與Web API通信
- 基於服務器的應用程序與Web API通信
- Web API與Web API進行通信（WebAPI自身 或 代表用戶與另一個WebAPI 通信）
通常，每個層（前端，中間層和后端）都必須保護資源並實現身份驗證和授權 - 通常針對同一個用戶存儲。
將這些基本安全功能外包給安全令牌服務可防止在這些應用程序和端點之間復制該功能。
重構應用程序以支持安全令牌服務會產生以下體系結構和協議：
這種設計將安全問題分為兩部分：
1.1 認證
當應用程序需要知道當前用戶的身份時，需要進行身份驗證。通常，這些應用程序代表該用戶管理數據，並且需要確保該用戶只能訪問允許的數據。最常見的示例是（經典）Web應用程序 - 但是基於本地和JS的應用程序也需要身份驗證。
最常見的身份驗證協議是SAML2p，WS-Federation和OpenID Connect - SAML2p是最受歡迎和最廣泛部署的。
OpenID Connect是三者中的最新產品，但被認為是未來，因為它具有最大的現代應用潛力。它從一開始就為移動應用場景而構建，旨在實現API友好。
1.2 API訪問
應用程序有兩種基本方式與API通信 - 使用應用程序標識或委派用戶身份。有時兩種方法都需要結合起來。
OAuth2是一種協議，允許應用程序從安全令牌服務請求訪問令牌，並使用它們與API通信。此委派降低了客戶端應用程序和API的復雜性，因為身份驗證和授權可以集中。
1.3 OpenID Connect和OAuth 2.0 - 更好地結合在一起
OpenID Connect和OAuth 2.0非常相似 - 事實上，OpenID Connect是OAuth 2.0之上的擴展。兩個基本的安全問題，即身份驗證和API訪問，被合並為一個協議 - 通常只需一次往返安全令牌服務。
我們相信OpenID Connect和OAuth 2.0的結合是在可預見的未來保護現代應用程序的最佳方法。IdentityServer4是這兩種協議的實現，經過高度優化，可以解決當今移動，本地和Web應用程序的典型安全問題。
1.4 IdentityServer4如何提供幫助
IdentityServer是一個中間件，可將符合規范的OpenID Connect和OAuth 2.0端點添加到任意ASP.NET Core應用程序中。
通常，您構建（或復用）包含登錄和注銷頁面的應用程序（或者 授權確認頁），並且IdentityServer 中間件會將需要的協議添加到頁面頭部，這樣一來客戶端應用程序就能夠使用這些標准協議跟它協商了。
你可以根據你的需要使用盡可能復雜的宿主應用程序。但是，為了保持受攻擊面盡可能小, 我們一般建議你只將認證相關的UI包含進來。