Node.js Authentication With Twilio Verify
About The Author
Alexander Godwin is a Software Developer and writer that likes to write code and build things. Learning by doing is the best way and it’s how Alex helps …
More about
Godwin ↬
In this tutorial, you’ll learn how to integrate two-factor authentication into your Express.js application. You will build an express application that authenticates users using traditional password-based authentication with an extra layer of security using OTPs powered by the Twilio Verify service. You’ll learn how to build an express backend from scratch and implement authentication while learning about the MVC architecture. MongoDB is the database of choice, and the Ui is built using EJS. By the end of this tutorial, you’ll have a fully functional express application that implements OTPs and passwords for user authentication.
Building authentication into an application is a tedious task. However, making sure this authentication is bulletproof is even harder. As developers, it’s beyond our control what the users do with their passwords, how they protect them, who they give them to, or how they generate them, for that matter. All we can do is get close enough to ensure that the authentication request was made by our user and not someone else. OTPs certainly help with that, and services like Twilio Verify help us to generate secured OTPs quickly without having to bother about the logic.
What’s Wrong With Passwords?
There are several problems faced by developers when using password-based authentication alone since it has the following issues:
Enter OTPs
A one-time password (OTP) is a password or PIN valid for only one login session or transaction. Once it can only be used once, I’m sure you can already see how the usage of OTPs makes up for the shortcomings of traditional passwords.
OTPs add an extra layer of security to applications, which the traditional password authentication system cannot provide. OTPs are randomly generated and are only valid for a short period of time, avoiding several deficiencies that are associated with traditional password-based authentication.
OTPs can be used to substitute traditional passwords or reinforce the passwords using the two-factor authentication (2FA) approach. Basically, OTPs can be used wherever you need to ensure a user’s identity by relying on a personal communication medium owned by the user, such as phone, mail, and so on.
This article is for developers who want to learn about:
To achieve these objectives, we’ll build a full-stack application using node.js, express.js, EJS with authentication done using passport.js and protected routes that require OTPs for access.
Note: I’d like to mention that we’ll be using some 3rd-party (built by other people) packages in our application. This is a common practice, as there is no need to re-invent the wheel. Could we create our own node server? Yes, of course. However, that time could be better spent on building logic specifically for our application.
Table Of Contents
Requirements
Although we will be building the whole application from scratch, here’s the GitHub Repository for the project.
Basic Overview Of Authentication In Web Applications
What Is Authentication?
Authentication is the whole process of identifying a user and verifying that a user has an account on our application.
That being said, let’s see what authorization is about.
What Is Authorization?
Authorization at its most basic, is all about user permissions — what a user is allowed to do in the application. In other words:
The most common way of authenticating a user is via username and password.
Setting Up Our Application
To set up our application, we create our project directory:
Building An Express Server
We’ll be using Express.js to build our server.
Why Do We Need Express?
Building a server in Node could be tedious, but frameworks make things easier for us.
Express is the most popular Node web framework. It enables us to:
In addition to all of these, developers have created compatible middleware packages to address almost any web development problem.
In our authWithTwilioVerify directory, we initialize a package.json that holds information concerning our project.
In Keeping with the Model View Controller(MVC) architecture, we have to create the following folders in our authWithTwilioVerify directory:
Many developers have different reasons for using the MVC architecture, but for me personally, it’s because:
We need to install the following packages to build our app:
Add the script below in the package.json file to start our server using nodemon.
Create an index.js file and add the necessary packages for our app.
We have to require the installed packages into our index.js file so that our application runs well then we configure the packages as follows:
Let’s break down the segment of code above.
Apart from the require statements, we make use of the app.use() function — which enables us to use application level middleware.
Middleware functions are functions that have access to the request object, response object, and the next middleware function in the application’s request and response cycle.
It’s like handing the application state over to the middleware function, saying here’s the state, do what you want with it, and call the next() function to the next middleware.
Finally, we tell our application server to listen for requests to port 3000.
Then in the terminal run:
If you see app is running on port 3000 in the terminal, that means our application is running properly.
Integrating MongoDB Into Our Express Application
MongoDB stores data as documents. These documents are stored in MongoDB in JSON (JavaScript Object Notation) format. Since we’re using Node.js, it’s pretty easy to convert data stored in MongoDB to JavaScript objects and manipulate them.
To install MongoDB in your machine visit the MongoDB documentation.
In order to integrate MongoDB into our express application, we’ll be using Mongoose. Mongoose is an ODM(which is the acronym for object data mapper).
Basically, Mongoose makes it easier for us to use MongoDB in our application by creating a wrapper around Native MongoDB functions.
In index.js, it requires mongoose:
The mongoose.connect() function allows us to set up a connection to our MongoDB database using the connection string.
The format for the connection string is mongodb://localhost:27017/{database_name}.
mongodb://localhost:27017/ is MongoDB’s default host, and the database_name is whatever we wish to call our database.
Mongoose connects to the database called database_name. If it doesn’t exist, it creates a database with database_name and connects to it.
Mongoose.connect() is a promise, so it’s always a good practice to log a message to the console in the then() and catch() methods to let us know if the connection was successful or not.
We create our user model in our models directory:
user.js requires mongoose and create our user schema:
A schema provides a structure for our data. It shows how data should be structured in the database. Following the code segment above, we specify that a user object in the database should always have name, username, password, phonenumber, and email. Since those fields are required, if the data pushed into the database lack any of these required fields, mongoose throws an error.
Though you could create schemaless data in MongoDB, it is not advisable to do so — trust me, your data would be a mess. Besides, schemas are great. They allow you to dictate the structure and form of objects in your database — who wouldn’t want such powers?
More after jump! Continue reading below ↓ with useful tips on front-end, design & UX. Subscribe and
get “Smart Interface Design Checklists” — a
free PDF deck with 150+ questions to ask yourself when designing and building almost
anything.
Meet with useful tips on front-end, design & UX. Subscribe and get “Smart Interface Design Checklists” — a free PDF deck with 150+ questions to ask yourself when designing and building almost anything.
Encrypting Passwords
The reason we need to encrypt user passwords is this: in case someone somehow gains access to our database, we have some assurance that the user passwords are safe — because all this person would see would be a hash. This provides some level of security assurance, but a sophisticated hacker may still be able to crack this hash if they have the right tools. Hence the need for OTPs, but let’s focus on encrypting user passwords for now.
bcryptjs provides a way to encrypt and decrypt users’ passwords.
In models/user.js, it requires bcryptjs:
The code above does a couple of things. Let’s see them.
The userSchema.pre('save', callback) is a mongoose hook that allows us to manipulate data before saving it to the database. In the callback function, we return a promise which tries to hash(encrypt) bcrypt.hash() the password using the bcrypt.genSalt() we generated. If an error occurs during this hashing, we reject or we resolve by setting this.password = hash. this.password being the userSchema password.
Next, mongoose provides a way for us to append methods to schemas using the schema.methods.method_name. In our case, we’re creating a method that allows us to validate user passwords. Assigning a function value to *userSchema.methods.validPassword*, we can easily use bcryptjs compare method bcryprt.compare() to check if the password is correct or not.
bcrypt.compare() takes two arguments and a callback. The password is the password that is passed when calling the function, while this.password is the one from userSchema.
Hopefully, you can see the usefulness of mongoose. Besides creating a schema that gives structure to our database objects, it also provides nice methods for manipulating those objects — that would have been otherwise somewhat though using native MongoDB alone.
Building The Views Of Our Application Using EJS Templating Engine
Before we start building the views of our application, let’s take a look at the front-end architecture of our application.
Front-end Architecture
EJS is a templating engine that works with Express directly. There’s no need for a different front-end framework. EJS makes the passing of data very easy. It also makes it easier to keep track of what’s going on since there is no switching from back-end to front-end.
We’ll have a views directory, which will contain the files to be rendered in the browser. All we have to do is call the res.render() method from our controller. For example, if we wish to render the login page, it’s as simple as res.render('login'). We could also pass data to the views by adding an additional argument — which is an object to the render() method, like res.render('dashboard', { user }). Then, in our view, we could display the data with the evaluation syntax <%= %>. Everything with this tag is evaluated — for instance, <%= user.username %> displays the value of the username property of the user object. Aside from the evaluation syntax, EJS also provides a control syntax (<% %>), which allows us to write program control statements such as conditionals, loops, and so forth.
Basically, EJS allows us to embed JavaScript in our HTML.
In index.js, it requires express-ejs-layouts:
Then:
In views/layout.ejs,
The layout.ejs file serves like an index.html file, where we can include all our scripts and stylesheets. Then, in the div with classes ui container, we render the body — which is the rest of our application views.
We’ll be using semantic UI as our CSS framework.
Building The Partials
Partials are where we store re-usable code, so that we don’t have to rewrite them every single time. All we do is include them wherever they are needed.
For example, we want partials for our menu, so that we do not have to write code for it every single time we need the menu on our page.
We’ll create two files in the /views/partials folder:
In menu.ejs,
In message.ejs,
Building The Dashboard Page
In our views folder, we create a dashboard.ejs file:
Here, we include the menu partials so we have the menu on the page.
Building The Error Page
In our views folder, we create an error.ejs file:
Building The Home Page
In our views folder, we create a home.ejs file:
Building The Login Page
In our views folder, we create a login.ejs file:
Building The Verify Page
In our views folder, we create a login.ejs file:
Here, we provide a form for users to enter the verification code that will be sent to them.
Building The Sign Up Page
We need to get the user’s mobile number, and we all know that country codes differ from country to country. Therefore, we’ll use the [intl-tel-input](https://intl-tel-input.com/) to help us with the country codes and validation of phone numbers.
In our public folder, we create a css directory, js directory and img directory:
We copy the intlTelInput.css file from node_modules\intl-tel-input\build\css\ file into our public/css directory.
We copy both the intlTelInput.js and utils.js from node_modules\intl-tel-input\build\js\ folder into our public/js directory.
We copy both the flags.png and flags@2x.png from node_modules\intl-tel-input\build\img\ folder into our public/img directory.
We create an app.css in our public/css folder:
In app.css, add the styles below:
Finally, we create a signup.ejs file in our views folder:
Basic Authentication With Passport
Building authentication into an application can be really complex and time-draining, so we need a package to help us with that.
passport is a package that helps out with authentication in our express application.
passport has many strategies we could use, but we’ll be using the local-strategy — which basically does username and password authentication.
In index.js we add the following code:
We’re adding some application level middleware to our index.js file — which tells the application to use the passport.initialize() and the passport.session() middleware.
Passport.initialize() initializes passport, while the passport.session() middleware let’s passport know that we’re using session for authentication.
Do not worry much about the localAuth() function. That takes the passport object as an argument, and we’ll create the function just below.
Next, we create a config folder and create the needed files:
In passportLogic.js,
Let’s understand what is going on in the code above.
Apart from the require statements, we create the localAuth() function, which will be exported from the file. In the function, we call the passport.use() function that uses the LocalStrategy() for username and password based authentication.
We specify that our usernameField should be email. Then, we find a user that has that particular email — if none exists, then we return an error in the done() function. However, if a user exists, we check if the password is valid using the validPassword method on the User object. If it’s invalid, we return an error. Finally, if everything is successful, we return the user in done(null, user).
passport.serializeUser() and passport.deserializeUser() helps in order to support login sessions. Passport will serialize and deserialize user instances to and from the session.
In middleware.js,
Our middleware file contains two(2) route level middleware, which will be used later in our routes.
isLoggedIn and notLoggedIn are route level middleware that checks if a user is logged in. We use these middlewares to block access to routes that we want to make accessible to logged-in users.
Building The Sign-Up Controllers
In signUpController.js, we:
In loginController.js,
Right now, sendVerification() doesn’t exactly work. That’s because we’ve not written the function, so we need Twilio for that. Let’s install Twilio and get started.
Using Twilio Verify To Protect Routes
In order to use Twilio Verify, you:
To install the Twilio SDK for node.js:
Next, we need to install dotenv to help us with environment variables.
We create a file in the root of our project and name it .env. This file is where we keep our credentials, so we don’t push it to git. In order to do that, we create a .gitignore file in the root of our project, and add the following lines to the file:
This tells git to ignore both the node_modules folder and the .env file.
To get our Twilio account credentials, we login into our Twilio console, and copy our ACCOUNT SID and AUTH TOKEN. Then, we click on get trial number and Twilio generates a trial number for us, click accept number. Now from the console copy, we copy our trial number.
In .env,
Don’t forget to replace <YOUR_ACCOUNT_SID>, <YOUR_AUTH_TOKEN>, and <TOUR_TWILIO_NUMBER> with your actual credentials.
We create a file named twilioLogic.js in the config directory:
In twilioLogic.js,
In the code snippet above, we create a new verify service.
Run:
The string that gets logged to our screen is our TWILIO_VERIFICATION_SID — we copy that string.
In .env, add the line TWILIO_VERIFICATION_SID = <YOUR_TWILIO_VERIFICATION_SID>.
In config/twilioLogic.js, we remove the createService() line, since we need to create the verify service only once. Then, we add the following lines of code:
sendVerification is an asynchronous function that returns a promise that sends a verification OTP to the number provided using the sms channel.
checkVerification is also an asynchronous function that returns a promise that checks the status of the verification. It checks if the OTP provided by the users is the same OTP that was sent to them.
In config/middleware.js, add the following:
We’ve created two more route level middleware, which will be used later in our routes.
isVerified and notVerified check if a user is verified. We use these middlewares to block access to routes that we want to make accessible to only verified users.
In verifyController.js,
resendCode() re-sends the verification code to the user.
verifyUser uses the checkVerification function created in the previous section. If the status is approved, we set the verified value on req.session to true.
req.session just provides a nice way to access the current session. This is done by express-session, which adds the session object to our request object.
Building The User Routes
Basically, our application is going to have the following routes:
In routes/user.js, it requires the needed packages:
We’re creating our routes in the piece of code above, let’s see what’s going on here:
router.route() specifies the route. If we specify router.route('/login'), we target the login route. .all([middleware]) allows us specify that all request to that route should use those middleware.
The router.route('/login').all([middleware]).get(getController).post(postController) syntax is an alternative to the one most developers are used to.
It does the same thing as router.get('/login', [middleware], getController) and router.post('/login, [middleware], postController).
Now, if we run our application by typing the command below in our terminal:
Our full-stack express application should be up and running.
What we have done in this tutorial was to:
I surely hope that after this tutorial, you are ready to rethink your password-based authentication and add that extra layer of security to your application.
What you could do next:
This content was originally published here.
