DEV Community: Ogbonna Basil

Remaining Stateless - A more optimal approach

Ogbonna Basil — Mon, 27 Apr 2020 19:32:54 +0000

This article provides an example of using http only cookies as containers for refresh tokens while sending authorization tokens as response to the client stored in memory on the client side.

In this article i will be using graphql, a more flexible api query language and typescript a strongly typed superset of javascript and mongodb ,a nosql database.

What are refresh tokens and why do we need them?

Refresh tokens are JWT that are long-lived and contains enough information about the user to generate access tokens. They are long lived in the sense that their expiration date is longer when compared to access tokens. Since JWT are stateless there is no way to destroy them until the they expire. Hence for better security access tokens used to access authenticated routes should have a short expiration period.
Just before an access token expires however a refresh token carries out a silent refresh to generate another access token so the user does not get forcefully logged out and have to login again.
In using refresh tokens, however the consideration mentioned in the first article of this series should be taken into account.

Remaining Stateless - Using Redis for token blacklisting in Node JS

Ogbonna Basil ・ Jul 22 '19

#redis #jwt

Where to store Refresh and access tokens?

Since we want to remain stateless, not saving the user state in any database, refresh tokens are generated on the backend and saved in the headers of the request using a http only cookie. using a http only ensures that that the client does not have access to cookies in the headers. For additional security you can add the secure option when creating the cookies to be true. This would ensure that you can only make request from https.
On the other hand the access tokens are best saved in memory on the frontend. That way they are not exposed to XSS attacks associated with local storage or CSRF attacks associated with cookie storage.

If refresh tokens are saved with cookies does that not make them susceptible to CSRF attacks?

Cookie storage are susceptible to CSRF attacks but if an attacker get access to your refresh token via a form attack, the attacker cannot gain access to authenticated routes because he maybe able to generate access tokens from the refresh tokens but would not be able to access them because they are saved in memory.

The example below shows a simple user authentication with refresh token and access tokens.

Create a database connection in mongodb

import dotenv from "dotenv";
import mongoose from "mongoose";

dotenv.config();

const url = process.env.MONGO_URI || "mongodb://localhost:27017/users";

export default function db() {
    mongoose.connect( url, { useCreateIndex: true,
useNewUrlParser: true, useUnifiedTopology: true,
      }).catch((err) => console.log(err));
}

// dbConfig.ts

Create a model for user including it type implementation using interfaces

import bcrypt from "bcryptjs";
import mongoose, { Document, Schema } from "mongoose";

export interface IUser extends Document {
    email: string;
    username: string;
    password: string;

}
const userSchema: Schema = new Schema({
    email: { type: String, required: true, unique: true , sparse: true },
    username: { type: String, required: true },
    password: { type: String, required: true }, 
});

userSchema.pre<IUser>("save", function(next) {
    if (!this.isModified("password")) { return next(); }
    const hash = bcrypt.hashSync(this.password, 10);
    this.password = hash;
    return next();
  });

// method for compare the password
userSchema.methods.comparePassword = function(password: string) {
    const user = bcrypt.compareSync(password, this.password);
    return user ? this : null;
};
export default mongoose.model<IUser>("user", userSchema);

// model.ts

In the example below i am using graphql-yoga, a graphql implementation built on top Apollo graphql server

import { ContextParameters } from "graphql-yoga/dist/types";

import models from "path/to/models";

export default function({request, response}: ContextParameters) {
    return {
        models,
        request,
        response,
    };
}
// context.ts

Type definition in graphql that describe the inputs and expected ouptut for either mutations, query or subscriptions

const typeDefs =`
type Query {
      refresh(id: ID!): String!
  }
type Mutation {
    login(input: loginDetails): Auth!
    signup(input: signupDetails): Auth!
    doSomething(input: someInput) : String!
  }

  type Auth {
    user: User!
    token: String!
  }

  type User {
    id: ID!
    username: String!
    email: String!
  }

  input signupDetails{
    email: String!
    username: String!
    password: String!

  }
  input loginDetails{
    email: String
    password: String
  }
input someInput {
 something: String
}

`

