整体概况
大多数现代应用程序看起来或多或少像这样：
最常见的交互是：
- 浏览器与 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 来尽可能减小攻击面。