HTTP是无状态的。为了授权您，您必须对发送给服务器的每个请求进行“签名”。

令牌身份验证

• 向服务器发出的请求由“令牌”签名-通常意味着设置特定的HTTP头，但是，它们可以在HTTP请求的任何部分（POST正文等）中发送
• 优点：
• 您只能授权希望授权的请求。（cookie—甚至授权cookie也会针对每个请求发送。）
• 对XSRF免疫（XSRF的简短示例-我将在电子邮件中向您发送一个类似<img src="http://bank.example?withdraw=1000&to=myself" />的链接，如果您通过cookie身份验证登录到e1d1e，而bank.example没有任何XSRF保护手段，我将从您的帐户中取款，只需您的浏览器将触发对该url的授权GET请求即可。)请注意，基于cookie的身份验证可以采取一些防伪措施，但必须实现这些措施。
• Cookie绑定到单个域。在域foo.example上创建的cookie不能被域e1d 4d1e读取，而您可以向任何您喜欢的域发送令牌。这对于使用多个需要授权的服务的单页应用程序特别有用，因此我可以在域myapp.example上拥有一个web应用程序，它可以向myservice1.example和myservice2.example发出授权的客户端请求。
• 缺点：
• 你必须把代币存放在某处；而cookie是“现成”存储的。想到的位置是localStorage（con：即使关闭浏览器窗口，令牌也会被持久化），sessionStorage（pro：关闭浏览器窗口后将丢弃令牌，con：在新选项卡中打开链接将使该选项卡匿名）和cookie（赞成：关闭浏览器窗口后，令牌将被丢弃。如果您使用会话cookie，则在新选项卡中打开链接时将对您进行身份验证，并且您对XSRF免疫，因为您忽略了用于身份验证的cookie，您只是将其用作令牌存储。反对：每个请求都会发送cookie。如果此cookie未标记为https，则您对中间人开放攻击。）
• 对基于令牌的身份验证进行XSS攻击稍微容易一些（即，如果我能够在您的站点上运行注入的脚本，我可以窃取您的令牌；但是，基于cookie的身份验证也不是万能的-虽然客户端无法读取标记为http的cookie，但客户端仍然可以代表您发出请求，请求将自动包含授权cookie。）
• 请求下载一个只对授权用户有效的文件，需要您使用文件API。对于基于cookie的身份验证，同样的请求是现成的。
  Cookie身份验证
• 对服务器的请求总是由授权cookie登录。
• 优点：
• Cookie可以标记为“仅http”，这样就无法在客户端读取。这对XSS攻击保护更好。
• 开箱即用—您不必在客户端实现任何代码。
• 缺点：
• 绑定到单个域。（因此，如果您有一个向多个服务发出请求的单页应用程序，那么您最终可能会做一些疯狂的事情，比如反向代理。）
• 易受XSRF攻击。你必须实施额外的措施，使你的网站免受跨站点请求伪造的影响。
• 每一个请求都会被发送出去（即使是不需要身份验证的请求）。

总的来说，我认为令牌给了您更好的灵活性（因为您不必绑定到单个域）。缺点是你必须自己编写一些代码。

对于谷歌用户：

• 请勿将状态与状态传输机制混合使用
  状态FULNESS
  *有状态=在服务器端保存授权信息，这是传统方式
  *无状态=在客户端保存授权信息，以及签名以确保完整性
  机制
  *Cookie=浏览器具有特殊处理（访问、存储、过期、安全、自动传输）的特殊头
  *自定义头=例如Authorization，只是没有任何特殊处理的头，客户必须管理传输的所有方面
  *其他。可以使用其他传输机制，例如，查询字符串暂时是传输身份验证ID的选择，但由于其不安全性而被放弃
  状态模糊度比较
