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

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

所以，这就是基于cookie和基于令牌的区别，后者使用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.

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

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/

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

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

所以，这就是基于cookie和基于令牌的区别，后者使用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)     |

因为谷歌员工:

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

有状态性

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

机制

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;这些并不是唯一可能的选择 它们有利有弊，但即使是加密的令牌，也不应该存储敏感信息