The Big Picture

大多数现代应用看起来都像下面的样子：

大多数的交互是下面这样：

通常每一层（前端的，中间层，后端的）都必须保护资源并实现认证和/或授权。而且都是针对同一个用户的存储来说。（实际上就是单点登录）

将这些基本安全功能外包给安全令牌服务（jwt），可以防止在这些应用程序和端点之间复制该功能。

重组应用以支持安全令牌服务会引入以下架构和协议：

注意这张图解释了上面大部分提到的术语，web应用，web APIs，等等。如果对上面属于有疑问的可以看这张图。

这样的设计将安全问题分为两个部分：

认证

当一个应用需要知道当前用户的身份时，认证这个东西就派上用场了。通常这些应用代表用户管理数据并且需要确保只处理当前用户被允许的数据。（使用这个）最普遍的例子是web应用，但是原生app和基于js的应用（angular、vue等这些大前端）同样需要认证。

最常见的认证协议包括SAMS2p，WS-Federation和OpenID Connect，SAMS2p是目前最流行的，并且应用最广泛的。

OpenID Connect是这里面提到的最新的，并且也被各大厂商认为是代表了未来的协议，因为它赋予了现代的应用最大的潜能。他从开始就考虑了移动应用的场景，并且对于API来说也是友好的。

应用有两个基本的途径来访问APIs--将应用本身作为身份标识（没有用户参与）。或者通过用户的身份标识（有用户参与）。有时这两个途径需要结合使用。

OAuth2是一个允许应用从安全令牌服务中请求access token的协议。然后，应用使用这个access token来和APIs交互。它（指安全令牌服务）减少了客户端应用程序和apis之间通信的复杂性，因为身份验证和授权可以集中处理。

OPenID Connec和OAuth2.0很像，实际上前者是后者的一个顶层的扩展。认证和访问API这两个基本的安全关注点被集中到了一个协议中，经常在安全令牌服务中进行一次往返。

我们相信在可预知的未来OpenID Connect和OAuth2.0的结合是保护现代应用最好的方案。IdentityServer4是对这两个协议的一个实现，并且经过高度的优化，以解决当今的移动应用、原生和web应用中的安全问题。

IdentityServer是一个中间件，它将兼容OpenID Connect和OAuth2.0的端点添加到任意的一个Asp.net core上面去。

通常情况下，你会创建（或者重用）一个包含登陆、登出页面（或许还有确认consen页面，这依赖于你的需求）的应用，并且IdentityServer中间件将一些必要的协议头添加到这个应用的上面，所以客户端应用可以使用这些标准的协议来与之交互。

宿主应用可以如你所愿很复杂，但是我们通常会推荐你的宿主应用应该只包含认证相关的UI来使你的受攻击面尽可能的减小。