• “状态授权”是指服务器在服务器上存储和维护用户授权信息，使授权成为应用程序状态的一部分
• 这意味着客户端只需要保留“身份验证ID”，服务器可以从其数据库中读取身份验证详细信息
• 这意味着服务器保留一个活动身份验证池（登录的用户），并将为每个请求查询此信息
• “无状态授权”意味着服务器不存储和维护用户身份验证信息，它只是不知道哪些用户已登录，并依赖客户端生成身份验证信息
• 客户端将存储完整的身份验证信息，如您是谁（用户ID），以及可能的权限、过期时间等，这不仅仅是身份验证ID，因此会给它一个新的名称令牌
• 显然客户端不可信，因此身份验证数据与从hash(data + secret key)生成的签名一起存储，其中密钥只有服务器知道，因此可以验证令牌数据的完整性
• 请注意，令牌机制只是确保完整性，而不是机密性，客户端必须实现
• 这还意味着对于每个请求，客户端都必须提交一个完整的令牌，这会增加额外的带宽
  机制比较
• “Cookie”只是一个标题，但在浏览器上有一些预加载的操作
• Cookie可以由服务器设置，由客户端自动保存，并将自动发送到同一域
• Cookie可以标记为httpOnly，从而阻止客户端JavaScript访问
• 预加载操作可能无法在浏览器以外的平台上使用（例如手机），这可能会导致额外的工作
• “自定义标题”只是没有预加载操作的自定义标题
• 客户端负责接收、存储、保护、提交和更新每个请求的自定义标头部分，这可能有助于防止一些简单的恶意URL嵌入
  总和
• 没有魔法，身份验证状态必须存储在某个地方，无论是服务器还是客户端
• 您可以使用cookie或其他自定义头实现有状态/无状态
• 当人们谈论这些事情时，他们的默认心态主要是：无状态=令牌+自定义头，有状态=身份验证ID+cookie；这些不是唯一可能的选择
• 它们有优缺点，但即使是加密令牌，也不应存储敏感信息

典型的web应用程序大多是无状态，因为它的请求/响应性质。HTTP协议是无状态协议的最佳示例。但是，由于大多数web应用程序需要状态，为了在服务器和客户端之间保持状态，使用了cookie，以便服务器可以在每次响应中向客户端发送cookie。这意味着客户端发出的下一个请求将包含此cookie，因此服务器将识别它。这样，服务器可以与无状态客户端维护会话**，了解应用程序状态的所有信息，但存储在服务器中。在这个场景中，客户端在任何时候都不会持有状态，这不是Ember.js的工作方式。
在Ember。js的东西是不同的。ember.js使程序员的工作更容易，因为它确实为您保存了客户端中的状态，随时了解其状态，而无需向服务器请求状态数据。
然而，在客户机中保持状态有时也会带来无状态情况下根本不存在的并发问题。ember然而，js也为您处理这些问题；特别是ember数据是基于这一点构建的。总之，Ember。js是为有状态客户机设计的框架。
ember.js不像典型的无状态web应用程序那样工作，在这种应用程序中，会话、状态和相应的cookie几乎完全由服务器处理。ember.js将其状态完全保存在Javascript中（在客户端内存中，而不像其他一些框架那样保存在DOM中），并且不需要服务器来管理会话。这会产生Ember。js在许多情况下都更加通用，例如当你的应用程序处于离线模式时。
显然，出于安全原因，每次发出请求时，都需要向服务器发送某种令牌或唯一密钥，以便进行身份验证。这样，服务器可以查找发送令牌（最初由服务器发出），并在向客户端发送响应之前验证它是否有效。
在我看来，使用身份验证令牌而不是Ember Auth FAQ中所述的cookie的主要原因主要是因为Ember的性质。js框架，也因为它更适合有状态的web应用范例。因此，在构建Ember时，cookie机制并不是最好的方法。js应用程序。
我希望我的回答能使你的问题更有意义。

• 令牌需要存储在某处（本地/会话存储或cookie）
• 令牌可以像cookie一样过期，但您有更多的控制权
• 本地/会话存储无法跨域工作，请使用标记cookie
• 每个CORS请求都将发送飞行前请求
• 当您需要流式传输内容时，使用令牌获取签名请求
• 处理XSS比处理XSRF更容易
• 每次请求都会发送令牌，注意其大小
• 如果您存储机密信息，请加密令牌
• JSON Web令牌可以在OAuth中使用
• 令牌不是万能的，请仔细考虑您的授权用例