export default typeDefs;

// typeDef.ts

In the code below on signup, a refresh token is generated and saved in the http only cookie via the method auth.generateRefreshToken. Also the access token is generated through the auth.generateAccessToken method. This also happens on login.

The refresh resolver gets the refresh token from the cookie string, verifies it and uses it to generate a new access token. The client has to make frequent calls to this mutation so as to ensure the user will not be forced out once the access token expires. Also notice that on refresh it generates an refreshCookie. Thus the previous refresh cookie is updated and you have a new cookie that has a expiry span of 30 days from when you last called the refresh token query. That way a user can always be logged in as far he is active over the last say 30 days.

The doSomething resolver verifies the access token sent as authorization header and then allows user access to authenticated routes based on it.

import { Context } from "graphql-yoga/dist/types";
import helpers from "path/to/utils";
const { auth, secret } = helpers;
export const signup = async (parent: any, args: any, { models, response }: Context) => {
    try {
        const userEmailExists = await models.user.findOne({ email: args.input.email });
        if (userEmailExists) {
            throw new Error("Email already exists");
        }
        const user = await models.user.create(args.input);
        auth.generateRefreshCookie({id: user.id}, response);
        const token = auth.generateAccessToken({ id: user.id });
        return { user, token };
    } catch (err) {
        throw new Error(err.toString());
    }
};


export const login = async (parent: any, args: any, { models, request, response }: Context) => {
    try {
        const user = await models.user.findOne({ email: args.input.email });
        if (!user || !user.comparePassword(args.input.password)) {
            throw new Error("Invalid user login details");
        }
        auth.generateRefreshCookie({ id: user.id}, response,
        );
        const token = auth.generateAccessToken({ id: user.id });
        return { user, token };
    } catch (err) {
        throw new Error(err.toString());
    }
};

export const refresh = async (parent: any, args: any, { request, response }: Context) => {
    try {
        const tokenString = request.headers.cookies.split(";")[0];
        const currentRefreshToken = tokenString.split("=")[1];
        if (!currentRefreshToken) {
            throw new Error("No Refresh Token found");
        }
        const decoded = auth.decode(currentRefreshToken, secret.refreshSecret);
        const devices = auth.decode(decoded.address, secret.userSecret);
        await auth.generateRefreshCookie({id: user.id}, response,)
        return auth.generateAccessToken({ id: decoded.id });
    } catch (err) {
        throw new Error(err.toString());
    }
};

export const doSomething = async (parent: any, args: any, { request }: Context) => {
try {
 const userId = await auth.verifyToken(request)
 // then do something on token verification
return 'something'
}
catch(err) {
throw new Error (err.toString())
}
}

// resolver.ts

import { Context } from "graphql-yoga/dist/types";
import * as auth from "path/to/helpers/auth";
import secret from "path/to/helpers/secret";
export default({
    auth,
    secret,
})
// utils.ts

import {config} from "dotenv";
import {Secret} from "jsonwebtoken";
config();
const secret = ({
    appSecret : process.env.APP_SECRET as Secret,
    refreshSecret: process.env.REFRESH_SECRET as Secret,
})
// secret.ts

In the code below notice that for the generateAccessToken, the token expires in 15min whereas the refreshToken used in the generateCookie method expires in 30days. It therefore means that a user will be logged in for 30 days from the last time of being active, before been logged out that is, if the user does not deliberately log out within this time frame.

Note also that the httpOnly option in cookie is set to true. Client side javascript has no way to view this cookie and this adds additional security. If you wish to use it only via https then set secure to true.

import { Context } from "graphql-yoga/dist/types";
import jwt, { Secret } from "jsonwebtoken";
import secrets from "path/to/helpers/secret";

