Stop Comparing JWT vs Cookies
Tags: webdev, programming, security
Published: 2022-12-01 23:30:43

There is a lot of confusion about cookies, sessions, token-based authentication, and JWT.

Today, I want to clarify what people mean when they talk about “_JWT vs Cookie_, “_Local Storage vs Cookies_,” “_Session vs token-based authentication_,” and “_Bearer token vs Cookie_” once and for all.

Here’s a hint — we should stop comparing JWT and Cookies!

Along the line, I’ll go through what XSS and CSRF attacks are and how to prevent them using token-based authentication with JWT and CSRF tokens.

Let’s begin!

## Overview

- [Terminology Speed Run](#terminology-speed-run)
  - [Client](#client)
  - [Server](#server)
  - [Request/Response Headers](#requestresponse-headers)
  - [Cookie](#cookie)
  - [XSS Attack](#xss-attack)
  - [CSRF Attack](#csrf-attack)
  - [Cookies Storage](#cookies-storage)
  - [Web Storage](#web-storage)
  - [Cookies (Storage) vs Web Storage](#cookies-storage-vs-web-storage)
- [JWT](#jwt)
  - [So, why use JWT?](#so-why-use-jwt)
  - [Stop comparing JWT and Cookie](#stop-comparing-jwt-and-cookie)
- [Session-based vs Token-based Authentication](#session-based-vs-token-based-authentication)
- [Cookie vs Bearer Tokens](#cookie-vs-bearer-tokens)
- [CSRF Prevention](#csrf-prevention)
  - [Same-site Cookies](#same-site-cookies)
  - [Common CSRF prevention methods](#common-csrf-prevention-methods)
  - [The modified “cookie-to-header token” approach](#the-modified-cookie-to-header-token-approach)
- [Conclusion](#conclusion)
  - [A Demo, perhaps?](#a-demo-perhaps)
- [Reference](#reference)

## Terminology Speed Run

To start, it’s important to know the differences between some of these terminologies.

Without explicitly stating these, it would be unclear for us to compare things properly.

### Client

Our client application. In this context, we are specifically talking about our web browsers, e.g., Firefox, Brave, Chrome, etc.

### Server

Computers that are doing all the magic behind the curtains.

### Request/Response Headers

[HTTP headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers). Note that they are case-insensitive.

### Cookie

Aka “HTTP cookie,” “web cookie,” or “browser cookie.”

A small piece of information that a server sends back to the client.

Stored in the browser’s Cookies storage, cookies are typically used for authentication, personalization, and tracking.

A cookie is received in name-value pairs via the `Set-Cookie` response header in a request. With this, your cookie will automatically be kept in the browser’s Cookies storage (`document.cookie`).

![An example of how a Cookie is received. You should never publicly share your JWT! (this JWT is no longer in use).
](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/99c2ywbvmfnq37wf01yr.png)

> An example of how a Cookie is received. You should never publicly share your JWT! (this JWT is no longer in use).

Cookies with `HttpOnly`, `Secure`, and `SameSite=Strict` flags are more secure.

For example, with the `HttpOnly` flag, the cookies are not accessible through JavaScript, thus making it immune to XSS attacks.

![With HttpOnly, the cookie is not shown
](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/g06mb8cvihdle36u4k4d.png)

> With HttpOnly, the cookie is not shown

[Read more on MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies) and check out what other flags do (they are handy).

### XSS Attack

Aka “Cross-Site Scripting” attack.

For context, the web storage (e.g., local storage) is accessible through JavaScript on the same domain. Consequently, web storage is vulnerable to XSS attacks.

In short, XSS is a type of vulnerability where an attacker injects JavaScript that will run on your page.

Basic XSS attacks attempt to inject JavaScript through form inputs, where the attacker puts an `alert(localStorage.getItem('your-secret-token'))` into a form to see if it is run by the browser and can be viewed by other users.

If you still don’t get what XSS is, check out [this “XSS Explained” video](https://www.youtube.com/watch?v=EoaDgUgS6QA).

### CSRF Attack

Aka “Cross-Site Request Forgery” attack.

Cookies are vulnerable to CSRF attacks. No cookies = no CSRF attacks.

As browsers automatically send Cookies with all requests, CSRF attacks use this to gain authenticated access to a trusted site. Need more? [Read CSRF in simple words](https://stackoverflow.com/a/33829607/10067850).

To protect your site against CSRF attacks while using Cookies (with `SameSite=None`), check out this [StackOverflow answer](https://stackoverflow.com/questions/34782493/difference-between-csrf-and-x-csrf-token/34783845#34783845). Next, read more about [CSRF prevention on Wikipedia](https://en.wikipedia.org/wiki/Cross-site_request_forgery#Prevention) (Wikipedia is generally too dry to my liking, but this is good!).

Still don’t get what CSRF is? Check out [this “CSRF Explained” video](https://www.youtube.com/watch?v=eWEgUcHPle0).

### Cookies Storage

Aka “Cookie Jar” or “Cookies.” *Yup. I can already see why it is confusing for many.*

Client-side storage where HTTP cookies are stored.

Here’s an important note: Browsers automatically send cookies (no client-side code needed) along with every request via the `cookie` request header. This is exactly why Cookie (storage) is vulnerable to CSRF attacks.

![XSS attacks can be prevented when using Cookies storage if the cookie is set with the HttpOnly flag.
](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rksbrca85jshug1d8otk.png)

> XSS attacks can be prevented when using Cookies storage if the cookie is set with the HttpOnly flag.

![To view Cookies: F12 → ‘Application’ → ‘Storage’ → ‘Cookies’
](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1a9pjsnifpp9sa855uhy.png)

> To view Cookies: F12 → ‘Application’ → ‘Storage’ → ‘Cookies’

### Web Storage

Aka “Local/Session Storage.”

Client-side storage. They are typically used to store data in key-value pairs.

Vulnerable to XSS attacks. Hence, not ideal for storing private/sensitive/authentication-related data.

![You can get any item on your Local Storage using JavaScript
](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4l18f6y2neqgc95iqhcv.png)

> You can get any item on your Local Storage using JavaScript

![To view Local Storage items: F12 → ‘Application’ → ‘Storage’ → ‘Local Storage’ / ’Session Storage’
](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xppb52k71mszxr83prbn.png)

> To view Local Storage items: F12 → ‘Application’ → ‘Storage’ → ‘Local Storage’ / ’Session Storage’

`sessionStorage` — data is persisted only for the duration of the page session

`localStorage` — data is persisted even when the browser is closed and reopened

[Read more on MDN](https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API).

### Cookies (Storage) vs Web Storage

|              | Local/Session Storage                                           | Cookies (Storage)                                                                                                          |
| ------------ | --------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| JavaScript   | Accessible through JavaScript on the same domain                | Cookies, when used with the HttpOnly cookie flag, are not accessible through JavaScript                                    |
| XSS attacks  | Vulnerable to XSS attacks                                       | Immune to XSS (with HttpOnly flag)                                                                                         |
| CSRF attacks | Immune to CSRF attacks                                          | Vulnerable to CSRF attacks                                                                                                 |
| Mitigation   | Do not store private/sensitive/authentication-related data here | Make use of CSRF tokens or [other prevention methods](https://en.wikipedia.org/wiki/Cross-site_request_forgery#Prevention) |

## JWT

Aka “JSON Web Tokens.”

Commonly used for [authentication and authorization](https://www.okta.com/identity-101/authentication-vs-authorization/#authentication-vs-authorization-2).

JWT is an open standard ([RFC 7519](https://tools.ietf.org/html/rfc7519)). Meaning all JWTs are tokens.

Typically, JWT is stored in Local Storage or Cookies (storage).

Remember, JWT is not encrypted by any means.

Rather, it is encoded in Base64. Try decoding any JWT on [jwt.io](https://jwt.io/).

### So, why use JWT?

Often used with token-based authentication, horizontal scaling is easier when using JWT.

Why? The verification of JWT does not require any communication between the servers and databases. In other words, the authentication can be stateless.

[Read more on Auth0](https://auth0.com/docs/secure/tokens/json-web-tokens).

### Stop comparing JWT and Cookie

Neither JWT nor Cookie are authentication mechanisms on their own.

JWT is simply a [token format](https://www.rfc-editor.org/rfc/rfc7519).

A cookie is an [HTTP state management mechanism](https://www.rfc-editor.org/rfc/rfc6265).

As demonstrated, a web cookie can contain JWT and can be stored within your browser’s Cookies storage.

So, we need to stop comparing JWT and Cookie.

## Session-based vs Token-based Authentication

Rather, the right question to ask is, “what is the difference between token-based authentication and session-based authentication?”

| Token-based                                                                                                           | Session-based                                                                                                                                                            |
| --------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Stateless                                                                                                             | Stateful                                                                                                                                                                 |
| The authentication state is NOT stored anywhere on the server-side                                                    | The authentication state is stored on the server-side (DB)                                                                                                               |
| Easier to scale horizontally                                                                                          | [Harder to scale horizontally](https://www.authgear.com/post/session-vs-token-authentication#:~:text=in%20recent%20times.-,Limited%20Scalability,-Since%20Cookies%20are) |
| Commonly uses JWT for authentication                                                                                  | Commonly uses Session ID                                                                                                                                                 |
| Typically sent to the server via an HTTP Request `Authorization` Header (e.g. `Bearer <token>)`. Can use `Cookie` too | Usually sent to the server in the `Cookie` request header                                                                                                                |
| Harder to revoke a user session                                                                                       | Able to revoke user session with ease                                                                                                                                    |

## Cookie vs Bearer Tokens

Now, we know how cookies work. Let’s take a stab at the term “Bearer tokens.” Let’s assume we’ll use JWT as our authentication token from hereon.

What people call a “Bearer token” is a string (e.g., JWT) that goes into the `Authorization` header of any HTTP request. Unlike a browser cookie, it is not automatically stored anywhere, thus making this CSRF impossible.

To make use of a “Bearer token,” we’ll need to explicitly store the JWT somewhere in our client (Cookies storage or Local Storage) and add that JWT to our HTTP `Authorization` header while making requests.

If your cookie containing a JWT is set with the `HttpOnly` flag, retrieving your token from the client side would be impossible with JavaScript.

“Wait, how about we use Local Storage then?”

Remember, using Local Storage makes our JWT vulnerable to XSS. As a result, you’ll often hear people advise strongly against storing JWT in Local Storage.

At this point, it may sound like using Cookie to store JWT is our only option. But remember, this makes our website vulnerable to CSRF attacks!

## CSRF Prevention

### Same-site Cookies

[Same-site cookies](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite) can effectively prevent CSRF attacks. Though, it comes with other caveats. [Read more here](https://security.stackexchange.com/questions/121971/will-same-site-cookies-be-sufficient-protection-against-csrf-and-xss/121986#121986).

What follows assumes that we’re not going to use SameSite cookies.

### Common CSRF prevention methods

Leaving JWT behind for a bit, these two are some of the most common CSRF prevention methods:

-   [Synchronizer token pattern](https://en.wikipedia.org/wiki/Cross-site_request_forgery#Synchronizer_token_pattern)
-   [Cookie-to-header-token pattern](https://en.wikipedia.org/wiki/Cross-site_request_forgery#Cookie-to-header_token)

Check out this [StackOverflow answer](https://stackoverflow.com/questions/34782493/difference-between-csrf-and-x-csrf-token/34783845#34783845) for a quick summary of the two approaches above.

Cool. But now comes the question — how can we do this with JWT?

### The modified “cookie-to-header token” approach

Honestly, I’m not too sure if this approach has a proper name. I found this approach from this wonderful talk about [100% Stateless with JWT (JSON Web Token) by Hubert Sablonnière](https://youtu.be/67mezK3NzpU). I highly recommend you check it out. It’s worth the hour.

In short, the modified approach (in my opinion) looks similar to the original [Cookie-to-header token approach](https://en.wikipedia.org/wiki/Cross-site_request_forgery#Cookie-to-header_token) except with a few tweaks:

-   the anti-CSRF token is returned in a separate response header (e.g. `X-CSRF-Token`) instead of the `Set-Cookie` response header
-   we sign and set a JWT on the `Set-Cookie` response header

![The modified “cookie-to-header token” approach](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/q12g94l0xajmn2c3xupg.png)

This implementation can be found on [this Cloudflare Worker demo](https://worker-auth.jerrynsh.workers.dev/) and [GitHub](https://github.com/ngshiheng/worker-auth).

1. The user logs in, and the server signs a JWT with `csrfToken` as part of the JWT claim.

```
{
  "email": "your@email.com",
  "exp": 1666798498,
  "csrfToken": "1449bd3e-41c2-45cb-a538-73c7ad80ca2c",
  "iat": 1666794898
}
```

The generated `csrfToken` should be unpredictable and unique per-user session.

2. The JWT would then be stringified into a cookie set into the `Set-Cookie` response header. The randomly generated `csrfToken` , on the other hand, will be set in the `X-CSRF-Token` response header.

3. With the `Set-Cookie` header present in the response header, our browser would automatically store the JWT in the Cookies (storage). The `csrfToken` present in the `X-CSRF-Token` header will be extracted and set in the browser’s local storage.

4. When a request (e.g., GET /hello) is triggered, our browser will get the `csrfToken` from the local storage.

5. The JWT from the Cookies (storage) and the `csrfToken` retrieved from the local storage will be sent to the server in our request header.

6. The server will verify the JWT and check the `csrfToken` from the request header with the `csrfToken` claim inside the JWT to verify if the CSRF Token is valid.

## Conclusion

In essence, as long as authentication isn’t automatic (such as in browsers with Cookies), you don’t have to worry about CSRF attacks.

For example, if your application attaches authentication credentials via a `Authorization` header, CSRF isn't possible as the browser can't authenticate the request automatically.

Lastly, we need to stop advocating that any of our comparisons is better. That is not how it works. Rather, we should think about the tradeoffs that we are making.

### A Demo, perhaps?

The screenshots in this post are taken from [this Cloudflare Worker demo](https://worker-auth.jerrynsh.workers.dev/) I made. The source code of this demo can be found [on GitHub](https://github.com/ngshiheng/worker-auth).

To test a CSRF attack, check out this [little tool](https://littletools.app/form?eyJtZXRob2QiOiJQT1NUIiwiYWN0aW9uIjoiaHR0cHM6Ly93b3JrZXItYXV0aC5qZXJyeW5zaC53b3JrZXJzLmRldi9oZWxsbyIsImZpZWxkcyI6W119) (credits: [Shrikant](https://sharats.me/)).

That aside, I created a [branch name `csrf-attack-demo`](https://github.com/ngshiheng/worker-auth/tree/csrf-attack-demo) where you could run that locally to simulate a CSRF attack on our demo site.

## Reference

I owe my thanks to all of the following references:

-   [100% Stateless with JWT (JSON Web Token) by Hubert Sablonnière](https://www.youtube.com/watch?v=67mezK3NzpU)
-   [How to Store Session Tokens in a Browser (and the impacts of each)](https://blog.ropnop.com/storing-tokens-in-browser/)


---

_This article was originally published on [jerrynsh.com](https://jerrynsh.com/all-to-know-about-auth-and-cookies/)_