现代的应用程序看起来像这样:

典型的交互操作包括：

• 浏览器与 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 验证服务器。

IdentityServer 的安全模型基于两个基本原语： 客户端和作用域：

客户端

客户端是请求访问IdentityServer或身份令牌的软件。客户可以是不同类型的应用：桌面或移动的，基于浏览器的或基于服务器的应用。OpenID 连接和 OAuth2 描述 （也称为流程）不同客户端如何请求令牌模式。检查的规格为有关流程的详细信息。

默认情况下，客户端可以请求在 IdentityServer-中定义的任何作用域，但您可以限制每个客户端可以请求的作用域。

作用域

作用域是一个资源 （通常也称为 Web API） 的标识符。你可以如范围被称为"日历"为您创建日历 API — — 或"calendar.readonly"如果你想要将您的日历的 API 分割成子"地区"-在这种情况下只读访问权限。

如果允许，此作用域将会包括作为访问令牌中的索赔与客户端然后可以请求如"日历"范围-的标记。然后可以确定范围是目前验证的访问令牌时日历 API （或资源）。

根据流程和配置，请求作用域将显示给用户之前颁发的令牌。这使用户有机会来允许或拒绝访问该服务。这就被所谓的同意。

OpenID 连接的作用域有点特殊。它们定义一个可以要求用户的身份信息和用户信息终结点。每一个 OpenID 连接作用域有关联的声明，如"Profile" 作用域映射到的名字、 姓氏、 性别、 个人资料图片和更多。

IdentityServer 既支持"资源"的作用域，也支持 OpenID 连接作用域。

理解OAuth 2.0

Thinktecture IdentityServer and CodeFluent Entities

基于Token的认证和基于声明的标识

Thinktecture Identity Server 3

Identity Server 3 Standalone Implementation Part 1

Identity Server 3 Standalone Implementation Part 2

Identity Server 3 Standalone Implementation Part 3