const { appSecret, refreshSecret } = secrets;
export const encode = (args: any, secret: Secret, options: object) => {
    return jwt.sign(args, secret, options) as any;
};
export const decode = (args: any, secret: Secret) => {
    const decoded = jwt.verify(args, secret) as any;
    if (!decoded) {
        throw new Error("Invalid Token");
    }
    return decoded;
};
export const generateAccessToken = (args: any) => {
    const token = encode(args, appSecret, { expiresIn: "15m" });
    return token;
};

export const generateRefreshCookie = (args: any, response: Context) => {
    const refreshToken = encode(args, refreshSecret, { expiresIn: "30d" });
    const auth = response.cookie("refreshtoken", refreshToken, {
        expiresIn: "30d",
        httpOnly: true,
        secure: false,
    });
    return auth;
};

export const verifyToken = (request: Context) => {
    const token = request.headers.authorization.split(" ")[1];
    if (token) {
        const decoded = decode(token, appSecret) as any;
        return decoded;
    }
    throw new Error("Not Authenticated");
};

// auth.ts

To be able to use use cookies you need a cookie parser , so install cookie-parser and use it as a middleware. Also in using cookies you need to set Cors credentials to be true and explicitly state the address from which the request will be originating. You


import parser from "body-parser";
import compression from "compression";
import cookieparser from "cookie-parser";
import cors from "cors";
import {config} from "dotenv";
import { NextFunction, Request, Response } from "express";
import {GraphQLServer} from "graphql-yoga"

config()
export const handleCors = (router: GraphQLServer) =>
  router.use(cors({ credentials: true, origin: [`process.env.frontUrl`] }));

export const handleBodyRequestParsing = (router: GraphQLServer) => {
  router.use(parser.urlencoded({ extended: true }));
  router.use(parser.json());
};

export const handleCookieParsing = (router: GraphQLServer) => {
  router.use(cookieparser());
};

export const handleCompression = (router: GraphQLServer) => {
  router.use(compression());
};
}))

export default [handleCors, handleBodyRequestParsing,  handleCookieParsing, handleCompression
];
// applyMiddleware

Note that Graphql has an inbuilt method of handling middlewares which could be used instead of this approach


import { GraphQLServer } from "graphql-yoga";
import db from "path/to/dbConfig";
import context from "path/to/context";
import resolvers from "path/to/resolver";
import typeDefs from "path/to/typedefs";
import { applyMiddleware } from "path/to/applyMiddleware";

process.on("uncaughtException", (e) => {
  console.error("uncaught exception ", e);
  process.exit(1);
});
process.on("unhandledRejection", (e) => {
  console.error("Unhandled Promise rejection ", e);
  process.exit(1);
});

db();

const server = new GraphQLServer({
  context,
  resolvers,
  typeDefs,
},
  );

applyMiddleware(middleware, server);

const options = {
  endpoint: "/users",
  playground: "/",
  port: 8000,
  subscriptions: "/subscriptions",

};

server.start(options, ({port}) =>
console.log(`Server started, listening on port ${port} for incoming requests.`),
);
// server.ts

I will leave you to try this optimal method for authenticating users while remaining stateless.

AHA! No more STUPID Codes,YAGNI.

Ogbonna Basil — Tue, 21 Jan 2020 21:13:11 +0000

It's another year to be a better developer. If like me, you are set out to be a better developer than last year, here are some software principles to apply that would improve your software development cycle.

Who is YAGNI or rather what?

Don't bother about that! You're Aren't Gonna Need It (YAGNI). That's a practice to imbibe when developing software. Add only required features, not features you think will be needed soon. Ron Jeffries one of the three founders of extreme programming states it in this way. "Always implement things when you need them, never when you just foresee that you need them". That's the whole essence of Agile development. Create the required features, the users' feedback to a product will tell what additional features to add. Then iterate. It saves you the following costs:-

Cost of building that additional features which might not have been necessary
Cost of delaying the release of the product because you want to add an extra feature that you're not going to need.
Cost of carrying the feature as each feature added adds additional complexity to the codebase and therefore increases the cost in terms of time spent debugging
The cost of refactoring the feature when you find out the user does not interact with the feature the way you had imagined they would.
Cost of repairing to build the right features or right way of interacting with a feature based on user feedback.

