## Why Json Web Tokens?

JWTs are a popular way to authenticate and authorize users. There are several advantages of using JWTs when compared to session-based authentication:

- Data is stored in client (token in localStorage) as opposed to being stored in a database (sessions). This makes JWTs more scalable.
- There are issues with session based authentication because they rely on cookies, cookies can be disabled when used from a different domain. JWTs are sent in the request header so no such problems exist.
- Cookies only work for web browsers, other applications may need additional logic to implement session-based authentication (like mobile native apps).
- Using JWTs makes a server stateless and truly adhere to REST architecture.

## JWT Workflow

1. User sends authentication data to server.
2. Server verifies authentication data and sends back a JWT.
3. The JWT is stored in the client localStorage.
4. The JWT is sent on all further requests to the server (in the header).
5. Protected routes verify the integrity of the JWT.
6. Server authorizes user to access to protect route.

## What Exactly Is a Json Web Token?

A JWT consists of 3 parts. The header, the payload and the signature. The header & payload are standard JSON objects.

```js

//header
{
  "alg": "HS256",
  "typ": "JWT"
}

//payload
{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

```

The header and token are base64 encoded to form the first two parts of the token. The server then takes the encoded header & payload and hashes + encodes it with an algorithm (usually HS256 or RS256). This generates the third and final part of the token, the signature.The three parts of the token are separated by ".".

```js
//example
const signature = HMACSHA256(
  base64UrlEncode(header) + '.' + base64UrlEncode(payload),
  secret
);

/* 
Resulting token: 

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 ->header
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ -> payload
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c -> signature
*/
```

The final result is a 3-part token that can be sent in the request header to authorize an user.

## Signing The Token

JWTs can be signed using a symmetric algorithm (HS256) or an asymmetric algorithm (RS256). The signature is used to verify the integrity of the token, not to hide the data from other parties (encoding).

### Symmetric Algorithm

A symmetric algorithm uses a single key to sign data. When the token is created, the header & payload are hashed and encoded with the key. When the server receives a JWT, it decodes the signature given the key, and compares it to the hash of the header & payload. If the hashes match, it means the data has not been tampered with and the token is valid.

Using one key to encrypt/decrypt can cause problems because anyone who has access to the key can create any type of token and impersonate others. There is also no way to know if a token is valid without having access to the key. This problem is solved by using asymmetric encryption.

### Asymmetric Algorithm

An asymmetric algorithm uses a private key and a public key to sign data. The private key is used to encode the data while the public key is used to decode the data. When the token is created, the server hashes the header & payload and encodes it with the private key. When the server receives a JWT, it decodes the signature using the public key and compares it to the hash of the header & payload. If the hashes match, then the token is valid and the data has not been tampered with.

The advantage of using an asymmetric algorithm is that only the holder of the private key can create tokens. Anyone else can use the matching public key to verify the integrity of the token and make sure that the token is coming from the private key holder.


password

JWT-Based Authentication

I wanted to learn more about backend authentication/authorization to be able to create a wider variety of web apps. I saw that passport is a popular package that handles authentication in Express, so I decided to build a project based around the passport-local strategy. The passport-local strategy uses session-based authentication. The strategy is commonly implemented with templating engines, but I decided to make it compatible with frontend frameworks (React).

## Sessions

I didn't know what sessions were before, so I had to read about them. Sessions are a way to store user-specific data on the server. The server sends a cookie to the client that stores the session id. On subsequent requests, the server uses the session id stored in the browser to get information stored in the session. The express-session package allows for easy setup in an Express app. By default, express-session stores sessions in memory, which is not scalable. Using the connect-mongo package, I can specify express-session to store data in a MongoDB database instead.

```js
const session = require('express-session');
const MongoStore = require('connect-mongo');

app.use(
  session({
    secret: 'not a good secret',
    store: MongoStore.create({ mongoUrl: MONGODB_URI }),
    cookie: {
      maxAge: 1000 * 60 * 60 * 24, // Equal to 1 day
    },
  })
);
```

The express-session package automatically sets one of the user's cookie values to the session id on a request. On subsequent requests the express-session package checks for the session id stored in the specified cookie. If a session is found, it fetches the session from the store and assigns the data to `req.session`. Routes can then access the `req.session` field to modify session data mutably.

## Passport Configuration

I used the passport-local strategy, which authenticates using username and password data. The passport-local package stores authentication data in sessions, so it requires express-session to be set up.

LocalStrategy takes a parameter `verifyCallback` that is used to authenticate users (used in `passport.authenticate('local')`).

```js
const passport = require('passport');
const LocalStrategy = require('passport-local').Strategy;
const User = require('./models/User');
const { validPassword } = require('./util');

passport.use(
  new LocalStrategy(async (username, password, done) => {
    // function used to authenticate a user (verifyCallback)
    // call done(error, user) to pass results
    try {
      // finds user in database
      const user = await User.findOne({ username: username });
      if (!user) return done(null, false, { message: 'User does not exist.' });

      //verify password using bcrypt
      const isValid = await validPassword(password, user.password);
      if (!isValid)
        return done(null, false, { message: 'Invalid password provided.' });

      // remove password to send to user
      user.password = undefined;
      return done(null, user);
    } catch (err) {
      return done(err);
    }
  })
);
```

