JWT vs cookies for token-based authentication

Question

The biggest difference between bearer tokens and cookies is that the browser will automatically send cookies, where bearer tokens need to be added explicitly to the HTTP request.

This feature makes cookies a good way to secure websites, where a user logs in and navigates between pages using links.

The browser automatically sending cookies also has a big downside, which is CSRF attacks. In a CSRF attack, a malicious website takes advantage of the fact that your browser will automatically attach authentication cookies to requests to that domain and tricks your browser into executing a request.

Suppose the web site at https://www.example.com allows authenticated users to change their passwords by POST-ing the new password to https://www.example.com/changepassword without requiring the username or old password to be posted.

If you are still logged in to that website when you visit a malicious website which loads a page in your browser that triggers a POST to that address, your browser will faithfully attach the authentication cookies, allowing the attacker to change your password.

Cookies can also be used to protect web services, but nowadays bearer tokens are used most often. If you use cookies to protect your web service, that service needs to live on the domain for which the authentication cookies are set, as the same-origin policy won't send cookies to another domain.

Also, cookies make it more difficult for non-browser based applications (like mobile to tablet apps) to consume your API.

Overview

What you're asking for is the difference between cookies and bearer tokens for sending JSON Web Tokens (JWTs) from the client to the server.

Both cookies and bearer tokens send data.

One difference is that cookies are for sending and storing arbitrary data, whereas bearer tokens are specifically for sending authorization data.

That data is often encoded as a JWT.

Cookie

A cookie is a name-value pair, that is stored in a web browser, and that has an expiry date and associated domain.

We store cookies in a web browser either with JavaScript or with an HTTP Response header.

document.cookie = 'my_cookie_name=my_cookie_value'   // JavaScript
Set-Cookie: my_cookie_name=my_cookie_value           // HTTP Response Header

The web browser automatically sends cookies with every request to the cookie's domain.

GET http://www.bigfont.ca
Cookie: my_cookie_name=my_cookie_value               // HTTP Request Header

Bearer Token

A bearer token is a value that goes into the Authorization header of any HTTP Request. It is not automatically stored anywhere, it has no expiry date, and no associated domain. It's just a value. We manually store that value in our clients and manually add that value to the HTTP Authorization header.

GET http://www.bigfont.ca
Authorization: Bearer my_bearer_token_value          // HTTP Request Header

JWT and Token Based Authentication

When we do token-based authentication, such as OpenID, OAuth, or OpenID Connect, we receive an access_token (and sometimes id_token) from a trusted authority. Usually we want to store it and send it along with HTTP Requests for protected resources. How do we do that?

Option 1 is to store the token(s) in a cookie. This handles storage and also automatically sends the token(s) to the server in the Cookie header of each request. The server then parses the cookie, checks the token(s), and responds accordingly.

Option 2 is to store the token in local/session storage, and then manually set the Authorization header of each request. In this case, the server reads the header and proceeds just like with a cookie.

It's worth reading the linked RFCs to learn more.

In addition to what MvdD has said about cookies being automatically sent:

1. A cookie can be a medium, but its most significant function is how it interacts with the browser. Cookies are set by the server and sent in requests in very specific ways. JWT on the other hand is exclusively a medium, it is an assertion of some facts in a particular structure. If you were so inclined, you could put a JWT as your authentication cookie. When you read articles comparing them, they typically are talking about using a JWT sent as a bearer token by front end code vs an authentication cookie which corresponds to some cached session or user data on the back end.
2. JWT offers many features, and puts them in a standard so they can be used between parties. A JWT can act as a signed assertion of some facts in many different places. A cookie, no matter what data you put in it or if you sign it, only really makes sense to use between a browser and a specific back end. JWT can be used from browser to back end, between back ends controlled by different parties (OpenId Connect is an example), or within back end services of one party. Regarding your specific example of your signed cookies, you can probably achieve the same functions ("not using session id, not use server memory or file storage") as JWT in that use case, but you lose out on libraries and peer-review of the standard, in addition to the CSRF issues talked about in the other answer.

In summary: the posts you're reading are probably comparing JWT as a bearer token to authentication cookie for browser to server authentication purposes. But JWT can do much more, it brings in standardization and features for use outside the use case you're probably thinking of.

While cookies can increase the risk of CSRF attacks by virtue of them being sent automatically along with requests, they can decrease the risk of XSS attacks when the HttpOnly flag is set, because any script that is injected into the page won't be able to read the cookie.

CSRF: a user clicks on a link (or views images) on an attacker's site, which causes the browser to send a request to the victim's site. If the victim uses cookies, the browser will automatically include the cookie in the request, and if the GET request can cause any non-read-only actions, the victim site is vulnerable to the attack.

XSS: an attacker embeds a script in the victim site (the victim site is only vulnerable if inputs are not sanitized correctly), and the attacker's script can do anything JavaScript is allowed to do on the page. If you store JWT tokens in local storage, the attacker's script could read those tokens, and also send those tokens to a server they control. If you use cookies with the HttpOnly flag, the attacker's script won't be able to read your cookie to begin with. That said, the script they successfully injected will still be able to do anything JavaScript can do, so you're still hosed IMO (i.e., while they may not be able to read the cookie to send it off to their own server for use later, they can send requests to the victim site using XHR, which will include the cookie anyway).

Ref - Need for JSON Web Token

Cookies

In case of cookies, once the user has been authenticated then the Gmail Server will create a unique session Id. Corresponding to this session id it will store in memory all the user information that is needed by the Gmail server for recognizing the user and allowing it perform operations.
Also then for all subsequent requests and response, this session id will also be passed. So now when the server receives a request it will check the session id. Using this session id will check if there is any corresponding information. It will then allow the user to access the resource and return back the response along with the session id.

Drawbacks of Cookies

• Cookies/session id is not self contained. It is a reference token. During each validation the Gmail server needs to fetch the information corresponding to it.
• Not suitable for microservices architecture involving multiple API's and servers

JWT

• JWT is self contained. It is a value token. So during each validation the Gmail server does not needs to fetch the information corresponding to it.
• It is digitally signed so if any one modifies it the server will know about it
• It is most suitable for Microservices Architecture
• It has other advantages like specifying the expiration time.