NodeJS Posts

Overview

---

A Node.js library for use as Express middleware to secure endpoints with JWTs. The implementation uses a JWT endpoint of an Authorization Server to get the keys required for verification of the token signature. There is also an example Express app that shows how to use the library.

Package: https://www.npmjs.com/package/jsonwebtoken

Using the JSON web token, we can simply authenticate each and every request on our server. As a standard / best practice, we can use JWT (JSON web token) middleware to validate all requests.

JWT Middleware

---

  const jwt = require('jsonwebtoken')

  module.exports = (expectedRole) => (req, res, next) => {

  const authHeader = req.get('Authorization')
  if (!authHeader) {
    const error = new Error('Not authenticated.')
    error.statusCode = 401
    throw error
  }

  const token = authHeader.split(' ')[1]
  if (!token) {
    const error = new Error('Not authenticated.')
    error.statusCode = 401
    throw error
  }

  let decodedToken
  try {
    decodedToken = jwt.verify(token, process.env.SECRET_KEY)
  } catch (error) {
    error.statusCode = 401
    throw error
  }

  if (!decodedToken) {
    const error = new Error('Not authenticated.')
    error.statusCode = 401
    throw error
  }

  const role = decodedToken.role

  const authorised = expectedRole.includes(role)
  if (!authorised) {
    const error = new Error('Not authorised.')
    error.statusCode = 401
    throw error
  }

  req.user = decodedToken
  next()
}

This middleware has been prepared and exported. Therefore, we need to include it in our routes file and pass it to the expected role, so in our JWT middleware, we will validate the request with the JWT token, then verify that the user has access to an expected role (this role saved in the database) to this endpoint.

Routes File

---

 const express = require('express')
 const router = express.Router()

 const auth = require('./auth/index')
 const admin = require('./admin/index')
 const common = require('./common/index')
 const authorize = require('../middleware/jwtAuth')

 router.use('/auth', auth)
 router.use('/admin', authorize(['admin']), admin)
 router.use('/common', authorize(['admin', 'user']), common)

 module.exports = router 

Now that we have set up our authentication and authorization middleware in our routes, we are passing the required role to access these routes. These roles will be checked against our user role.

Our middleware simply next() the request if the user has a valid JWT token and is authorized to access this route, otherwise, it will throw the global error that is caught by the express global error handler.

There is no doubt that Node.Js is the most widely used JavaScript runtime environment, but Deno is more secure and offers more features.

Compare Deno and Node.js to see which is better for your next project, the purpose of this article is to introduce you to Deno and Node.js, their differences, and how to choose the right one for your upcoming project.

What is Node.js?

Created by Ryan Dahl in 2009, Node is a server-side JavaScript environment based on Google's V8 javascript engine and heavily focused on event-driven HTTP servers. This paradigm of JavaScript everywhere allowed the development of web applications using a single programming language by bringing server-side JavaScript to the mainstream.

At JSConf EU 2018, Ryan Dahl presented "10 Things I Regret About Node.js" - a talk titled "Design Mistakes in Node". In his talk, he details his regrets regarding some of the choices that were made in the development of Node.

In order to fix many of the design flaws mentioned at the talk, Ryan decided to introduce Deno, which ends support for legacy applications.

What is Deno?

Deno is a secure runtime for JavaScript and TypeScript that has been extended for JavaScript XML (JSX), and its TypeScript extension, TSX. Developed by the creator of Node.js, Deno is an attempt to reimagine Node to leverage advances in JavaScript since 2009, including the TypeScript compiler.

Like Node.js, Deno is essentially a shell around the Google V8 JavaScript engine. Unlike Node, it includes the TypeScript compiler in its executable image. Dahl, who created both runtimes, has said that Node.js suffers from three major issues: a poorly designed module system based on centralized distribution; lots of legacy APIs that must be supported, and a lack of security. These fixes are covered in Deno.

Can we use Node.js and Deno together?

Node.js or Deno are both excellent choices for server-side JavaScript projects. But is it possible to combine them? The answer to that is a definite "maybe."

The first thing to note is that Node packages from Deno often work just fine. Fortunately, there are workarounds for most of the common stumbling blocks. In addition, Deno standard library modules can be used to "polyfill" the built-in modules of Node; CDNs can be used to access npm packages in Deno-compatible ways, and import maps can be used. Additionally, Deno supports Node compatibility mode since version 1.15.

However, Node's plugin system does not work with Deno; Deno's Node compatibility mode does not support TypeScript, and a few Node modules (such as VM) do not work with Deno.

Here is a cheat sheet for Node users interested in switching to Deno.

Which to choose: Node.js or Deno?

Choosing the right technology for your use case depends on a variety of factors. Don't fix an existing Node.js deployment if it's not broken. My recommendation would be to strongly consider Deno if you intend to write a new TypeScript project. It's pretty hard to predict whether you're going to be successful without a proof-of-concept: Node.js packages are difficult to integrate with Deno without trying them out.