一.整体情况
现代应用程序看起来更像这个：
最常见的相互作用：
- 浏览器与Web应用程序的通信 Browser -> Web App
- Web应用程序与Web API通信
- 基于浏览器的应用程序与Web API
- 本机应用程序与Web API进行沟通
- 基于服务器的应用程序与Web API
- Web API与Web API通信
通常，每个层（前端、中间层和后端）必须保护资源并实现身份验证或授权——通常针对同一个用户存储区。
将这些基本安全功能外包给安全令牌服务可以防止在这些应用程序和端点上复制该功能。
应用支持安全令牌服务将引起下面的体系结构和协议：
这样的设计将安全问题分为两部分：
二.认证（Authentication）
认证可以让一个应用程序知道当前用户的身份。 通常，这些应用程序代表该用户管理数据，并且需要确保该用户只能访问允许他访问的数据。最常见的示例是Web应用程序，但基于本地和基于js的应用程序也需要进行身份验证。
最常用的认证协议saml2p、WS-Federation和OpenID，saml2p协议是最流行和实际应用最多的。
OpenID Connect对于现在应用来说是被认为是未来最有潜力的，这是专为移动应用场景设计的，一开始就被设计成对移动应用场景友好。
三.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来使攻击面尽可能小。