現代的應用程序看起來像這樣:
典型的交互操作包括：
- 瀏覽器與 web 應用程序進行通信
- Web 應用程序與 web Api （有時是在他們自己的有時代表用戶） 通信
- 基於瀏覽器的應用程序與 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解決跨站點的認證問題，OAuth解決跨站點的授權問題。認證和授權是密不可分的。而OpenID和OAuth這兩套協議出自兩個不同的組織，協議上有相似和重合的之處，所以想將二者整合有些難度。好在OpenID Connect作為OpenID的下一版本，在OAuth 2.0的協議基礎上進行擴展，很好的解決了認證和授權的統一，給開發者帶來的便利。Thinktecture IdentityServer v3 是一個.NET 平台上開源的OpenID Connect 提供者 和 OAuth2 驗證服務器。