A typical web app is mostly stateless, because of its request/response nature. The HTTP protocol is the best example of a stateless protocol. But since most web apps need state, in order to hold the state between server and client, cookies are used such that the server can send a cookie in every response back to the client. This means the next request made from the client will include this cookie and will thus be recognized by the server. This way the server can maintain a session with the stateless client, knowing mostly everything about the app's state, but stored in the server. In this scenario at no moment does the client hold state, which is not how Ember.js works.

在Ember.js中情况有所不同。Ember.js使程序员的工作变得更容易，因为它确实在客户端为您保存了状态，可以随时了解其状态，而不必向服务器请求状态数据。

然而，在客户端保存状态有时也会引入在无状态情况下不存在的并发问题。然而，Ember.js也为您处理这些问题;具体地说，ember-data是基于这一点构建的。总之，Ember.js是为有状态客户端设计的框架。

Ember.js不像典型的无状态web应用程序那样，会话、状态和相应的cookie几乎完全由服务器处理。Ember.js将其状态完全保存在Javascript中(在客户端的内存中，而不是像其他框架那样在DOM中)，并且不需要服务器来管理会话。这导致Ember.js在许多情况下更加通用，例如当你的应用程序处于离线模式时。

显然，出于安全原因，每次发出请求时都需要向服务器发送某种令牌或唯一密钥，以便进行身份验证。通过这种方式，服务器可以查找发送令牌(最初由服务器发出)，并在将响应发送回客户端之前验证它是否有效。

在我看来，使用认证令牌而不是在Ember Auth FAQ中所述的cookie的主要原因是Ember.js框架的性质，也因为它更适合有状态的web应用程序范例。因此，cookie机制并不是构建Ember.js应用程序的最佳方法。

我希望我的回答能让你的问题更有意义。

我认为这里有些混乱。基于cookie的身份验证与HTML5 Web Storage之间的显著区别在于，浏览器被构建为每当从设置它们的域请求资源时都发送cookie数据。如果不关掉cookie，你无法阻止这种情况。除非页面中的代码发送数据，否则浏览器不会从Web存储发送数据。页面只能访问自己存储的数据，而不能访问其他页面存储的数据。

因此，如果用户担心自己的cookie数据可能被谷歌或Facebook使用，可能会关闭cookie。但是，他们没有理由关闭网络存储(直到广告商也找到一种方法来使用它)。

所以，这就是基于cookie和基于令牌的区别，后者使用Web存储。

Tokens need to be stored somewhere (local/session storage or cookies) Tokens can expire like cookies, but you have more control Local/session storage won't work across domains, use a marker cookie Preflight requests will be sent on each CORS request When you need to stream something, use the token to get a signed request It's easier to deal with XSS than XSRF The token gets sent on every request, watch out its size If you store confidential info, encrypt the token JSON Web Tokens can be used in OAuth Tokens are not silver bullets, think about your authorization use cases carefully

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/

基于令牌的认证是无状态的，服务器不需要在会话中存储用户信息。这样就可以扩展应用程序，而不用担心用户已经登录到哪里。有web服务器框架的亲缘性基于cookie，而这不是一个问题，基于令牌。因此，可以使用相同的令牌从我们登录的域以外的域获取安全资源，从而避免了另一个uid/pwd身份验证。

非常好的文章:

http://www.toptal.com/web/cookie-free-authentication-with-json-web-tokens-an-example-in-laravel-and-angularjs

HTTP无状态。为了授权你，你必须“签署”你发送到服务器的每一个请求。

令牌验证

A request to the server is signed by a "token" - usually it means setting specific HTTP headers, however, they can be sent in any part of the HTTP request (POST body, etc.) Pros: You can authorize only the requests you wish to authorize. (Cookies - even the authorization cookie are sent for every single request.) Immune to XSRF (Short example of XSRF - I'll send you a link in email that will look like <img src="http://bank.example?withdraw=1000&to=myself" />, and if you're logged in via cookie authentication to bank.example, and bank.example doesn't have any means of XSRF protection, I'll withdraw money from your account simply by the fact that your browser will trigger an authorized GET request to that url.) Note there are anti forgery measure you can do with cookie-based authentication - but you have to implement those. Cookies are bound to a single domain. A cookie created on the domain foo.example can't be read by the domain bar.example, while you can send tokens to any domain you like. This is especially useful for single page applications that are consuming multiple services that are requiring authorization - so I can have a web app on the domain myapp.example that can make authorized client-side requests to myservice1.example and to myservice2.example. Cons: You have to store the token somewhere; while cookies are stored "out of the box". The locations that comes to mind are localStorage (con: the token is persisted even after you close browser window), sessionStorage (pro: the token is discarded after you close browser window, con: opening a link in a new tab will render that tab anonymous) and cookies (Pro: the token is discarded after you close the browser window. If you use a session cookie you will be authenticated when opening a link in a new tab, and you're immune to XSRF since you're ignoring the cookie for authentication, you're just using it as token storage. Con: cookies are sent out for every single request. If this cookie is not marked as https only, you're open to man in the middle attacks.) It is slightly easier to do XSS attack against token based authentication (i.e. if I'm able to run an injected script on your site, I can steal your token; however, cookie based authentication is not a silver bullet either - while cookies marked as http-only can't be read by the client, the client can still make requests on your behalf that will automatically include the authorization cookie.) Requests to download a file, which is supposed to work only for authorized users, requires you to use File API. The same request works out of the box for cookie-based authentication.

Cookie验证

