整体结构
现代程序的架构基本如下:
典型的交互包括:
浏览器和web应用程序通信
Web应用程序和WebApi通信(有时使用系统权限，有时代理使用登陆用户权限)
基于浏览器应用程序和WebAPI交互
原生程序和Web API交互
服务器端程序和WebAPI交互
Web APIs 之间互相交互(有时使用系统权限，有时代理使用登陆用户权限)
一般来说，每一层（前端，中间层，后端）都需要实现认证和授权来保护关键资源，大部分会基于同样的用户信息。所以我们不会在业务层实现这些基础的权限功能，而是把这些关键功能放到一个服务中去---安全令牌服务。
采用了安全令牌服务和对应的协议后，架构就变成下面的样子:
这种架构把安全问题分成两部分:
认证
认证是确定当前访问应用的用户是谁，一般来说，应用程序是替用户来保管数据，应该让用户只可以访问他/她被允许访问的数据。最常见的例子是web应用程序，但是原生程序，基于JS程序同样需要认证。
常见认证协议包括SAML2p,WS-Federation和OpenID Connect--SAML2p是最流行和应用最广的协议。
OpenID Connect是三个协议中最新，一般认为它最有潜力成为未来主导的认证协议，它在设计时，就完全考虑了移动应用场景，也被设计成API友好。
API 访问
应用程序和API之间有两种主要的认证方式--使用系统账号或者代理用户的身份。有时候会两种方式混合使用。
OAuth2是一个授权协议，允许应用程序从安全令牌服务得到一个访问令牌，然后用访问令牌和API通信。这样可以降低应用和API实现的复杂度，因为认证和授权都被集中到了安全令牌服务了，应用程序和API可以专注于业务逻辑。
OpenID Connect 和 OAuth2 – 天作之合
OpenID Connect和OAuth2非常相似 – 事实上，OPenID Connect是在OAuth2之上的一个扩展。
这意味着我们能够把认证和API访问合并到一个协议中--只需要一次来回就可以从安全令牌服务中得到所需要的信息。
这就是为什么，我们相信把OpenID Connect和OAuth2合在一起保护现代应用程序，是可预见未来的最好的方式。IdentityServer3实现了这两个协议，并针对当今的移动，原生，Web应用程序典型的俺去问题，进行了大量优化。