Avoid writing STUPID codes.

What's a stupid codebase? A STUPID codebase is one that uses:-

Singletons - Most times we need more than one instance of a class. Learn more about the dangers of singletons here
Tight coupling - Why link two components in such a way that changing one will not work unless the other is changed?
Untestable code - Shipping without writing tests is a recipe for broken deployments. Difficulty in writing unit tests shows that your code is tightly coupled. Integrations test, snapshot testing, end-to-end testing all have their use cases and should be written as necessary.
Premature Optimisation - Don't waste your time trying to optimize parts of the codes that do not improve the overall software performance.
Indescriptive Naming - Naming can be a pain sometimes. However, it is more painful to give names that do not describe well what the class, function, method, string e.t.c does. After some time when you or another developer visits the codebase, you would be asking the question 'What does this variable do?'. Some principles on naming variables can be found here
Duplication - Copy and paste may seem easy but truly it makes the code ugly. You have a long codebase full of redundant codes. Learn to make it DRY

It's good to keep your codes, DRY

Don't Repeat Yourself(DRY) is a basic principle in software development. The aim as the name implies is to save time in development by avoiding repetitions of code and information.

How to keep it DRY

Break down your code and logic into reusable units. Call them where you need them.
Use helper functions or methods.
Middleware comes in handy.

Pitfall of DRY

In a bid to keep code DRY, many developers fall into the lure of abstracting almost every aspect of the codebase. For you the developer who wrote the code, it's dry, for the next developer going through the codebase is hard. I was overly concerned about keeping it DRY, that I became habituated to abstracting my codes. Time for a rethink is when you hear of AHA programming.

Ever heard of AHA programming?

Abstracting a software component means separating what it does from how it does it. This could be achieved by creating a new method or function (what it does) and importing or calling it were you need it (how it does it).
Avoid Hasty Abstractions (AHA) programming is a software development principle popularised by Kent.C.Odds. You can read more about AHA programming here. A basic summary of how to ensure you have avoided the lure of hasty abstractions is summed up in the words Prefer duplication over wrong abstraction, Optimise for change.
Basically, instead of hurriedly creating a helper class that would not necessarily apply to all the cases where the abstraction is needed as changes occur to the codebase, duplicate the code inline.

How to AHA!

Write codes with duplicate codes first for all use cases.
When you have finished writing, you will see the commonalities, then you can abstract.

The bottom line is, feel free to use abstractions not sparingly but when necessary and don't be afraid to duplicate your code.

KISS or GRASP

KISS

When it comes to software design you either Keep It Simple, Stupid (KISS) or risk losing your users. A difficult to navigate application is not usable no matter how useful it is and can't be lovable. What can help you get a kiss on design? Two tips to keep in mind.

Do user research before designing the products and get an insight into how the user would most likely interact with the app.
Remember YAGNI so you don't complicate the products.

GRASP

General Responsibility Assignment Software Patterns (Grasp) are guidelines used in assigning responsibility to classes and objects in Object-Oriented designs. Grasp is made up of 9 basic patterns for assigning responsibility. Here is a summary of them