A request to the server is always signed in by authorization cookie. Pros: Cookies can be marked as "http-only" which makes them impossible to be read on the client side. This is better for XSS-attack protection. Comes out of the box - you don't have to implement any code on the client side. Cons: Bound to a single domain. (So if you have a single page application that makes requests to multiple services, you can end up doing crazy stuff like a reverse proxy.) Vulnerable to XSRF. You have to implement extra measures to make your site protected against cross site request forgery. Are sent out for every single request, (even for requests that don't require authentication).

总的来说，我认为令牌给了您更好的灵活性(因为您不局限于单个域)。缺点是你必须自己编写一些代码。

一个主要的区别是cookie服从同源策略，而令牌则不是。这就产生了各种各样的下游效应。

由于cookie只发送给特定的主机，该主机必须承担验证用户身份的责任，用户必须在该主机上创建一个具有安全数据的帐户，以便进行验证。

Tokens on the other hand are issued and are not subject to same origin policy. The issuer can be literally anybody and it is up to the host to decide which issuers to trust. An issuer like Google and Facebook is typically well trusted so a host can shift the burden of authenticating the user (including storing all user security data) to another party and the user can consolidate their personal data under a specific issuer and not have to remember a bunch of different passwords for each host they interact with.

这允许单点登录场景，从而减少用户体验中的整体摩擦。从理论上讲，网络也变得更加安全，因为专门的身份提供者出现了，提供认证服务，而不是每个ma和pa网站都有自己的，可能不成熟的认证系统。随着这些提供商的出现，为非常基本的资源提供安全网络资源的成本也趋向于零。

因此，总的来说，令牌减少了与提供身份验证相关的摩擦和成本，并将安全web各个方面的负担转移到能够更好地实现和维护安全系统的中心化方。

使用Token时…

需要联邦。例如，您希望使用一个提供者(令牌分发器)作为令牌颁发者，然后使用api服务器作为令牌验证器。应用程序可以向令牌分发器进行身份验证，接收令牌，然后将该令牌提交给api服务器进行验证。(同样适用于谷歌登录。或贝宝。或Salesforce.com。等)

Asynchrony is required. For example, you want the client to send in a request, and then store that request somewhere, to be acted on by a separate system "later". That separate system will not have a synchronous connection to the client, and it may not have a direct connection to a central token dispensary. a JWT can be read by the asynchronous processing system to determine whether the work item can and should be fulfilled at that later time. This is, in a way, related to the Federation idea above. Be careful here, though: JWT expire. If the queue holding the work item does not get processed within the lifetime of the JWT, then the claims should no longer be trusted.

客户需要签署请求。在这里，请求由客户端使用他的私钥签署，服务器将使用客户端已经注册的公钥进行验证。

因为谷歌员工:

不要将状态性与状态传输机制混合在一起

有状态性

有状态=在服务器端保存授权信息，这是传统的方式 无状态=在客户端保存授权信息，以及签名以确保完整性

机制

Cookie =浏览器对其进行特殊处理(访问、存储、过期、安全、自动传输)的特殊标头 自定义报头=例如，授权，只是没有任何特殊处理的报头，客户端必须管理传输的所有方面 其他。可以利用其他传输机制，例如查询字符串是一种暂时传输身份验证ID的选择，但由于其不安全性而被放弃

有状态性比较

"Stateful authorization" means the server stores and maintains user authorization info on server, making authorizations part of the application state This means client only need to keep an "auth ID" and the server can read auth detail from its database This implies that server keeps a pool of active auths (users that are logged in) and will query this info for every request "Stateless authorization" means the server does not store and maintain user auth info, it simply does not know which users are signed in, and rely on the client to produce auth info Client will store complete auth info like who you are (user ID), and possibly permissions, expiration time, etc., this is more than just auth ID, so it is given a new name token Obviously client cannot be trusted, so auth data is stored along with a signature generated from hash(data + secret key), where secret key is only known to server, so the integrity of token data can be verified Note that token mechanism merely ensures integrity, but not confidentiality, client has to implement that This also means for every request client has to submit a complete token, which incurs extra bandwidth

机制比较

"Cookie" is just a header, but with some preloaded operations on browsers Cookie can be set by server and auto-saved by client, and will auto-send for same domain Cookie can be marked as httpOnly thus prevent client JavaScript access Preloaded operations may not be available on platforms other than browsers (e.g. mobile), which may lead to extra efforts "Custom headers" are just custom headers without preloaded operations Client is responsible to receive, store, secure, submit and update the custom header section for each requests, this may help prevent some simple malicious URL embedding

总结

没有魔法，认证状态必须存储在某个地方，要么在服务器或客户端 您可以使用cookie或其他自定义头文件实现有状态/无状态 当人们谈论这些事情时，他们的默认心态大多是:无状态=令牌+自定义头，有状态=认证ID + cookie;这些并不是唯一可能的选择 它们有利有弊，但即使是加密的令牌，也不应该存储敏感信息

简而言之:

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)     |

cookie依赖于您与另一端存储您已登录事实的数据库共享的个人秘密。这里没有什么特别的东西，只是一个密码短语来识别您的会话，尽管细节可能有所不同。

认证令牌使用奇特的加密技术来消除对存储登录状态的数据库的需求，方法是通过给定提供者的签名发布一个文档，其中包含允许您在哪个日期之前做什么。

打个比方，cookie就像一张会员卡，检查它的前台必须打电话或查询数据库来检查你是否是会员。而认证令牌就像一张有签名和到期日期的支票。然后，安全性来自于基于难以伪造的假设的签名，而无需直接询问发行者。

在这两种情况下，它们都处理授权，而不是身份验证。任何持有会员卡或支票的人都可以获得访问权，它们不能证明你是谁，只是证明你有权使用你要求的资源。正因为如此，它们必须小心防范盗窃，这对于更难撤销的认证令牌来说尤其如此。