http://blog.auth0.com/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/
http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/

我认为这里有些混乱。基于cookie的身份验证与现在使用HTML5 Web Storage所能实现的身份验证之间的显著区别在于，浏览器构建为在向设置它们的域请求资源时发送cookie数据。如果不关闭cookie，就无法阻止这种情况。浏览器不会从Web存储发送数据，除非页面中的代码发送数据。并且页面只能访问它们存储的数据，而不能访问其他页面存储的数据。
因此，用户担心他们的cookie数据可能被谷歌或Facebook使用，可能会关闭cookie。但是，他们没有太多理由关闭Web存储（除非广告商也想出了使用它的方法）。
因此，这就是基于cookie和基于令牌的区别，后者使用Web存储。

基于令牌的身份验证是无状态的，服务器不需要在会话中存储用户信息。这使得能够扩展应用程序，而不必担心用户登录的位置。基于cookie的web Server Framework具有亲和力，而基于令牌的则没有这个问题。因此，可以使用相同的令牌从我们登录的域以外的域中获取安全资源，这样可以避免另一个uid/pwd身份验证。
这里有一篇很好的文章：
http://www.toptal.com/web/cookie-free-authentication-with-json-web-tokens-an-example-in-laravel-and-angularjs

在以下情况下使用令牌。。。
需要联合。例如，您希望使用一个提供者（Token Dispensor）作为令牌颁发者，然后使用您的api服务器作为令牌验证器。应用程序可以向令牌分发器进行身份验证，接收令牌，然后将该令牌提供给您的api服务器进行验证。（同样适用于Google Sign-In.或Paypal.或Salesforce.com等）
需要异步。例如，您希望客户机发送一个请求，然后将该请求存储在某个地方，以便“稍后”由单独的系统执行。该单独的系统将不会与客户端同步连接，也可能不会与中央代币药房直接连接。异步处理系统可以读取JWT，以确定工作项是否可以并且应该在稍后的时间完成。这在某种程度上与上面的联邦思想有关。不过，这里要小心：JWT过期。如果持有工作项的队列在JWT的生命周期内没有得到处理，那么声明就不再可信。
需要Cient Signed请求。这里，请求由客户机使用其私钥签名，服务器将使用客户机已注册的公钥进行验证。

主要区别之一是cookie受同源策略的约束，而令牌则不受此约束。这会产生各种下游效果。
由于cookie仅发送到特定主机或从特定主机发送，因此主机必须承担对用户进行身份验证的责任，并且用户必须使用该主机的安全数据创建帐户，以便进行验证。
另一方面，代币是发行的，不受同源政策的约束。发行人可以是任何人，由主办方决定信任哪些发行人。像谷歌和Facebook这样的发行人通常都很受信任，因此主机可以将用户身份验证的负担（包括存储所有用户安全数据）转移给另一方，用户可以将其个人数据整合到特定的发行人下，而无需记住与之交互的每个主机的一系列不同密码。
这允许单点登录场景，以减少用户体验中的总体摩擦。理论上，随着专业身份提供者的出现，网络也变得更加安全，他们提供身份验证服务，而不是让每个ma和pa网站都建立自己的身份验证系统（可能还不够成熟）。随着这些提供商的出现，为甚至是非常基本的资源提供安全网络资源的成本也趋于零。
因此，一般来说，令牌减少了与提供身份验证相关的摩擦和成本，并将安全web各个方面的负担转移给了能够更好地实施和维护安全系统的集中方。

简而言之：

JWT vs Cookie Auth

|                    | Cookie        | JWT                             |
| Stateless          | No            | Yes                             |
| Cross domain usage | No            | Yes                             |
| Mobile ready       | No            | Yes                             |
| Performance        | Low           | High (no need in request to DB) |
| Add to request     | Automatically | Manually (if not in cookie)     |