Understanding Auth and Cookies for Web Applications

Stop comparing JWT and Cookies

Photo by Vyshnavi Bisani on Unsplash

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!

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

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…