简而言之:

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

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

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

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

非常好的文章:

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

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

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

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

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