Passport also comes with middleware that handles storing and retrieving data from the current session. This middleware calls the `passport.serializeUser` to store a newly authenticated user into the session. On subsequent requests, if the session contains an authenticated user, the passport calls the `passport.deserializeUser` function and attaches the resulting user to `req.user`.

```js
// serializes user into session
passport.serializeUser((user, done) => {
  // store only user.id into session
  done(null, user.id);
});

// deserialize user from session
passport.deserializeUser(async (id, done) => {
  try {
    // finds user in database using id in session
    const user = await User.findById(id).select('-password');
    done(null, user);
  } catch (err) {
    done(err);
  }
});

// passport middleware
app.use(passport.initialize());
app.use(passport.session());
```

## Registering

Logic to create a user is not handled by passport. A new document in the `users` collection with a username and password field needs to be created.

```js
const express = require('express');
const router = express.Router();

const User = require('../../models/User.js');
const { genPassword, wrapAsync } = require('../../util');

const AppError = require('../../AppError');

// register a user
router.post(
  '/',
  wrapAsync(async (req, res) => {
    const { username, password } = req.body;
    const foundUser = await User.findOne({ username });
    if (foundUser) throw new AppError(400, 'User already exists.');

    const hash = await genPassword(password);
    const user = new User({ username, password: hash });
    const saved = await user.save();

    saved.password = undefined; // don't send password to user
    res.json(saved);
  })
);

module.exports = router;
```

## Authenticating

Authenticating an user uses the `passport.authenticate` method. Normally, this is passed in as middleware but I used it inside the route handler for custom functionality (error handling). `passport. authenticate` uses the passport `verifyCallback` function (defined in config). `passport. authenticate` looks for the username and password field in `req.body` to be used in the verify callback (can be changed in the config). If authentication is successful, the user is serialized into the session.

```js
//by default, if authentication fails - passport.authenticate returns a 401 unauthorized error with a text message
router.post('/', passport.authenticate('local'), (req, res, next) => {
  res.json(req.user);
});

//using a custom callback, handle errors using custom error handler
router.post(
  '/',
  wrapAsync(async (req, res, next) => {
    passport.authenticate('local', function (err, user, info) {
      if (err) return next(err);

      if (!user) return next(new AppError(401, info.message));

      //req.logIn function provided by passport - handles user serializing
      req.logIn(user, function (err) {
        if (err) {
          return next(err);
        }
        res.json(user);
      });
    })(req, res, next);
  })
);
```

## Authorization

Custom middleware can be used to protect routes. The middleware can call `req.isAuthenticated` (provided by passport) to check if a user is stored in the current session.

```js
const AppError = require('./AppError');

//Authentication middleware

module.exports.isAuth = (req, res, next) => {
  if (req.isAuthenticated()) {
    // given by passport
    next();
  } else {
    next(new AppError(401, 'Not authorized.'));
  }
};
```

## Conclusion

This project taught me a lot about different methods of authentication and how to implement session-based authentication. I have used some JWT authentication (without passport) in the past, and it seems more suitable for integrating with React. It is still good to know how session-based authentication works behind the scenes.


keys

Session-Based Authentication with Passport

I recently decided to read over the official redux documentation when working on a project. In the past, I remember redux needed a lot of boilerplate to set up, and it was a pain recalling what to do.

## Redux Boilerplate

For implementing redux in my application, there were a lot of things that needed to be done. I had to set up the store with the correct middleware, set up my reducers, action creators, action types, and more. This code was written across multiple files and it was a very lengthy process to get right. In the docs, I read about a new package they created, redux-toolkit. redux-toolkit is a package that simplifies the setup for a redux store and makes everything more neat and modular.

## Creating The Store

When setting up a redux store, you have to combine all of the reducers, configure the middleware (most commonly redux-thunk), and set up the redux dev tools extension. This is a lot to remember. With redux-toolkit, all of that code is taken care of with the configure store function.

```js
import { configureStore } from '@reduxjs/toolkit';
import recipeReducer from './slices/recipeSlice';
import authReducer from './slices/authSlice';
import errorReducer from './slices/errorSlice';
import userReducer from './slices/userSlice';

const store = configureStore({
  reducer: {
    recipe: recipeReducer,
    auth: authReducer,
    error: errorReducer,
    user: userReducer,
  },
});

export default store;
```

## Redux Slices

Using slices removes a lot of unnecessary code from the original redux. Originally, I had to keep three separate files for each reducer. An actions file, an action types file, and the reducer file itself. Using a slice combines all of this logic into one. Creating a slice also comes with the benefit that you can modify the reducer state mutably. This is because redux-toolkit comes with a feature that automatically turns mutable updates into immutable updates in the slice reducer.

