第1章背景 - Identity Server 4 中文文档(v1.0.0)

大多数现代应用程序或多或少看起来像这样：

最常见的互动是：

浏览器与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包含进来。

github地址