上一篇我们介绍了如何使用vue resource处理HTTP请求，结合服务端的REST API，就能够很容易地构建一个增删查改应用。
这个应用始终遗留了一个问题，Web App在访问REST API时，没有经过任何认证，这使得服务端的REST API是不安全的，只要有人知道api地址，就可以调用API对服务端的资源进行修改和删除。
今天我们就来探讨一下如何结合Web API来限制资源的访问。
本文的主要内容如下：
介绍传统的Web应用和基于REST服务的Web应用
介绍OAuth认证流程和密码模式
创建一个基于ASP.NET Identity的Web API应用程序
基于$.ajax实现OAuth的注册、登录、注销和API调用
基于vue-resource实现OAuth的注册、登录、注销和API调用
本文的最终示例是结合上一篇的CURD，本文的登录、注册、注销和API调用功能实现的。
本文9个示例的源码已放到GitHub：https://github.com/keepfool/vue-tutorials/tree/master/04.OAuth
OAuth介绍
传统的Web应用
在传统的Web应用程序中，前后端是放在一个站点下的，我们可以通过会话（Session）来保存用户的信息。
例如：一个简单的ASP.NET MVC应用程序，用户登录成功后，我们将用户的ID记录在Session中，假设为Session["UserID"]。
前端发送ajax请求时，如果这个请求要求已登录的用户才能访问，我们只需在后台Controller中验证Session["UserID"]是否为空，就可以判断用户是否已经登录了。
这也是传统的Web应用能够逃避HTTP面向无连接的方法。
基于REST服务的Web应用
当今很多应用，客户端和服务端是分离的，服务端是基于REST风格构建的一套Service，客户端是第三方的Web应用，客户端通过跨域的ajax请求获取REST服务的资源。
然而REST Service通常是被设计为无状态的（Stateless），这意味着我们不能依赖于Session来保存用户信息，也不能使用Session["UserID"]这种方式确定用户身份。
解决这个问题的方法是什么呢？常规的方法是使用OAuth 2.0。
对于用户相关的OpenAPI，为了保护用户数据的安全和隐私，第三方Web应用访问用户数据前都需要显式的向用户征求授权。
相比于OAuth 1.0，OAuth 2.0的认证流程更加简单。
专用名词介绍
在了解OAuth 2.0之前，我们先了解几个名词：
Resource：资源，和REST中的资源概念一致，有些资源是访问受保护的
Resource Server：存放资源的服务器
Resource Owner：资源所有者，本文中又称为用户(user)
User Agent：用户代理，即浏览器
Client： 访问资源的客户端，也就是应用程序
Authorization Server：认证服务器，用于给Client提供访问令牌的服务器
Access Token：访问资源的令牌，由Authorization Server器授予，Client访问Resource时，需提供Access Token
Bearer Token：Bearer Token是Access Token的一种，另一种是Mac Token。
Bearer Token的使用格式为：Bearer XXXXXXXX
Token的类型请参考：
有时候认证服务器和资源服务器可以是一台服务器，本文中的Web API示例正是这种运用场景。
OAuth认证流程
在知道这几个词以后，我们用这几个名词来编个故事。
简化版本
这个故事的简化版本是：用户(Resource Owner)访问资源(Resource)。
具体版本
简化版的故事只有一个结果，下面是这个故事的具体版本：
用户通过浏览器打开客户端后，客户端要求用户给予授权。
客户端可以直接将授权请求发给用户（如图所示），或者发送给一个中间媒介，比如认证服务器。
用户同意给予客户端授权，客户端收到用户的授权。
授权模式(Grant Type)取决于客户端使用的模式，以及认证服务器所支持的模式。
客户端提供身份信息，然后向认证服务器发送请求，申请访问令牌
认证服务器验证客户端提供的身份信息，如果验证通过，则向客户端发放令牌
客户端使用访问令牌，向资源服务器请求受保护的资源
资源服务器验证访问令牌，如果有效，则向客户端开放资源
