来看应用部署示意图

当下多数应用都是图示这样的结构

最常见的几种交互形式如下:

  • 浏览器 与 Web应用程序之间的通讯;
  • Web应用程序 与 Web API 之间的通讯(Web应用程序自身 或 代表用户 与 Web API 通信);
  • 基于浏览器的应用程序 与 Web API 通讯;
  • 本地应用程序 与 Web API 通讯;
  • 基于服务器的应用程序 与 Web API 通讯;
  • Web API 与 Web API 通讯(WebAPI自身 或 代表用户与另一个WebAPI 通讯);

前端、中间层、后端各个层级为了保护资源经常要针对相同的用户仓储去实现身份认证和授权。

但是如果我们把这些基本的安全功能统一颁发给一个安全令牌服务,就可以不必再让这些应用和端点之间重复实现这些基础安全功能。

重组这些应用使让他们都支持安全令牌服务,就会引导出如下的体系结构和协议:

 

这样就把安全问题拆分成两个部分:

身份认证

当应用程序需要获取当前用户的身份就需要通过身份认证。通常这些应用管理着用户的数据,并且确保用户只能访问到这些被授权的数据。最常见的例子就是传统的web应用程序 —— 但是本地应用程序和基于JS的应用程序也同样需要身份认证。

最常见的身份认证协议是 SAML2p、WS-Federation 和 OpenID Connect——SAML2p 是最受欢迎的,也是部署得最广泛的。

OpenID Connect 是三种协议中最新的一种,它将是未来的发展趋势,因为它对于现代应用程序来说最具潜力。它从一开始就是为移动应用场景而生,并且被设计成了非常友好的API接口。

 

API访问控制

应用程序有两种基本方式与API进行通信,一种是使用应用程序标识,另一种是委托用户的身份。有时这两种方法都需要结合。

OAuth2协议,它允许应用程序从一个安全令牌服务要求访问令牌,使用这个访问令牌来访问API。这个机制降低了客户机应用程序和API的复杂性,因为身份验证和授权可以是集中式的。

OpenID Connect和OAuth2 —— 结合使用更好

OpenID Connect和OAuth2非常相似 —— 实际上前者是后者的顶级扩展。它们把两个基础安全问题(身份认证和 API 访问)合并成了一个单一的协议 —— 通常这只是与安全令牌服务的一个往返交互。

我们坚信,将 OpenID Connect 和 OAuth2 结合以保护现代应用程序,在可预见的未来,肯定会是最佳实践。IdentityServer4 是这两种协议的实现,并且它已经被高度优化以解决当今 移动应用程序、本地应用程序 和 Web应用程序 的典型安全问题。

IdentityServer4可以帮助你做什么

IdentityServer是将规范兼容的OpenID Connect和OAuth 2.0端点添加到任意ASP.NET Core应用程序的中间件。通常,您构建(或重新使用)包含登录和注销页面的应用程序,IdentityServer中间件会向其添加必要的协议头,以便客户端应用程序可以与其对话 使用这些标准协议。

 

你可以根据你的需要使用尽可能复杂的宿主应用程序。但是,为了保持受攻击面尽可能小, 我们一般建议你只将认证相关的UI包含进来。