Information Expert:- Give a class the responsibility only if it has all the necessary information in that class to fulfill that responsibility.
Creator:- A class B should only be given the responsibility to create another class A if B contains or aggregates A, B closes uses A, B holds the data for initializing A or B records A.
Controller:- An object is assigned the role of a controller if the object sits as the first layer after the UI components. A controller handles all user requests coming from the UI by delegating the responsibility to other objects or methods. The controller should be thought of as a service layer.
Low Coupling:- Assign responsibilities to objects so that the dependency of one to another object is low. That is a change in one does not necessarily affect the other greatly. This makes it have a high potential of being reused. One way to achieve this is by using the indirection principle. Another way to achieve low coupling is to use composition instead of inheritance.
Indirection:- Assign the responsibility of the interaction between two objects to another object, an intermediate object. This helps to ensure that they are not directly coupled. They become low coupled.
High Cohesion:- Assign responsibilities to a class or object such that the responsibilities are related. If a class has many responsibilities it would have low cohesion because the class would be handling unrelated responsibilities. On the other hand, an object with a single responsibility has the highest cohesion.
Polymorphism:- When related behaviors (method) vary by type(class), assign the responsibility of the method to the class in which the variation occurs. A way to achieve polymorphism is method overriding.
Protected Variations:- To avoid changes or variations of elements to affect other elements, take note of what causes the variations in these elements, create an interface for these variations and use polymorphism for various implementation of the interface.
Pure Fabrication:- When trying to have an information expert reduces high cohesion and causes tight coupling or it becomes difficult to figure out where to place responsibilities, assign a highly cohesive set of responsibilities to a class that does not represent the domain problem. For example, storing data does not represent a domain problem. It is a service.

Build Software like Hollywood

How does one build a software like Hollywood? By implementing the Hollywood principle, "Don't call us, we call you". This is a popular phrase used in Hollywood auditions to infer rejections of candidates seen as not fitting. Following that design in software development, the higher-level component dictates how low-level components should be implemented so that no dependency is between them, but not the other way round. Higher-level components call lower-level components not through direct dependence but via abstractions. This is similar to the Dependency inversion principle in SOLID although the Hollywood principle specifies the exact flow.

Your codes should be SOLID

SOLID principles are a major set of software design principles. They include

Single Responsibility Principle: - A class, method or function should have only one responsibility i.e it should carry out only one function. A function that checks if a user exists before logging the user in does not follow SRP. That is because it carries out two functions, checks if the user already exists and logging the user. These two actions should be separated into different functions, one for checking if the user exists and the other functions for logging the user in. That way it abides by SRP.
Open-Closed Principle:- A class or method should be open to extension but closed to modification. This is achievable through inheritance or composition where the base class is extended to any subclass including its methods without modifying the base class. Methods can also be overridden in subclasses ensuring polymorphism. In functional programming, this is achievable using higher-order functions.
Liskov Substitution Principle:- An object in a program should be substitutable with instances of the object subtype without altering the correctness of the program.
Interface Segregation Principle:- Clients should not be forced to depend on methods it does not use. Do not add functionality to an existing interface by adding new methods but rather create many client-specific interfaces that contain only what the client needs for its specific use case.
Dependency Inversion Principle:- Abstractions should not depend on details. Details should depend on the abstractions. High-level modules should not depend on low-level modules. They should both depend on the abstraction.

Keeping it LEAN

Lean development is an agile framework where the team creates the minimum viable product, releases to the public, learns from its users and iterate back on feedback. Seven principles that could help you keep your software development cycle are:

Eliminate waste - During software development, eliminate waste by avoiding extra features, partially done work, switching tasks between teams and unnecessary inventory.
Build quality in - You can do this by practicing test-driven development and continuous integration, refactoring often, keeping the code base simple and avoid building defects in the software for the first time.
Create knowledge - Expect your design to evolve from the initial design plan. Therefore create short release cycles, deliver MVP and get knowledge from the users through feedback and evaluation. Then iterate. Learn as you build throughout the process.
Deliver fast - Create release cycles of equal length so that developers know the timeline for release and do not have to guess. These release cycles should be short so that the software would be delivered fast so that customers would not have time to change their minds about using the products.
Defer commitment - Delay uncertain decisions in the development process as late as possible when facts have been gathered to aid the decision-making process. It doesn't mean you should not plan, it means that you should plan different options as possible but only decide on one as late as possible when feedbacks and evaluation suggest that the option is the best.
Respect people - Don't view the people working on the development project as resources but rather as people. They need motivation. They need a higher purpose for doing the work. They also need to be acknowledged for the work they do. Help the members of the team grow their technical skills through training. Empower the team with the right tools to do the work.
Optimize the whole - While different teams could work on various parts of the software development and in a series of release cycles, the overall aim is to optimize the whole product, the big picture. That means the interactions within various parts of the app should be optimized and bug-free. That ensures the whole value stream is optimized.

