Course Banner

JSON Web Tokens & Cookies

Introduction

Authentication, the validating of the site visitor as a known entity, and a determination of the rights the visitor possesses within the site, is critical to site security. We will use a fairly traditional process of checking an email address and matching password to handle authentication. However, we will use JSON Web Tokens, more commonly known as "JWT"'s as the mechanism for authorizing visitors to move in areas that an unauthorized visitor would be denied access to.

Video Overview

This video represents a high-level overview of the process to be implemented using JSON web tokens. It is not meant to replace reading the content of this document. Be sure to carefully consider both. This is the Transcript of the video.

Background

A token is simply a "ticket", which is carried from one location to another. Upon arrival, the ticket is examined for authenticity. If valid, the ticket holder is admitted. In our case, the JWT is created on our server and sent to the client's browser within a cookie. The client will automatically send the cookie back to our server with every request. When the cookie arrives, the server checks the token it carries. If valid, the server allows the request to be carried out. If the token is missing or not valid, the request is denied.

Warning!

Unfortunately, using a cookie as the transfer mechanism creates a potential means of attacking our server, known as a Cross Site Request Forgery attack. In short, another site steals the cookie, then sends the cookie to our server, pretending to be the browser to whom the cookie was originally sent. If this were a security course, we would take steps to mitigate the CSRF attack. Since it is not, we will ackowledge that the potential for this type of attack exists, but we will not deal with it. If you are interested in learning more about CSRF, visit the Open Web Application Security Project (OWASP) site.

JWT Website

The official home of JSON Web Tokens is jwt.io. Here you learn more about the how, why and what's of this approach to authorization. In addition, it has a tool, on the home page, that shows the four components of a JWT and the resulting token when all four components are combined correctly. I encourage you to visit the site, scroll down to the tool and play with it for a minute or two to get a feel for what it does. Change the Algorithm, change the payload and change the secret to see the changes that occur to the token.

JWT Components

Cookie

Cookie? No, not that kind (I love white chocolate chip with macadamia nuts - just in case you are interested)! I know, it's a strange name for a small text file that is created by the server, sent to and stored in the browser. As with most data it consists of a number of "name - value pairs". What is unique is that when the browser visits the website that created the cookie, the cookie is automatically sent back to the server as part of every "http request" until the cookie is destroyed.

Cookies are small. The maximum size they can be is 4K (4 kilobytes). In addition, they are typically plain text and can be changed in the browser. As a result, they should NEVER be used for sensitive information!

Types of Cookies

Without getting carried away, you should know that there are several types of cookies:

Persistent Cookie
A "persistent" cookie is one which lasts beyond the current set of interactions between the browser and the server. These cookies are given a life span at the time they are created. That life span can be increased or decreased by the code on the server. The means of setting the lifespan is by using the expire value, as an option, in the res.cookie(name, 'value', {expire: 3600000 + Date.now()}) . In the provided example the cookie will expire in one hour (1000 milliseconds * 60 seconds * 60 minutes).
Session Cookie
A "session" cookie is created without an "expire" option and is destroyed when the session ends. Typically, there are three main ways of ending a session:
  1. The browser window is closed.
  2. The session "times out" due to inactivity. This time factor can be altered but typically is around 24 minutes.
  3. The cookie is given an expiry value in the past or perhaps of 1 millisecond in the future. This can occur at the end of a logout procedure or at the end of a "check-out" process.

There are other cookies, but to one extent or another they are variations of the persistent cookie.

Using a cookie

Have you ever registered with a website and when you return to the site sometime in the future, the site somehow shows your name, even when you haven't logged into the site? Chances are it is a cookie at work. Some sites use "Third Party Cookies". A third-party cookie is set by one website, but used by another website. This use is usually for advertising but can also be used for tracking your browsing habits. It is this browsing function that has caused a wide variety of new privacy laws to be passed and forced websites to notify you that they use cookies. Perhaps you've seen such notices appear on websites you visit, that show you a warning notice that you have to acknowledge for it to go away. We will not create a third-party cookie, but we will create a cookie to transport a JWT token from the server to the browser and back for authorization purposes.

New Packages

In order to implement JWT's and cookies into our authentication / authorization process, we need two new packages: jsonwebtoken and cookie-parser. The "jsonwebtoken" package will make working with JWT's easier, while the "cookie-parser" package will do the same for cookies.

  1. Open a new VSC terminal.
  2. Type the following code, then press "Enter": 
    pnpm add jsonwebtoken cookie-parser
  3. When done, close the terminal.

Implementation

Having provided some background and explanation, as well as installing the packages, let's implement the JWT and the coookie in the next activity.