```js
import { createSlice } from '@reduxjs/toolkit';

const initialState = {
  error: '',
  show: false,
};

const errorSlice = createSlice({
  name: 'error',
  initialState,
  reducers: {
    setError(state, action) {
      state.error = action.payload;
      state.show = true;
    },
    hideError(state) {
      state.error = '';
      state.show = false;
    },
  },
});

export const { setError, hideError } = errorSlice.actions;

// async actions here

export default errorSlice.reducer;
```

## Conclusion

That is pretty much all of the code necessary to create the Redux store. Without redux-toolkit, the code is much more complicated. In the future, I will 100% be using the redux-toolkit package if my project integrates redux for state management.


database

Revisiting Redux

This article is about the many new things I learned while developing a full-stack to-do list. This app uses the MERN stack and is deployed on Heroku.

- [Github repo](https://github.com/HoangNguyen-CA/fullstack-todo-list)

## Backend

- Express
- Mongoose (MongoDB)

Using express, I created a REST API to handle HTTP requests and perform CRUD operations. For simplicity, all to-dos share a global collection in MongoDB; user-dependent data is not stored (yet).

### API Routes

The following routes are able to handle all API requests:

- GET `/api/todos/`
  - Fetches all to-dos
- POST `/api/todos/`
  - Adds a new to-do
- PUT `/api/todos/:id/`
  - Edits an existing to-do
- DELETE `/api/todos/:id/`
  - Deletes an existing to-do

### Asynchronous Code

I used the mongoose package to integrate MongoDB with express. Interacting with a database is an asynchronous operation and must be handled properly. I recently learned a new syntax for making asynchronous calls: async/await. The async/await syntax allows for asynchronous code to be written similarly to synchronous code. In my opinion, this new syntax is much cleaner and more convenient to use when compared to promises.

```js
/* async/await syntax */
async (req, res) => {
  try {
    const data = await Todo.findOne(); // Asynchronous call
  } catch (e) {
    // handle error
  }
};

/* promises syntax */
Todo.findOne()
  .then((data) => {})
  .catch((e) => {});
```

### Error Handling

I recently learned a new way to handle errors in an express app. This is done using a centralized error handling middleware. This middleware will automatically catch all synchronous errors that are thrown. Asynchronous errors must be handled differently, they must be passed into the next() function in each middleware to be handled. Using this middleware is convenient since all errors in the app will be processed and an appropriate response will be sent to the client.

```js
app.use((err, req, res, next) => {
  const { status = 500, message = 'Something Went Wrong!' } = err;
  res.status(status).json({ status, error: message });
});
```

Using a custom AppError class, errors can be thrown that contains a status code and a message, which will be sent to the handler.

```js
class AppError extends Error {
  constructor(status, message) {
    super();
    this.status = status;
    this.message = message;
  }
}
```

#### Asynchronous Errors

To properly catch and send asynchronous errors to the error handler, asynchronous code must be wrapped in a try/catch statement. To achieve this, I created a higher-order function that takes in an asynchronous function and catches all errors produced by it. The function then calls next(error) to send the error to the error handler. This function wraps around all route callbacks to catch all of their errors.

```js
const wrapAsync = (action) => (req, res, next) =>
  action(req, res, next).catch((error) => next(error));

router.get('/', wrapAsync(async (req, res, next) => {
    ...
  })
);
```

## Frontend

- React
- CSS Modules

### Styling

Using CSS Modules allows for CSS code to be modular and prevent conflicts between styling classes. Each React component has its own stylesheet which only applies locally. CSS module comes built-in with create-react-app. CSS module files must end with `.module.css` and can be imported into any react component. All of the styles become available from the imported object and can be used in the className property.

```css
/* styles.module.css*/
.bigFont {
  font-size: 1rem;
}
```

```js
/* App.js */
import styles from './styles.module.css';

function App() {
  return <p className={styles.bigFont}>hello world</p>;
}
```

#### Global Theme

To keep the colours consistent within my app, I needed a way to share variables between all of my CSS files. I used CSS custom properties(variables) to achieve this. CSS variables can be set in a global CSS file and be accessed from any CSS file on the page using the var() function.

```css
/* global.css*/
html {
  --colors-dark: #161616;
  --colors-primary: rgb(86, 12, 255);
  --colors-primary-dark: rgb(65, 0, 218);
  --colors-primary-light: #5a66ff;
  --colors-blue: #127bff;
  --colors-blue-dark: rgb(5, 99, 214);
  --colors-orange: #fe5413;
  --colors-orange-dark: #d13e04;
}

/* styles.module.css */

.orangeBackground {
  background-color: var(--colors-orange);
}
```

## Conclusion

Creating this app was a great learning experience. I made a lot of progress understanding how to write good and modular code.

Here is the site deployed to Heroku:

- [Todo List](https://hoangnguyen-todolist.herokuapp.com/)


Hoang Nguyen

Blog