Don't forget that KID!

You may have followed some of these principles in building that great app, don't forget to Keep It Documented (KID). A good document is essential for maintenance purposes, for transfer of knowledge from one developer or team to another and for development purposes. Good documentation should include installation details, troubleshooting, how to deploy the app in various environments, databases, and files. It should also enable the user to easily navigate the app.

PS: These principles are in no way new. This serves as my software design principle cheatsheet but I am optimistic others will benefit from it in a bid to becoming a better developer.

Cheers to being a better developer in 2020 and the years to come!

Remaining Stateless - JWT + Cookies in Node JS(REST)

Ogbonna Basil — Tue, 22 Oct 2019 22:20:59 +0000

JWT is stateless. Using cookies as a container to store JWT is easy and scalable.

Why Store in cookies

The need to store JWT in cookies is seen in considering the difference between cross-site scripting(XSS) and cross-site request forgery (CSRF).
A little digging will suffice but in summary:-

XSS happens when an attacker inserts malicious code into the client-side browser basically by inputting a script in forms and checking if the browser will run these scripts.XSS exploits the trust a user has for a particular site.
CSRF, on the other hand, is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated(i.e they have sessions). CSRF attacks specifically target state-changing requests, not theft of data since the attacker has no way to see the response to the forged request.CSRF exploits the trust that a site has in a user's browser
XSS attacks occur in varied ways.
CSRF attack can only occur when an authenticated user session is hijacked, the attacker carrying out activities on behalf of the user.
Stateless JWT stored in the browser local storage is more susceptible to XSS attacks and less to CSRF attacks.
Cookies are less susceptible to XSS attacks provided it's HTTPOnly and the secure flag is set to true. Using only HTTPOnly might not prevent an attack as an attacker might use XST (cross-site tracing) to retrieve the cookie via XSS + HTTP Trace.
Cookies are more susceptible to CRSF attacks. However, it is well known how to mitigate CSRF attacks than the more varied XSS attacks.

Storing JWT in cookies in Node JS

Step 1 - Create a JWT on register or Login

install JWT and dotenv

 npm install jsonwebtoken
 npm install dotenv

Generate Token and save in token in Cookie

const jwt = require('jsonwebtoken');
//import jwt from 'jsonwebtoken'; 

const generateToken = (res, id, firstname) => {
  const expiration = process.env.DB_ENV === 'testing' ? 100 : 604800000;
  const token = jwt.sign({ id, firstname }, process.env.JWT_SECRET, {
    expiresIn: process.env.DB_ENV === 'testing' ? '1d' : '7d',
  });
  return res.cookie('token', token, {
    expires: new Date(Date.now() + expiration),
    secure: false, // set to true if your using https
    httpOnly: true,
  });
};
module.exports = generateToken

// generateToken.js file

Step 2 - Use Cookie-Parser

install cookie-parser and cors

npm install cookie-parser
npm install cors

Ensure server uses cookie-parser



const express = require('express');
const cors = require('cors');
const cookieParser = require('cookie-parser');
const loginRouter = require('./path/to/loginRouter');
require('dotenv').config();
const server = express();
server.use(express.json());
server.use(cors());
server.use(cookieParser());
// server should use login router
server.use('/', loginRouter)

const PORT = process.env.PORT || 5000;

server.listen(PORT, () => console.log(`Server started at port ${PORT}`));

// server.js file

Step 3- On Login/Register call the generate token

const generateToken = require('./path/to/generateToken');

const login = async (req, res) => {
  const { email, password } = req.body;

  try {
// get user details based on the login parameters

    const result = await emailExists(email);

    const { id, firstname} = result;

    await generateToken(res, id, firstname);
// carry out other actions after generating token like sending a response);
  } catch (err) {
    return res.status(500).json(err.toString());
  }
};
// loginController.js file

Verifying JWT stored in cookies

