入门教程：.NET开源OpenID Connect 和OAuth解决方案IdentityServer v3 介绍 （一）

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

典型的交互操做包括：

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