现代的应用程序看起来像这样:
典型的交互操作包括:
- 浏览器与 web 应用程序进行通信
- Web 应用程序与 web Api (有时是在他们自己的有时代表用户) 通信
- 基于浏览器的应用程序与 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解决跨站点的认证问题,OAuth解决跨站点的授权问题。认证和授权是密不可分的。而OpenID和OAuth这两套协议出自两个不同的组织,协议上有相似和重合的之处,所以想将二者整合有些难度。好在OpenID Connect作为OpenID的下一版本,在OAuth 2.0的协议基础上进行扩展,很好的解决了认证和授权的统一,给开发者带来的便利。Thinktecture IdentityServer v3 是一个.NET 平台上开源的OpenID Connect 提供者 和 OAuth2 验证服务器。