To create protected routes, the user needs to be authenticated. Authenticating a user requires decrypting the token gotten in the cookies. To do that you need an authentication middleware that gets the token from the cookies, verify the token is still valid and passes the action to the controller.

const dotenv = require('dotenv');
const jwt = require('jsonwebtoken');

dotenv.config();
const verifyToken = async (req, res, next) => {
  const token = req.cookies.token || '';
  try {
    if (!token) {
      return res.status(401).json('You need to Login')
    }
    const decrypt = await jwt.verify(token, process.env.JWT_SECRET);
    req.user = {
      id: decrypt.id,
      firstname: decrypt.firstname,
    };
    next();
  } catch (err) {
    return res.status(500).json(err.toString());
  }
};

module.exports = verifyToken;

// verifyToken.js file

This is then used as a middleware to verify the user. If the user is verified, the controller is called. Otherwise, an authorization error is sent to the user

const express = require('express');
const user = require('./userController');
const verifyToken = require('../path/to/verifyToken');

const router = express.Router();

router.post(
  '/auth/verify',
  verifyToken,
  user.verifyMail,
);
)
module.exports = router;

// LoginRouter.js file

Using backend generated Cookies for front-end authentication

When cookies are created at the backend with options of HTTPOnly set to true, the cookies are not visible to the frontend. When a request is made to the server, the cookies comes embedded in the headers alongside the request.

Set up cors on the backend

when using cookies on the backend, the origin of the request needs to be specifically stated. To do this ensure that the server has cors with the credentials set to true and origin containing the needed origins. One way to easily change up origin is by saving the frontend as an environment variable and setting it up using process.env.

// server.js (backend)
server.use(
  cors({
    origin: [
      `${process.env.FRONT_URL}`,
      'http://localhost:3000',
      'https://mypage.com',
    ],
    credentials: true
  })
);

Ensure headers are sent with request to the backend

On the frontend, when making request from the backend with axios or fetch ensure that headers are sent alongside the request. To do that with axios calls, set the with credentials option to true for both get and post calls. If you are using fetch calls set the credentials option to include likewise.

// axios post
axios
    .post(`${url}`, {contentToBeSent}, {
      withCredentials: true
    })

// fetch get
fetch('https://example.com', {
  credentials: 'include'
});

I'll leave it to you to try JWT + Cookies for better security.

Feel free to reach out to me on basil_cea or on the threads below.

Remaining Stateless - Using Redis for token blacklisting in Node JS

Ogbonna Basil — Mon, 22 Jul 2019 09:27:25 +0000

JSON web tokens are stateless. That means the server does not maintain the state of the user. No information about who is sending a specific request is saved in the database or session. JWT provides a token to handle such authentication

A major drawback of not maintaining state is that a token is active until it's set expiration date. Therefore even if the user has logged out on the front-end and local storage cleared, anyone one having access to the token can access authenticated routes for that user until the token expires.

A number of solutions have been provided for this drawback:

Reducing the JWT expiration duration to a very short time and using refresh tokens with an expiration date or 2 weeks or longer. When the JWT expires, the refresh token is used to generate a new JWT for the user while the user is still logged in.
One major drawback to this is that the admin can revoke the refresh token at any time and if this happens at the time at the point where the JWT expires, the user has to log in again because you have both a revoked token and an expired JWT.
A second approach is to save a blacklisted token on logout in a column of the user table and use it for validation, destroying the previous token when it expires.
- This is not scalable.
- It defeats the whole purpose of JWT being stateless as the state is being maintained.
A third approach is to invalidate the token for all users by changing the JWT Secret Key. This is likely going to piss off all users as they all have to login again.
A fourth approach is to blacklist the token on logout in Redis

What is Redis

Redis is an in-memory data structure store used as a database, cache or message broker. You can use data structures like strings, hashes, lists, sets, sorted sets e.t.c

Why use in-memory instead of database

In-memory relies on main memory for computer data storage and are faster than database management systems that use disk-management systems because the internal optimization algorithms are simpler and execute fewer CPU instructions. Getting data in memory eliminates seek time when querying the data, which provides faster and more predictable performance than disk.
This is more scalable compared to using a DBMS.

