身份验证cookies和Token

后端服务器有两种基本的身份验证：
1.是基于Cookie的身份验证，使用服务器端的cookie来对每次请求的用户进行身份验证。
2. 较新的方法，基于令牌Token的认证，依赖于被发送到服务器上每个请求的签署令牌。

token的优势

1.跨域 / CORS: cookies并不能跨不同的域名:abc.com和xy.abc.com的cookies是不能共享的,索性这种一级二级域名是可以通过

设置Cookie的SetDomain参数(例如:cookies.setDomain(".abc.com"))来共享cookies.但是abc.com和xy.com是不能相互获取cookies的.而基于令牌能够使用 AJAX 调用服务器，在任何域名下你都可以使用HTTP header头部来传输用户信息。

2. 无态(代表服务器端可伸缩): 没有必要将会话保存，令牌 token 自己是一个自我包容的实体，包含用户各种信息，其他状态信息可以保存在cookie或客户端本地存储器中

3.CDN: 能够适用来自CDN任何应用部件(e.g. javascript, HTML, images, etc.), 你的服务器只是一个 API.

4.解耦: 你不必和一个特定的验证格式Schema绑定，令牌token 能在任何地方产生，这样的你的API可以在任何地方以同一种验证方式调用验证。

5.对移动Mobile友善: 当你在一个原生平台(iOS, Android, Windows 8, etc.)时， cookies依赖于一个安全API，并不是好主意，因为你得和一个cookie容器打交道，而基于令牌则简单多。

6.CSRF: 因为你不依赖cookies, 你就不需要跨请求保护，(e.g. it 有可能来自 <iframe> 请求一个POST，需要重用一个存在的验证。).

6.性能:一个网络往返（如发现在数据库中的会话）可能会比计算的HMACSHA256验证令牌耗费更多时间。

7.登录页面不是一个特殊情况，如果你如果您正在使用量角器来写你的功能测试，你不需要来处理登录的任何特殊情况。

8.基于标准: 你的API能接受一个标准的 JSON Web Token (JWT). 这个标准后面有多个库包(.NET, Ruby, Java, Python, PHP)，许多公司支持(e.g. Firebase, Google, Microsoft). ，比如Firebase允许他们的客户使用任何身份验证机制，只要你使用预先定义的属性生成一个 JWT，并使用共享密钥签署，就能调用它们的API.

基于Token的验证原理

基于Token的身份验证是无状态的，我们不将用户信息存在服务器或Session中。

这种概念解决了在服务端存储信息时的许多问题

NoSession意味着你的程序可以根据需要去增减机器，而不用去担心用户是否登录。

基于Token的身份验证的过程如下:

1.用户通过用户名和密码发送请求。

2.程序验证。

3.程序返回一个签名的token 给客户端。

4.客户端储存token,并且每次用于每次发送请求。

5.服务端验证token并返回数据。

 每一次请求都需要token。token应该在HTTP的头部发送从而保证了Http请求无状态。我们同样通过设置服务器属性Access-Control-Allow-Origin:* ，让服务器能接受到来自所有域的请求。需要主要的是，在ACAO头部标明(designating)*时，不得带有像HTTP认证，客户端SSL证书和cookies的证书。