Using Redis for validating token in Node

Install npm redis package
```
npm install redis  
```

Import Redis and use redisClient

import redis from redis  // ES6 +
import { exec} from 'child_process';// to start the redis database in development 
/*// for windows user import {execFile} from 'child_process';        
// for ES5 users
const redis = require('redis')*/
// if in development mode use Redis file attached
// start redis as a child process
if (process.env.NODE_ENV === 'development') {
const puts = (error, stdout) =>{
console.log(error)
console.log(stdout)
}
exec('redis/src/redis-server redis/redis.conf', puts);  
}
/* for window implementation 
execFile('redis/redis-server.exe',(error,stdout)=>{
if(error){
throw error
}
console.log(stdout)
})
*/
export const redisClient = redis.createClient(process.env.REDIS_URL);
// process.env.REDIS_URL is the redis url config variable name on heroku. 
// if local use redis.createClient()
redisClient.on('connect',()=>{
console.log('Redis client connected')
});
redisClient.on('error', (error)=>{
console.log('Redis not connected', error)
});

Use Redis for validating token.

Pass your Redis action as part of your authentication

import jwt from 'jsonwebtoken';
import pool from '../path/to/file';
import { redisClient } from '../path/to/file';
import 'dotenv';
const auth = {
// eslint-disable-next-line consistent-return
async checkToken(req, res, next) {
const token = req.headers.authorization.split(' ')[1]|| req.params.token;
// check if token exists
if (!token) {
  return res.status(401).send({
    status: 401,
    error: 'You need to Login',
  });
}
/* .......redis validation .........*/
try {

    const result = await redisClient.lrange('token',0,99999999)
    if(result.indexOf(token) > -1){
      return res.status(400).json({
        status: 400,
        error: 'Invalid Token'
    })
  }
   /*
     const invalid = (callback) => {
     redisClient.lrange('token', 0, 999999999, (err, result) => 
     callback(result));
  };
    invalid((result) => {
  // check if token has been blacklisted
     if (result.indexOf(token) > -1){
       return res.status(400).json({
        status: 400,
        error: 'Invalid Token',
     });
   }
})
*/
/* ...... ............................*/
 const decrypt = await jwt.verify(token, process.env.SECRET);
  const getUser = 'SELECT * FROM users WHERE id= $1';
  const { rows } = await pool.query(getUser, [decrypt.id]);
  // check if token has expired
  if (!rows[0]) {
    return res.status(403).json({
      status: 403,
      error: ' Token Not accessible',
    });
  }

  next();
} catch (error) {
  return res.status(501).json({
    status: 501,
    error: error.toString(),
  });
}
},
};
export default auth;

Explanation:

The Redis lrange function returns a list of tokens in the array. These token are tokens already blacklisted. if a token used is already blacklisted, the indexOf method returns a value of 0 and above and the 400 response.

Using Redis for Blacklisting in Node

To blacklist a token using Redis

Create a route for logout on the backend:

Usually, all that is required is to clear the token from local storage
on logging out but to blacklist the token an endpoint is needed to be
called on logout.

static async logout(req, res) {
    // logout user
    // save token in redis
    const token = req.headers.authorization.split(' ')[1];
    try {
        await redisClient.LPUSH('token', token);
        return res.status(200).json({
          'status': 200,
          'data': 'You are logged out',
        });
    } catch (error) {
      return res.status(400).json({
        'status': 500,
        'error': error.toString(),
      });
    }
  }

Explanation:

Redis LPUSH method is similar to the array push method. so basically you add the token to an array named 'token'. On clicking the logout button, the endpoint for the logout is called, the token blacklisted and local storage can then be cleared.

Conclusion:

Redis is a valuable tool. For more uses of Redis read its
documentation , especially caching.

A Redis implementation for Windows is available in this Redis folder.
Feel free to reach out to me on ob_cea or on the threads below.