{"componentChunkName":"component---src-templates-blog-list-template-js","path":"/engineering/5","result":{"data":{"allMarkdownRemark":{"edges":[{"node":{"excerpt":"BigCommerce is a great eCommerce platform with rich features, and millions of people benefit from it. But there are limitations when you…","fields":{"slug":"/engineering/extend-ciam-capabilities-of-bigcommerce/"},"html":"

BigCommerce is a great eCommerce platform with rich features, and millions of people benefit from it. But there are limitations when you want to extend the platform for the following identity and access management requirements:

\n\n

Let’s talk about how you can extend BigCommerce and add on the above-mentioned features hassle-free.

\n

The answer is to utilize a CIAM (Consumer Identity and Access Management) that provides BigCommerce integration. You can easily configure and implement these features with minimal development effort using the CIAM provider. One such CIAM provider is LoginRadius.

\n

How to Implement These Features

\n

You are required to create an account with the CIAM provider, enable BigCommerce Integration, and do needed configurations in both BigCommerce and CIAM Provider. For more details, refer to this guide here.\nThis guide also explains the modifications required in your Stencil or Blueprint themes of BigCommerce. As a result of this implementation, you can enable the desired authentication method(s) for customers of your BigCommerce Application. Consequently, making the eCommerce experience smoother for your customers.

\n

Both customer and business will see several benefits (described below) from using CIAM solutions for features such as SSO, Phone Login, Prefilled Customer Information, and Analytics.

\n

Benefits of Implementing These Features

\n

Enhanced Customer Experience with SSO

\n

SSO lets customers log in with an existing identity. Allowing customers to use their existing identity increases conversions and return rates. It also improves security by allowing your customers to manage lesser digital identities and credentials.\nThe movement toward Bring Your Own Identity(BYOI) is gaining prominence as customers look to control their digital profiles, and SSO enables customers to bring their own digital identity.

\n

Increased Customer Engagement with Phone Login

\n

Phone login via OTP allows customers to easily log into their account without remembering a username or password. They only need to provide the Phone Number and then enter the received OTP to log in.

\n

This process makes sign-up and sign-in seamless for the customers and improves customer engagement. Also, businesses get fewer or no forgot password requests from customers, which reduces the support efforts.

\n

Improved Upsell and Cross-sell with Prefilled Information

\n

The top reason behind the cart abandonment is the long or confusing checkout process. Using the prefilled customer information with the LoginRadius Social Login feature, you can reduce the overall time involved in the checkout process.

\n

Prefilled customer information such as name, city, email address during checkout allows customers to place orders quickly.

\n

Let’s say a customer logged in using a social account and during checkout. With the customer’s permission, LoginRadius can retrieve basic information like name, email, birth date, gender from their social account. Thus, the customers need not enter data manually and experience a shorter and smoother checkout process.

\n

Insights Turned into Actions

\n

When you use LoginRadius as CIAM, it stores your customer data with your desired data centers. Also, LoginRadius Dashboard allows you to access the customer analytics related to identity, demographics, login, communication, etc. These analytics and charts help you understand your customers and their preferences better.

\n

For example:

\n\n

In addition to the benefits mentioned above, you experience below additional benefits:

\n\n

Conclusion

\n

Extending the capabilities of your great eCommerce platform is like a cherry on the cake. Signup for free and get in touch with us to take your eCommerce platform a level ahead.

\n","frontmatter":{"date":"January 27, 2022","updated_date":null,"description":"Want to add Phone Login or Single Sign-on for customers of your BigCommerce application? This article explains it all. Towards the end, it talks about how LoginRadius can help you improve upsell and cross-sell.","title":"4 Ways to Extend CIAM Capabilities of BigCommerce","tags":["BigCommerce","Authentication","CIAM"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/d145b262e248d51a28c0d8d8d731e1f2/ee604/4-ways-to-extend-ciam-capabilities.png","srcSet":"/static/d145b262e248d51a28c0d8d8d731e1f2/69585/4-ways-to-extend-ciam-capabilities.png 200w,\n/static/d145b262e248d51a28c0d8d8d731e1f2/497c6/4-ways-to-extend-ciam-capabilities.png 400w,\n/static/d145b262e248d51a28c0d8d8d731e1f2/ee604/4-ways-to-extend-ciam-capabilities.png 800w,\n/static/d145b262e248d51a28c0d8d8d731e1f2/f3583/4-ways-to-extend-ciam-capabilities.png 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Archna Yadav","github":null,"avatar":null}}}},{"node":{"excerpt":"Introduction Creating a user registration form employs the management of the registered user. This is where user role authentication comes…","fields":{"slug":"/engineering/guest-post/nodejs-authentication-guide/"},"html":"

Introduction

\n

Creating a user registration form employs the management of the registered user. This is where user role authentication comes into play. Role authentication ensures that non-admin users cannot make changes or access exclusive information. It grants administrative privileges to admin users and basic privileges to basic users.

\n

You can build your own authentication functionality with web tokens like JSON Web Token (JWT) or use a trusted third-party customer identity and access management (CIAM) software like LoginRadius.

\n

Goal

\n

This tutorial helps you:

\n\n

Prerequisites

\n

You have installed the following:

\n\n

You already understand JavaScript E56 Syntax.

\n

Now that everything is in place, let's set up your database.

\n

Set Up a Mongo Database

\n

You'll store all your user data — which includes username, password, and role — in MongoDB.

\n

Install a node package called Mongoose that will connect to MongoDB. Then create a user schema for your application.

\n
npm init\nnpm install mongoose
\n

npm init sets up your new project and creates a package.json file with the credentials.

\n

After installing mongoose, create a new file db.js in the project's directory and require mongoose.

\n
const Mongoose = require("mongoose")
\n

With the help of mongoose, you can connect your application to MongoDB:

\n
// db.js\nconst Mongoose = require("mongoose")\nconst localDB = `mongodb://localhost:27017/role_auth`\nconst connectDB = async () => {\n  await Mongoose.connect(localDB, {\n    useNewUrlParser: true,\n    useUnifiedTopology: true,\n  })\n  console.log("MongoDB Connected")\n}\nmodule.exports = connectDB
\n

The code snippet here connects to mongodb://localhost:27017 and then specifies the name of the database /role_auth.

\n

The function connectDB awaits for the connection, which contains the URI and options as a second parameter. If it connects without errors, it will log out MongoDB Connected. Error issues will be fixed while connecting to the database. After this, it exported the function for use in the server.

\n

Set Up the Server

\n

You need to install some dependencies that you'll use in this tutorial.

\n
  npm i express nodemon
\n

Express.js is a Node.js framework for building web applications quickly and easily.

\n

Nodemon is a tool that watches the file system and automatically restarts the server when there is a change.

\n

You require express in your application to listen for a connection on port 5000. Create a new file server.js in the root directory and create the listening event:

\n
const express = require("express")\nconst app = express()\nconst PORT = 5000\napp.listen(PORT, () => console.log(`Server Connected to port ${PORT}`))
\n

The next step is to test your application. Open up your package.json file and add the following to scripts:

\n
"scripts": {\n  "start": "node server.js",\n  "dev": "nodemon server.js"\n}
\n

Open your terminal and run npm run dev to start the server.

\n

Connect to the Database

\n

Earlier, you've created a function that connects to MongoDB and exported that function. Now import that function into your server.js:

\n
const connectDB = require("./db");\n...\n//Connecting the Database\nconnectDB();
\n

You also need to create an error handler that catches every unhandledRejection error.

\n
const server = app.listen(PORT, () =>\n  console.log(`Server Connected to port ${PORT}`)\n)\n// Handling Error\nprocess.on("unhandledRejection", err => {\n  console.log(`An error occurred: ${err.message}`)\n  server.close(() => process.exit(1))\n})
\n

The listening event is assigned to a constant server. If an unhandledRejection error occurs, it logs out the error and closes the server with an exit code of 1.

\n

Create User Schema

\n

Schema is like a blueprint that shows how the database will be constructed.

\n

You'll structure a user schema that contains username, password, and role.

\n

Create a new folder model in the project's directory, and create a file called User.js. Now open User.js and create the user schema:

\n
// user.js\nconst Mongoose = require("mongoose")\nconst UserSchema = new Mongoose.Schema({\n  username: {\n    type: String,\n    unique: true,\n    required: true,\n  },\n  password: {\n    type: String,\n    minlength: 6,\n    required: true,\n  },\n  role: {\n    type: String,\n    default: "Basic",\n    required: true,\n  },\n})
\n

In the schema, the username will be unique, required, and will accept strings.

\n

You've specified the minimum characters(6) the password field will accept. The role field grants a default value (basic) that you can change if needed.

\n

Now, you need to create a user model and export it:

\n
const User = Mongoose.model("user", UserSchema)\nmodule.exports = User
\n

You've created the user model by passing the UserSchema as the second argument while the first argument is the name of the model user.

\n

Perform CRUD Operations

\n

You'll create functions that handle:

\n\n

Register Function

\n

As the name implies, this function will handle the registrations of users.

\n

Let's create a new folder named Auth. It will contain the Authentication file and the Route set-up file.

\n

After creating the Auth folder, add two files — Auth.js and Route.js.

\n

Now open up our Auth.js file and import that User model:

\n
const User = require("../model/User")
\n

The next step is to create an async express function that will take the user's data and register it in the database.

\n

You need to use an Express middleware function that will grant access to the user's data from the body. You'll use this function in the server.js file:

\n
const app = express()\napp.use(express.json())
\n

Let's go back to your Auth.js file and create the register function:

\n
// auth.js\nexports.register = async (req, res, next) => {\n  const { username, password } = req.body\n  if (password.length < 6) {\n    return res.status(400).json({ message: "Password less than 6 characters" })\n  }\n  try {\n    await User.create({\n      username,\n      password,\n    }).then(user =>\n      res.status(200).json({\n        message: "User successfully created",\n        user,\n      })\n    )\n  } catch (err) {\n    res.status(401).json({\n      message: "User not successful created",\n      error: error.mesage,\n    })\n  }\n}
\n

The exported register function will be used to set up the routes. You got the username and password from the req.body and created a tryCatch block that will create the user if successful; else, it returns status code 401 with the error message.

\n

Set Up Register Route

\n

You'll create a route to /register using express.Router. Import the register function into your route.js file, and use it as the route's function:

\n
const express = require("express")\nconst router = express.Router()\nconst { register } = require("./auth")\nrouter.route("/register").post(register)\nmodule.exports = router
\n

The last step is to import your route.js file as middleware in server.js:

\n
app.use("/api/auth", require("./Auth/route"))
\n

The server will use the router middleware function if there is a request to /api/auth.

\n

Test the Register Route

\n

You'll use Postman to test all the routes.

\n

Open up Postman to send a POST request to http://localhost:5000/api/auth/register and pass the username and password to the body:

\n

\n \n

Open the Auth.js file and create the Login function, as follows:

\n
// auth.js\nexports.login = async (req, res, next) => {\n  const { username, password } = req.body\n  // Check if username and password is provided\n  if (!username || !password) {\n    return res.status(400).json({\n      message: "Username or Password not present",\n    })\n  }\n}
\n

The login function returns status code 400 if the username and password were not provided. You need to find a user with the provided username and password:

\n
exports.login = async (req, res, next) => {\n  try {\n    const user = await User.findOne({ username, password })\n    if (!user) {\n      res.status(401).json({\n        message: "Login not successful",\n        error: "User not found",\n      })\n    } else {\n      res.status(200).json({\n        message: "Login successful",\n        user,\n      })\n    }\n  } catch (error) {\n    res.status(400).json({\n      message: "An error occurred",\n      error: error.message,\n    })\n  }\n}
\n

Here, it returns status code 401 when a user isn't found and 200 when a user is found. The code snippet wrapped all this in a tryCatch block to detect and output errors, if any.

\n

Set Up Login Route

\n

To set up the login route, import the login function into your route.js:

\n
const express = require("express");\nconst router = express.Router();\nconst { register, login } = require("./auth");\n...\nrouter.route("/login").post(login);\nmodule.exports = router;
\n

Test the Login Route

\n

Make a POST request at http://localhost:5000/api/auth/login and pass a valid username and password to the body:

\n

\n \n \n

\n

Update Function

\n

This function will be responsibile for updating the role of a basic user to an admin user. Open the auth.js file and create the update function, as follows:

\n
//auth.js\nexports.update = async (req, res, next) => {\n  const { role, id } = req.body\n  // Verifying if role and id is presnt\n  if (role && id) {\n    // Verifying if the value of role is admin\n    if (role === "admin") {\n      await User.findById(id)\n    } else {\n      res.status(400).json({\n        message: "Role is not admin",\n      })\n    }\n  } else {\n    res.status(400).json({ message: "Role or Id not present" })\n  }\n}
\n

The first if statement verifies if role and id are present in the request body.

\n

The second if statement checks if the value of role is admin. You should do this to avoid having over two roles.

\n

After finding a user with that ID, you'll create a third if block that will check for the role of the user:

\n
exports.update = async (req, res, next) => {\n  const { role, id } = req.body;\n  // First - Verifying if role and id is presnt\n  if (role && id) {\n    // Second - Verifying if the value of role is admin\n    if (role === "admin") {\n      // Finds the user with the id\n      await User.findById(id)\n        .then((user) => {\n          // Third - Verifies the user is not an admin\n          if (user.role !== "admin") {\n            user.role = role;\n            user.save((err) => {\n              //Monogodb error checker\n              if (err) {\n                res\n                  .status("400")\n                  .json({ message: "An error occurred", error: err.message });\n                process.exit(1);\n              }\n              res.status("201").json({ message: "Update successful", user });\n            });\n          } else {\n            res.status(400).json({ message: "User is already an Admin" });\n          }\n        })\n        .catch((error) => {\n          res\n            .status(400)\n            .json({ message: "An error occurred", error: error.message });\n        });\n\n       ...
\n

The third if block prevents assigning an admin role to an admin user, while the last if block checks if an error occurred when saving the role in the database.

\n
\n

The numerous if statements might be a little bit tricky but understandable. Please read the comments in the above code block for better understanding.

\n
\n

Set Up Update Route

\n

Import the update function in your route.js, as follows:

\n
const { register, login, update } = require("./auth");\n...\nrouter.route("/update").put(update);
\n

Testing the Update Route

\n

Send a put request to http://localhost:5000/api/auth/update:

\n

\n auth.js file:

\n
exports.deleteUser = async (req, res, next) => {\n  const { id } = req.body\n  await User.findById(id)\n    .then(user => user.remove())\n    .then(user =>\n      res.status(201).json({ message: "User successfully deleted", user })\n    )\n    .catch(error =>\n      res\n        .status(400)\n        .json({ message: "An error occurred", error: error.message })\n    )\n}
\n

You remove the user based on the id you get from req.body.

\n

Set up the deleteUser Route

\n

Open your route.js file to create a delete request to /deleteUser, using the deleteUser as its function:

\n
const { register, login, update, deleteUser } = require("./auth");\n...\nrouter.route("/deleteUser").delete(deleteUser);
\n

Test the deleteUser Route

\n

Send a delete request to http://localhost:5000/api/auth/deleteUser by passing a valid id to the body:

\n

\n \n \n

\n

Hash User Passwords

\n

Saving user passwords in the database in plain text format is reckless. It is preferable to hash your password before storing it.

\n

For instance, it will be tough to decipher the passwords in your database if they are leaked. Hashing passwords is a cautious and reliable practice.

\n

Let's use bcryptjs to hash your user passwords.

\n

Lets install bcryptjs:

\n
npm i bcryptjs
\n

After installing bcryptjs, import it into your auth.js

\n
const bcrypt = require("bcryptjs")
\n

Refactor Register Function

\n

Instead of sending a plain text format to your database, lets hash the password using bcrypt:

\n
exports.register = async (req, res, next) => {\n  const { username, password } = req.body;\n\n  ...\n\n  bcrypt.hash(password, 10).then(async (hash) => {\n    await User.create({\n      username,\n      password: hash,\n    })\n      .then((user) =>\n        res.status(200).json({\n          message: "User successfully created",\n           user,\n        })\n      )\n      .catch((error) =>\n        res.status(400).json({\n          message: "User not successful created",\n          error: error.message,\n        })\n      );\n  });\n};
\n

bcrypt takes in your password as the first argument and the number of times it will hash the password as the second argument. Passing a large number will take bcrypt a long time to hash the password, so give a moderate number like 10.

\n

bcrypt will return a promise with the hashed password; then, send that hashed password to the database.

\n

Test the Register Function

\n

Send a POST request to http://localhost:5000/api/auth/register and pass the username and password to the body:

\n

\n \n \n

\n

Authenticate Users with JSON Web Token (JWT)

\n

JSON Web Token helps shield a route from an unauthenticated user. Using JWT in your application will prevent unauthenticated users from accessing your users' home page and prevent unauthorized users from accessing your admin page.

\n

JWT creates a token, sends it to the client, and then the client uses the token for making requests. It also helps verify that you're a valid user making those requests.

\n

You've to install JWT before using it in your application:

\n
npm i jsonwebtoken
\n

Refactor the Register Function

\n

When a user registers, you'll send a token to the client using JWT as a cookie. To create this token, you need to set a secret string. You'll use the node's in-built package called crypto to create random strings:

\n
node\nrequire("crypto").randomBytes(35).toString("hex")
\n

Output:

\n

\n \n \n

\n

Storing this secret string in an environment variable is a safe practice. If this secret string is leaked, unauthenticated users can create fake tokens to access the route.

\n

Store your secret string in a variable:

\n
const jwtSecret =\n  "4715aed3c946f7b0a38e6b534a9583628d84e96d10fbc04700770d572af3dce43625dd"
\n

Once you've created your jwtSecret, import jsonwebtoken as the token in the register function:

\n
...\nconst jwt = require('jsonwebtoken')\nconst jwtSecret = '4715aed3c946f7b0a38e6b534a9583628d84e96d10fbc04700770d572af3dce43625dd'\nexports.register = async (req, res, next) => {\n  const { username, password } = req.body;\n\n  ...\n\n  bcrypt.hash(password, 10).then(async (hash) => {\n    await User.create({\n      username,\n      password: hash,\n    })\n      .then((user) => {\n        const maxAge = 3 * 60 * 60;\n        const token = jwt.sign(\n          { id: user._id, username, role: user.role },\n          jwtSecret,\n          {\n            expiresIn: maxAge, // 3hrs in sec\n          }\n        );\n        res.cookie("jwt", token, {\n          httpOnly: true,\n          maxAge: maxAge * 1000, // 3hrs in ms\n        });\n        res.status(201).json({\n          message: "User successfully created",\n          user: user._id,\n        });\n      })\n      .catch((error) =>\n        res.status(400).json({\n          message: "User not successful created",\n          error: error.message,\n        })\n      );\n  });\n};
\n

The code snippet created the token using JWT's sign function. This function takes in three parameters:

\n\n

After passing all these arguments, JWT will generate a token. After the token is generated, send it as a cookie to the client.

\n

Refactor the Login Function

\n

Also, generate a token for logged in users:

\n
exports.login = async (req, res, next) => {\n\n    ...\n\n      bcrypt.compare(password, user.password).then(function (result) {\n        if (result) {\n          const maxAge = 3 * 60 * 60;\n          const token = jwt.sign(\n            { id: user._id, username, role: user.role },\n            jwtSecret,\n            {\n              expiresIn: maxAge, // 3hrs in sec\n            }\n          );\n          res.cookie("jwt", token, {\n            httpOnly: true,\n            maxAge: maxAge * 1000, // 3hrs in ms\n          });\n          res.status(201).json({\n            message: "User successfully Logged in",\n            user: user._id,\n          });\n        } else {\n          res.status(400).json({ message: "Login not succesful" });\n        }\n      });\n    }\n  } catch (error) {\n    res.status(400).json({\n      message: "An error occurred",\n      error: error.message,\n    });\n  }\n};
\n

Protect the Routes

\n

To prevent unauthenticated users from accessing the private route, take the token from the cookie, verify the token, and redirect users based on role.

\n

You'll get the token from the client using a node package called cookie-parser. Let's install the package before using it:

\n
npm i cookie-parser
\n

After installing it, import it into your server.js file and use it as a middleware:

\n
const cookieParser = require("cookie-parser");\n...\napp.use(cookieParser());
\n

You'll create your middleware that verifies the token and grants access to your private route.

\n

Let's create a new folder in the project's folder named middleware and create a file called auth.js.

\n

Admin Authentication

\n

Open the auth.js file and create the middleware:

\n
const jwt = require("jsonwebtoken")\nconst jwtSecret =\n  "4715aed3c946f7b0a38e6b534a9583628d84e96d10fbc04700770d572af3dce43625dd"\nexports.adminAuth = (req, res, next) => {\n  const token = req.cookies.jwt\n  if (token) {\n    jwt.verify(token, jwtSecret, (err, decodedToken) => {\n      if (err) {\n        return res.status(401).json({ message: "Not authorized" })\n      } else {\n        if (decodedToken.role !== "admin") {\n          return res.status(401).json({ message: "Not authorized" })\n        } else {\n          next()\n        }\n      }\n    })\n  } else {\n    return res\n      .status(401)\n      .json({ message: "Not authorized, token not available" })\n  }\n}
\n

The code snippet requests a token from the client, checks if a token is available, and verifies that token.

\n

JWT verifies your token with your jwtSecret and returns a callback function. This function returns status code 401 if the token fails the authentication test.

\n

When you've created the token, you passed a payload that contained the user's credentials. You'll get the role from the credentials and check if the user's role is admin. If the user is not an admin, you return status code 401, but you'll call the next function if the user is an admin.

\n

Basic User Authentication

\n

You'll also authenticate basic users before granting them access to the users route. Let's create another middleware in your auth.js file that will authenticate basic users:

\n
exports.userAuth = (req, res, next) => {\n  const token = req.cookies.jwt\n  if (token) {\n    jwt.verify(token, jwtSecret, (err, decodedToken) => {\n      if (err) {\n        return res.status(401).json({ message: "Not authorized" })\n      } else {\n        if (decodedToken.role !== "Basic") {\n          return res.status(401).json({ message: "Not authorized" })\n        } else {\n          next()\n        }\n      }\n    })\n  } else {\n    return res\n      .status(401)\n      .json({ message: "Not authorized, token not available" })\n  }\n}
\n

Protect the Routes

\n

You'll have two routes: one for the user and the other for the admin. Let's import this middleware into your server.js file and protect your routes:

\n
const { adminAuth, userAuth } = require("./middleware/auth.js");\n...\napp.get("/admin", adminAuth, (req, res) => res.send("Admin Route"));\napp.get("/basic", userAuth, (req, res) => res.send("User Route"));
\n

Updating user roles and deleting users should be done by an Admin, so you need to import this auth.js middleware into your route.js file to protect the update and delete routes.

\n

route.js:

\n
const { adminAuth } = require("../middleware/auth")\nrouter.route("/update").put(adminAuth, update)\nrouter.route("/deleteUser").delete(adminAuth, deleteUser)
\n

Populate the Database with Admin User

\n

You need to create an admin user in your database. Open up your terminal, and let's run some MongoDB methods:

\n
mongo
\n

After mongo is started, you need to use the role_auth database:

\n
use role_auth
\n

Before adding your admin user to the database, you need to hash the password using bcrypt in the node terminal. Open node terminal in your project's directory:

\n
const password = require("bcryptjs").hash("admin", 10)\npassword
\n

After you've created the constant password, you need to enter the password in the node terminal to get your hashed password.

\n

\n \n \n

\n

You'll use the hashed password to create your admin:

\n
db.users.insert({\n  username: "admin",\n  password: "$2a$10$mZwU9AbYSyX7E1A6fu/ZO.BDhmCOIK7k6jXvKcuJm93PyYuH2eZ3K",\n  role: "admin",\n})
\n

To check if it was successfully created, run db.users.find().pretty() — this will output all users in the database.

\n

Create the Login Form Using EJS

\n

You'll use Embedded JavaScript (EJS) to create a front-end for your application.

\n

Install the ejs package:

\n
    npm i ejs
\n

After you've installed ejs, you need to set ejs as your default view engine in your server.js file:

\n
app.set("view engine", "ejs")
\n

Render Embedded JavaScript

\n

When making a GET request to specific routes, you'll render an ejs file:

\n
app.get("/", (req, res) => res.render("home"))\napp.get("/register", (req, res) => res.render("register"))\napp.get("/login", (req, res) => res.render("login"))\napp.get("/admin", adminAuth, (req, res) => res.render("admin"))\napp.get("/basic", userAuth, (req, res) => res.render("user"))
\n

Create EJS Files

\n

By default, your application will look into the views folder when rendering an ejs file. You need to create the views folder in your project's folder and add your ejs files to it

\n

Create a Home Page

\n

Your home page will contain the links to /login and /register ejs file. Open up home.ejs and add these links:

\n
<!DOCTYPE html>\n<html lang="en">\n  <head>\n    <meta charset="UTF-8" />\n    <meta name="viewport" content="width=device-width, initial-scale=1.0" />\n    <title>Home page</title>\n  </head>\n  <body>\n    <h1>Home Page</h1>\n    <a href="/register"> Register</a> <br />\n    <a href="/login">Login</a>\n  </body>\n</html>
\n

Create a Registration Form

\n

Embedded JavaScript (EJS) supports HTML syntax. You'll create the registration form in register.ejs using HTML syntax:

\n
<!DOCTYPE html>\n<html lang="en">\n  <head>\n    <meta charset="UTF-8" />\n    <meta name="viewport" content="width=device-width, initial-scale=1.0" />\n    <title>Register Page</title>\n  </head>\n  <body>\n    <h1>Register Page</h1>\n    <form>\n      <div class="error" style="background-color: red;"></div>\n      <br />\n      <label for="username">Username</label><br />\n      <input type="text" id="username" required /><br />\n      <label for="password">Password</label><br />\n      <input type="password" id="password" required /><br />\n      <input type="submit" value="register" /><br />\n    </form>\n    <a href="/login">Already registered? Login</a>\n  </body>\n</html>
\n

Add POST Request Functionality

\n

You need to get the username and password that the user entered and pass it to the body when making the POST request:

\n
...\n<script>\n  const form = document.querySelector('form')\n  const username = document.querySelector('#username')\n  const password = document.querySelector('#password')\n  const display = document.querySelector('.error')\n  form.addEventListener('submit', async (e) => {\n     e.preventDefault()\n     display.textContent = ''\n     try {\n       const res = await fetch('/api/auth/register', {\n       method: 'POST',\n        body: JSON.stringify({ username: username.value, password: password.value }),\n       headers: { 'Content-Type': 'application/json' }\n       })\n       const data = await res.json()\n       if(res.status === 400 || res.status === 401){\n        return display.textContent = `${data.message}. ${data.error ? data.error : ''}`\n       }\n       data.role === "admin" ? location.assign('/admin') : location.assign('/basic')\n        } catch (err) {\n          console.log(err.message)\n        }\n      })\n</script>\n</body>\n</html>
\n

The code snippet uses JavaScript's in-built library called fetch to send a POST request to /api/auth/register.

\n

After the request has been sent, it stores the response to a constant res.

\n

res.json will return the JSON you've passed as a response in the API.

\n

When res.json returns the data, you store that data in a constant data.

\n

If you get an error while making the request, display the error to the user. If an error isn't found, redirect the user based on their role on different routes.

\n

Create a Login Form

\n

Creating your login form and adding functionality to it will be similar to that of your registration. Open login.ejs and create this form:

\n
<!DOCTYPE html>\n<html lang="en">\n  <head>\n    <meta charset="UTF-8" />\n    <meta name="viewport" content="width=device-width, initial-scale=1.0" />\n    <title>Login Page</title>\n  </head>\n  <body>\n    <h1>Login Page</h1>\n    <form>\n      <div class="error" style="background-color: red;"></div>\n      <br />\n      <label for="username">Username</label><br />\n      <input type="text" id="username" required /><br />\n      <label for="password">Password</label><br />\n      <input type="password" id="password" required /><br />\n      <input type="submit" value="login" /><br />\n    </form>\n    <a href="/register">Don't have an accout? Register</a>\n  </body>\n</html>
\n

Add POST Request Functionality

\n
    <script>\n      const form = document.querySelector('form')\n      const username = document.querySelector('#username')\n      const password = document.querySelector('#password')\n      const display = document.querySelector('.error')\n      form.addEventListener('submit', async (e) => {\n        e.preventDefault()\n        display.textContent = ''\n        try {\n          const res = await fetch('/api/auth/login', {\n            method: 'POST',\n            body: JSON.stringify({ username: username.value, password: password.value }),\n            headers: { 'Content-Type': 'application/json' }\n            })\n          const data = await res.json()\n          if (res.status === 400 || res.status === 401) {\n            return display.textContent = `${data.message}. ${data.error ? data.error : ''}`\n          }\n          data.role === "admin" ? location.assign('/admin') : location.assign('/basic')\n        } catch (err) {\n            console.log(err.message)\n          }\n\n        })\n      </script>\n    </body>\n    </html>
\n

Add Registered Users to the Route

\n

Once you've redirected users based on role to different routes, display all registered users on that route. You need to send a GET request to /getUsers.

\n

Open auth.js file in Auth folder:

\n
exports.getUsers = async (req, res, next) => {\n  await User.find({})\n    .then(users => {\n      const userFunction = users.map(user => {\n        const container = {}\n        container.username = user.username\n        container.role = user.role\n        return container\n      })\n      res.status(200).json({ user: userFunction })\n    })\n    .catch(err =>\n      res.status(401).json({ message: "Not successful", error: err.message })\n    )\n}
\n

The User.find method returns an array of users. After mapping through this array, it stores the username and role in the constant container and returns the container.

\n

Display Registered User in user Route

\n

You've rendered user.ejs when accessing the /user route. Now, you'll display all registered users to that route.

\n

user.ejs:

\n
<!DOCTYPE html>\n<html lang="en">\n  <head>\n    <meta charset="UTF-8" />\n    <meta http-equiv="X-UA-Compatible" content="IE=edge" />\n    <meta name="viewport" content="width=device-width, initial-scale=1.0" />\n    <title>User page</title>\n  </head>\n  <body>\n    <h1>Users</h1>\n    <ul></ul>\n    <script>\n      const ul = document.querySelector("ul")\n      const getUsers = async () => {\n        const res = await fetch("/api/auth/getUsers")\n        const data = await res.json()\n        data.user.map(mappedUser => {\n          if (mappedUser.username !== "admin") {\n            let li = `<li> <b>Username</b> => ${mappedUser.username} <br> <b>Role</b> => ${mappedUser.role} </li>`\n            ul.innerHTML += li\n          } else {\n            return null\n          }\n        })\n      }\n      getUsers()\n    </script>\n  </body>\n</html>
\n

Add Update and Delete Function to the Admin Route

\n

You'll also display registered users to the admin route but add update and delete functionality to the route:

\n

admin.ejs:

\n
<!DOCTYPE html>\n<html lang="en">\n  <head>\n    <meta charset="UTF-8" />\n    <meta http-equiv="X-UA-Compatible" content="IE=edge" />\n    <meta name="viewport" content="width=device-width, initial-scale=1.0" />\n    <title>Admin page</title>\n  </head>\n  <body>\n    <div class="display" style="background-color: red;"></div>\n    <h1>Users</h1>\n    <ul></ul>\n    <script>\n      const ul = document.querySelector("ul")\n      const display = document.querySelector(".display")\n      const getUsers = async () => {\n        const res = await fetch("/api/auth/getUsers")\n        const data = await res.json()\n        data.user.map(mappedUser => {\n          if (mappedUser.username !== "admin") {\n            let li = `<li> <b>Username</b> => ${mappedUser.username} <br> <b>Role</b> => ${mappedUser.role} </li> <button class="edit">Edit Role</button> <button class="delete">Delete User</button>`\n            ul.innerHTML += li\n          } else {\n            return null\n          }\n          const editRole = document.querySelectorAll(".edit")\n          const deleteUser = document.querySelector(".delete")\n        })\n      }\n      getUsers()\n    </script>\n  </body>\n</html>
\n

Edit a User's Role

\n

You'll create an event listener that will listen for a click on the Edit Role button. When the button is clicked, you'll send a PUT request to /api/auth/update:

\n
<script>\n\n    ...\n\n    const editRole = document.querySelectorAll('.edit')\n    const deleteUser = document.querySelector('.delete')\n  editRole.forEach((button, i) => {\n    button.addEventListener('click', async() => {\n      display.textContent= ''\n      const id = data.user[i+1].id\n      const res = await fetch('/api/auth/update', {\n      method: 'PUT',\n      body: JSON.stringify({ role: 'admin', id}),\n      headers: { 'Content-Type': 'application/json' }\n      })\n      const dataUpdate = await res.json()\n      if (res.status === 400 || res.status === 401) {\n        document.body.scrollTop = 0\n        document.documentElement.scrollTop = 0\n        return display.textContent = `${dataUpdate.message}. ${dataUpdate.error ? dataUpdate.error : ''}`\n      }\n      location.assign('/admin')\n      })\n    });\n\n      ...\n</script>
\n

Delete Users

\n

Deleting Users from the database should be the duty of an admin.

\n

admin.ejs:

\n
<script>\n\n  ...\n\n  const editRole = document.querySelectorAll('.edit')\n  const deleteUser = document.querySelector('.delete')\n  deleteUser.forEach((button, i)=> {\n   button.addEventListener('click', async ()=> {\n   display.textContent =''\n   const id = data.user[i+1].id\n   const res = await fetch('/api/auth/deleteUser', {\n     method: 'DELETE',\n     body: JSON.stringify({id}),\n     headers: {'Content-Type': 'application/json'}\n     })\n   const dataDelete = await res.json()\n   if (res.status === 401){\n     document.body.scrollTop = 0\n     document.documentElement.scrollTop = 0\n     return display.textContent = `${dataUpdate.message}. ${dataUpdate.error ? dataUpdate.error : ''}`\n   }\n   location.assign('/admin')\n    })\n  })\n\n   ...\n</script>
\n

You've created an event listener that listens for a click on the Delete User button. When the button is clicked, you'll send a DELETE request to /api/auth/deleteUser.

\n
\n

Please ensure the admin user is first on the list to avoid populating the database with an admin user again.

\n
\n

Logout Functionality

\n

To log out users, you need to remove the token from the client and redirect the client to the home page.

\n

You'll create a GET request to /logout in the server.js file:

\n
app.get("/logout", (req, res) => {\n  res.cookie("jwt", "", { maxAge: "1" })\n  res.redirect("/")\n})
\n

The code snippet replaced the JWT token with an empty string and gave it a lifespan of 1 second.

\n

After creating the GET request, add a logout button to the admin's route and user's route:

\n
...\n<ul></ul>\n<button class="logout"><a href="/logout">Log Out</a></button>\n...
\n

Node.js Authentication with LoginRadius

\n

You can simply replace the many steps discussed above using LoginRadius. In turn, it helps you focus more on developing core application features while letting you quickly implement user signup and login and manager users.

\n

In other words, LoginRadius is a SaaS-based customer identity and access management (CIAM) system with features to manage customer identity, privacy, and access. It is a simple, implementable solution for adding user authentication and authorization to your website.

\n

Basically, LoginRadius handles user registration, login, and authentication. Other features of LoginRadius include:

\n\n

To get started with LoginRadius, you need to create an account with either the free plan or the Developer plan, customize your registration and login forms, and start managing your users.

\n

How to Authenticate Your Node.js App with LoginRadius

\n

This section briefly covers how authentication works with LoginRadius.

\n

After signing up for LoginRadius, choose a name for your Node.js app.

\n
\n

\n \n \n

\n
\n

After completing your LoginRadius signup process, you can get your App Name, API Key, and API Secret from the configuration link on the sidebar. With these configurations, you can easily link the server-side of our application to LoginRadius.

\n

\n \n \n

\n

LoginRadius automatically generates a link that will be used to authenticate users. This link contains the name of your LoginRadius application and a URL that authenticated users will be redirected to:

\n
https://<LoginRadius-APP-Name>.hub.loginradius.com/auth.aspx?action=login&return_url=<Return-URL>
\n

An instance of the link is given below:

\n
https://noderoleauth.hub.loginradius.com/auth.aspx?action=login&return_url=http://localhost:5000
\n

Conclusion

\n

You've successfully learned how to perform CRUD operations using MongoDB as a database, hash passwords, authenticate using JWT, and render Embedded JavaScript (EJS). You can put all these together to build more complex applications.

\n

Resources

\n\n","frontmatter":{"date":"January 18, 2022","updated_date":null,"description":"Want to authenticate and manage users with specific roles in your Node.js app? This in-depth tutorial explains everything step-by-step to help you implement authentication in your Node.js apps.","title":"Node.js User Authentication Guide","tags":["JWT","Authentication","Node.js"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.9047619047619047,"src":"/static/2bf56fe9f3665d6ea50e762f073b6531/14b42/coverimage.jpg","srcSet":"/static/2bf56fe9f3665d6ea50e762f073b6531/f836f/coverimage.jpg 200w,\n/static/2bf56fe9f3665d6ea50e762f073b6531/2244e/coverimage.jpg 400w,\n/static/2bf56fe9f3665d6ea50e762f073b6531/14b42/coverimage.jpg 800w,\n/static/2bf56fe9f3665d6ea50e762f073b6531/235b6/coverimage.jpg 1034w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Uma Victor","github":"uma-victor1","avatar":null}}}},{"node":{"excerpt":"In this article, you'll learn about authentication in Next.js and how you can authenticate Next.js applications with LoginRadius. Note: An…","fields":{"slug":"/engineering/guest-post/nextjs-authentication-guide/"},"html":"

In this article, you'll learn about authentication in Next.js and how you can authenticate Next.js applications with LoginRadius.

\n
\n

Note: An understanding of React, Hooks, and Next.js is beneficial to follow this tutorial.

\n
\n

What is Authentication?

\n

Authentication is the process of validating that an individual is who they claim to be. Authentication is an essential feature for applications, particularly those that store user data.

\n

You should not mistake authentication for authorization. Authorization is the process of verifying that whether a user has required permission to access an asset or data set.

\n

Authentication deals with identifying a user, while authorization checks what resources or data an authenticated user has permission to access.

\n

Some of the methods used to implement authentication are:

\n\n

Should You Build Your Authentication System or Use a Third-party Solution?

\n

Authentication is one of the most critical parts of an application’s security, so you should address it adequately.

\n

A few aspects you should consider when assessing if you should build your authentication system or use a third-party solution:

\n\n

Considering these factors, it's pretty easier to rely on a third-party solution, and it's also cheaper and more secure than building your own authentication system.

\n

What is LoginRadius?

\n
\n

Loginradius is the world's first no-code identity platform. It is a simple, implementable solution for adding user authentication and authorization to your website.

\n
\n

LoginRadius provides no-code services for authorization, authentication, account security, and much more. It has several interesting features, and some of them are:

\n\n

Understanding Next.js Authentication Patterns

\n

Next.js offers two authentication patterns — client-side and server-side authentication.

\n

Client-Side Authentication

\n

With client-side authentication, the authentication logic and user redirection are done in the browser. The page component fully loads before the redirect logic is executed.

\n

When this authentication approach is used, developers usually use a loading indicator to indicate to the user that a process is running in the background. The loading indicator helps boost user experience. If the user’s authentication fails, redirect the user to a login page.

\n

The following example shows how to handle client-side redirects:

\n
import { useEffect } from "react"\nimport { useRouter } from "next/router"\nimport authService from "auth-service" //imaginary auth service\n\nexport default function ProtectedPage() {\n  const router = useRouter()\n\n  useEffect(() => {\n    const authUser = authService.getUser()\n\n    // if there is no authenticated user, redirect to login page_\n\n    if (!authUser) {\n      router.push("/login")\n    }\n  }, [])\n\n  return (\n    <>\n      <h1>Welcome {user.name}. This is a protected page</h1>`\n    </>\n  )\n}
\n

The above code snippet handles client-side redirects in the browser using next/router. It also uses an imaginary authentication service, auth-service, for illustration purposes. You’ll work with LoginRadius later in this tutorial.

\n

It checks if there is an authenticated user with the authService.getUser() method in the useEffect. If there is none, it redirects the user to the /login page using Next.js’s router object.

\n

This is a simple illustration of client-side authentication and redirection.

\n

Server-Side Authentication

\n

With server-side authentication, you can redirect a user from, say, pages/profile to pages/login. When non-authenticated users try to access a protected page, they are redirected to a login page. All of this is done on the server — before the request reaches the browser.

\n

A benefit of this pattern is that non-authenticated users do not see flashes of unauthenticated content before they are redirected.

\n

The following example below shows how to handle server-side redirects:

\n
export default function ProtectedPage({ user }) {\n\treturn (\n\t\t<>\n\t\t\t<h1>Welcome {user.name}. This is a protected page</h1>\n\t\t</>\n\t)\n}\n\nexport const getServerSideProps = async context => {\n\tconst { user } = authService.getUser(context.req)\n\n\t// if there is no authenticated user, redirect to login page\n\n\tif (!user)\n\t\treturn {\n\t\t\tprops: {},\n\n\t\t\tredirect: { destination: "/login" },\n\t\t}\n\n\t\treturn { props: { user } }\n\t}\n}
\n

Using getServerSideProps enables rendering pages on the server. You can take advantage of that to also handle the redirection on the server.

\n

The above code snippet uses the authService.getUser() method to get the authenticated user’s object. If there is no user, it returns an object with a redirect object. The redirect object contains a destination key, where you can put the page you want to redirect the user to, which is your application’s login page.

\n

Now that you’ve understood the authentication patterns available, let’s see how to authenticate a Next.js application with LoginRadius.

\n

Authenticating Next.js Apps with LoginRadius

\n

The steps below highlight how you can integrate and authenticate your Next.js applications with LoginRadius:

\n

Create a LoginRadius Account

\n

You should create an account to get started with LoginRadius. There is a free plan you can start with.

\n

Get Account Credentials

\n

Now that you have an account, you should get the credentials for your appName and apiKey from the dashboard. You'll need them later to use the React SDK.

\n

Start a New Next.js Application

\n

Run the following command in your terminal to create a new Next.js application:

\n
npx create-next-app <name-of-project>\n//or\nyarn add create-next-app <name-of-project>
\n

Install LoginRadius React SDK

\n

Next, install the React SDK into the project:

\n
```javascript\nnpm install loginradius-react\n//or\nyarn add loginradius-react\n```
\n

Integrate the React SDK

\n

You need to wrap the root component with the SDK’s authentication provider.

\n

You also need to pass the account credentials to the provider. You can get these credentials from your LoginRadius account dashboard.

\n

Navigate to pages/_app.js and update it with the code below:

\n
import Head from "next/head"\nimport { LRAuthProvider } from "loginradius-react"\nimport { ChakraProvider } from "@chakra-ui/react"\nimport Layout from "../layout"\nimport "../styles/globals.css"\n\nfunction MyApp({ Component, pageProps }) {\n  return (\n    <>\n      <Head>\n        <title>Loginradius Next</title>\n      </Head>\n\n      <LRAuthProvider\n        appName="your-app-name"\n        apiKey="your-api-key"\n        redirectUri={"http://localhost:3000/"}\n      >\n        <ChakraProvider>\n          <Layout>\n            <Component {...pageProps} />\n          </Layout>\n        </ChakraProvider>\n      </LRAuthProvider>\n    </>\n  )\n}\n\nexport default MyApp
\n

The above code snippet imports the LRAuthProvider component from loginradius-react. It passes the appName and apiKey taken from the LoginRadius account dashboard earlier to LRAuthProvider. It also sets the redirectUri to http://localhost:3000/.

\n

The redirectUri is the callback URL where you want to redirect users after being authenticated. You should whitelist the redirect_uri in your LoginRadius account dashboard. Localhost URLs are whitelisted by default.

\n

Now that you've integrated the SDK, let’s add the authentication functionality.

\n

Add Login and Logout Functionality

\n

Your users should be able to log in and out of our application, so let’s set that up.

\n

We will add the log in and log out functionality to a Nav component. Let’s set up the component.

\n

Create a layout folder in the root directory, and create a Nav.js file there. Add the following code to Nav.js:

\n
import { Button, Flex, Stack } from "@chakra-ui/react"\nimport { useLRAuth } from "loginradius-react"\n\nexport default function Nav() {\n  const { loginWithRedirect, logout } = useLRAuth()\n\n  return (\n    <Flex>\n      <Stack spacing={[6, 8]}>\n        <Button onClick={() => loginWithRedirect()}>Login to continue</Button>\n        <Button onClick={() => logout()}>Log out</Button>\n      </Stack>\n    </Flex>\n  )\n}
\n

Here, Chakra UI is used for UI components.

\n

First, it imports the useLRAuth hook from the SDK. Next, it accesses the loginWithRedirect and logout methods from the useLRAuth hook.

\n

Then, it passes loginWithRedirect and logout to the login and logout buttons’ onClick event handlers, respectively.

\n

Having created the Nav component, we need to create the Layout component we mentioned earlier.

\n

Create an index.js file in the layout folder, and paste the code below:

\n
import { Box } from "@chakra-ui/react"\nimport Nav from "./Nav"\n\nexport default function Layout({ children }) {\n  return (\n    <Box h="100vh" bg="green.50">\n      <Nav />\n      <Box>{children}</Box>\n    </Box>\n  )\n}
\n

With that, you've added authentication to your application. However, you need a way to track the authentication state. You need to know if there is a logged-in user and do something with that information.

\n

Tracking Authentication State

\n

The SDK also provides error and user objects, along with isLoading and isAuthenticated booleans. You'll use these to track the authentication state.

\n

You can access information about an authenticated user, such as their email address, from the user object. If any, you can display error messages from the error object.

\n

isAuthenticated returns true if there is an authenticated user and false if there is not.

\n

We are currently rendering both the login and logout buttons in the Nav component. However, we don’t want that. We want to display the login button when there is no authenticated user and logout when there is an authenticated user.

\n

Let’s update the Nav.js file with the code below to fix that:

\n
import { Button, Flex, Stack } from "@chakra-ui/react"\nimport { useLRAuth } from "loginradius-react"\n\nexport default function Nav() {\n  const { isAuthenticated, user, loginWithRedirect, logout } = useLRAuth()\n  return (\n    <Flex as="nav">\n      <Stack spacing={[6, 8]}>\n        {!user && (\n          <Button onClick={() => loginWithRedirect()}>Login to continue</Button>\n        )}\n\n        {isAuthenticated && user && (\n          <Button onClick={() => logout()}>Log out</Button>\n        )}\n      </Stack>\n    </Flex>\n  )\n}
\n

We conditionally display the login and logout buttons based on the authentication state.

\n

If there is a logged-in user, we want to redirect them to the profile page.

\n

Navigate to pages/index.js file and update it with the code below:

\n
import { useEffect } from "react"\nimport { useRouter } from "next/router"\nimport { useLRAuth } from "loginradius-react"\nimport { Button, Heading, VStack, Center } from "@chakra-ui/react"\n\nexport default function Home() {\n  const { isLoading, isAuthenticated, error, user } = useLRAuth()\n  const router = useRouter()\n\n  useEffect(() => {\n    if (user && isAuthenticated) {\n      router.push("/profile")\n    }\n  }, [router, user, isAuthenticated])\n\n  if (isLoading) {\n    return <div>Loading...</div>\n  }\n\n  if (error) {\n    return <div>Oops... {error.message}</div>\n  }\n\n  return (\n    <Center pt={10}>\n      <VStack spacing={[6, 8]}>\n        <Heading as="h2">Welcome</Heading>\n        <Text fontSize="3xl">Login to continue</Text>\n      </VStack>\n    </Center>\n  )\n}
\n

Let’s break down the above code snippet:

\n\n

Displaying Authenticated User Data

\n

You have to display information about the authenticated user. Let’s set that up.\nCreate a profile.js file in the pages directory and paste the code below:

\n
import { Box, Center, Heading } from "@chakra-ui/react"\nimport { useLRAuth } from "loginradius-react"\n\nexport default function Profile() {\n  const { user, isLoading, isAuthenticated } = useLRAuth()\n\n  if (isLoading) {\n    return <div>Loading...</div>\n  }\n\n  if (isAuthenticated) {\n    return (\n      <Box>\n        <Center mt={10}>\n          <Heading a="h2">\n            Welcome to your profile {user.Email[0].Value}\n          </Heading>\n        </Center>\n      </Box>\n    )\n  }\n}
\n

You should display a user’s information if they're authenticated. Here, you check that they're authenticated with the isAuthenticated hook. If they're authenticated, return some JSX and display the user’s email address.

\n

Protecting a Route

\n

You can create protected routes to ensure only authenticated users can access those routes.

\n
import { withAuthenticationRequired } from "loginradius-react"\n\nconst Profile = () => {\n\tif (isAuthenticated) {\n\t\treturn (\n\t\t\t<Box\n\t\t\t\t...markup goes here\n\t\t\t</Box\n\t\t)\n\t}\n}\n\nexport default withAuthenticationRequired(Profile,\n\t//Show a message while the user waits to be redirected to the login page.\n\tonRedirecting: () => (\n\t\t<div>Redirecting you to LoginRadius awesome Login page</div>\n\t),\n});
\n

Here, the code snippet uses the withAuthenticationRequired higher-order component to wrap the Profile component. With this, anytime an unauthenticated user tries to access the /profile route, they'll be redirected to LoginRadius’s login page and then back to /profile after they log in.

\n

The image below shows an authenticated user's profile page.

\n

\n \n \n

\n

Conclusion

\n

In this tutorial, you have learned about user authentication and understood whether you should develop an authentication system in-house or use a modern identity platform like LoginRadius.

\n

Then, you have briefly learned different authentication patterns available in Next.js. And you step-by-step understood how to authenticate Next.js applications with LoginRadius’s React SDK.

\n

A working version of the code used in this tutorial is available on Github.

\n","frontmatter":{"date":"January 13, 2022","updated_date":null,"description":"This tutorial describes Next.js authentication patterns and helps you learn step-by-step how to authenticate a Next.js application.","title":"Your Ultimate Guide to Next.js Authentication","tags":["Authentication","React","Next.js","LoginRadius"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.7699115044247788,"src":"/static/cc1040bb014138d9f198e7e127d9c831/ee604/next-authentication.png","srcSet":"/static/cc1040bb014138d9f198e7e127d9c831/69585/next-authentication.png 200w,\n/static/cc1040bb014138d9f198e7e127d9c831/497c6/next-authentication.png 400w,\n/static/cc1040bb014138d9f198e7e127d9c831/ee604/next-authentication.png 800w,\n/static/cc1040bb014138d9f198e7e127d9c831/f3583/next-authentication.png 1200w,\n/static/cc1040bb014138d9f198e7e127d9c831/5707d/next-authentication.png 1600w,\n/static/cc1040bb014138d9f198e7e127d9c831/eeb1b/next-authentication.png 1920w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Emadamerho-Atori Nefe","github":"nefejames","avatar":null}}}},{"node":{"excerpt":"In this post, I’ll talk about how cookies compare to browser storage. You’ll understand why cookies came out, the problem they solve, and…","fields":{"slug":"/engineering/guest-post/local-storage-vs-session-storage-vs-cookies/"},"html":"

In this post, I’ll talk about how cookies compare to browser storage. You’ll understand why cookies came out, the problem they solve, and their limitations.

\n

Then you’ll explore what browser storage is, and dive deeper into local storage and session storage. You’ll look at their features, where they can be useful, and how to use them via JavaScript.

\n

You’ll then see how you can contrast the features, advantages, and disadvantages of each and also highlight specific use cases of each.

\n

You’ll also look at the best practices or approach to keep in mind while using each of them and the best place to store your JWT or auth tokens.

\n
\n

How many times have you seen a popup on a website that says:

\n
\n

This website is using cookies to store your information.

\n
\n

I'm guessing so often that you've lost the count!

\n

Cookies have been used since time immemorial for storing session related information of a user. This allows websites to provide a unique and engaging experience to their users.

\n

However, cookies can be a bit difficult to use, have limited use-case, and have small data storing capacity. To combat this, modern browsers come with their own storage mechanisms like local storage and session storage.

\n

In this post, I’ll talk about these storage mechanisms. You'll understand how local storage, session storage, and cookies compare against one another and explore common use cases of each. By the end of this post, you'll know exactly when to use which.

\n

A Brief History of Cookies

\n

Let's have a refresher on the history of cookies.

\n

Back in the day, websites used HTTP protocol which is stateless. This meant that they couldn't store user-related information like the user’s session id, the name of the user, etc., in the browser.

\n

As the web advanced and grew more popular, websites started storing user related information in the browser itself. This helped them differentiate what kind of user is interacting with their website and provide a personalized experience to the user.

\n

Enter Cookies

\n

That's how cookies were born. They presented a mechanism to store lightweight client or server side data on the browser as key value pairs. They also had an expiry timestamp after which they were automatically deleted by the browser.

\n

Also, both browser and the server could set and retrieve cookies from a user’s browser. Moreover, these cookies were sent alongside each HTTP request automatically. This came in handy for server side websites at a time when single page applications weren't a thing. They could easily discern a user's information with each HTTP request that user made.

\n

The Rise of Browser Storage

\n

Where cookies solved a great problem, it had some limitations. First, they could only store data up to a few kbs. As client-side applications became more complex, there was a need to store more complex data in the browser.

\n

With the onset of HTML5, websites were introduced to browser storage APIs for storing client side information. These APIs were available on browser's window objects globally. Thus, any JavaScript running in the browser could easily access them. The major differentiator was that they had higher data storage capacity and could only be accessed by client-side JavaScript.

\n

Browsers rolled out two storage mechanisms — local storage and session storage. So let's explore and understand them in detail.

\n

Browser’s Session Storage

\n

Let's first take a peek at where the session storage resides in the browser:

\n
    \n
  1. \n

    Open the developer tools in the browser and head over to the \"Application\" tab.

    \n

    \"Application

    \n
    2. \n
  2. \n

    Under the storage section, you'll find a section named \"Session Storage\".

    \n

    \"Session

    \n
    3. \n
  3. Click on it, and you'll be able to see the session storage for that website.
    4. \n
\n

There it is! Now, let's look at the features of browser's session storage.

\n

Storage Capacity

\n

Session storage can store data ranging between 5mb - 10mb. The exact amount of storage capacity varies as per each browser's implementation, but it's a lot more than 4kb of storage capacity cookies offer!

\n

Data Persistence

\n

As the name suggests, session storage only persists the data as long as a browser tab is opened. This means that each time you open a new tab or a new browser window, a new session storage is created. So any data you store inside the session storage will automatically get deleted when you close that tab/window.

\n

Using Session Storage

\n

You can access the session storage in the window object:

\n
window.sessionStorage\n//Storage {length: 0}
\n

This would return the length of the session storage along with an object representing the data that's currently present inside. Since it's empty to begin with, the length is 0. Note that you may directly access the sessionStorage object as well.

\n

Adding Data

\n

Let's add a key-value pair to the session storage using the setItem function available in the sessionStorage object:

\n
sessionStorage.setItem("id", "123")
\n

This will set a new item in the session storage with the key id and value 123. If you simply invoke the sessionStorage object now:

\n
sessionStorage\n//Storage {id: '123', length: 1}
\n

You now get your recently added data back!

\n

You'll also see this inside the session storage section of the browser's application tab:

\n

\"Session

\n

Inserting Complex JSON Data

\n

Let's add a bit more complex JSON object in the session storage that looks like this:

\n
const data = {\n  _id: "61c6c1df7cda7d370a9ef601",\n  index: 0,\n  guid: "13672f0e-f693-4704-a6f9-839ff36e8960",\n  isActive: true,\n  balance: "$3,602.49",\n  picture: "http://placehold.it/32x32",\n  age: 25,\n  friends: [\n    {\n      id: 0,\n      name: "Adkins Coleman",\n    },\n    {\n      id: 1,\n      name: "Howe Douglas",\n    },\n    {\n      id: 2,\n      name: "Becky Velez",\n    },\n  ],\n}
\n

You'll first need to stringify it since the value against a key can only be a string. Then, you'll store it inside the session storage using the setItem method:

\n
sessionStorage.setItem("user_data", JSON.stringify(data))
\n

It should now appear inside the session storage of the browser's application tab:

\n

\"Complex

\n

Awesome! Let's take a look at retrieving this data.

\n

Retrieving Data

\n

You can use the getItem() function to retrieve a value stored against a key from the session storage by specifying the key as the first parameter in the function.

\n
sessionStorage.getItem("id")\n//'123'
\n

If you're retrieving an object, you'll need to use JSON.parse first to convert the string into a JavaScript object:

\n
JSON.parse(sessionStorage.getItem("user_data"))
\n

Usecase

\n

Since data in session storage persists only across a browser tab, there are some unique usecases for session storage.

\n

Booking Applications

\n

Session storage can be used in multi-step processes that must be performed in a single instance. This includes booking flights, hotels, movie tickets, train reservations etc. You can store the details of the previous steps in the browser's session storage to prepopulate those forms or inputs.

\n

Since these are critical activities that must be performed in a single go, the data will automatically get deleted when the user jumps to a new tab or a new browser window.

\n

Prompting Login/Signups to a User

\n

Blogging websites, newsletters, tutorial websites etc., have tons of visitors who read through the content without creating an account. In such scenarios, you can subtly prompt the user every time they visit the website to create an account. You can track the session of each user in the session storage.

\n

Every time a user reads a blog post or an article on a different tab, you can ask them to create an account. This could be a great way to offer a non-blocking experience for your users whilst effectively converting them to a signed-up user for your website.

\n

Browser’s Local Storage

\n

Under the application tab where session storage resides, you'll find a section called local storage right underneath it.

\n

\"Local

\n

That's where you can see everything you store inside the local storage of your browser. Local storage works, appears, and similar to session storage. For instance, just like Session storage, local storage can also store data ranging between 5mb - 10mb depending upon a browser's implementation.

\n

Data Persistence

\n

Unlike session storage where data is automatically deleted when a browser tab or window is closed, data in local storage has no default expiry. It's only deleted if you manually delete that data from the local storage either directly, via browser settings, or through your JavaScript code.

\n

That means that data in a local storage persists even after a particular tab or browser window is closed.

\n

Using Local Storage

\n

You can add and retrieve data from local storage in the same way you perform those operations with session storage. The only change is now you'll have to use the localStorage object to perform these operations instead.

\n

For instance, you can add an item to the localStorage, as follows:

\n
localStorage.setItem("id", "123")
\n

Consequently, you can retrieve an item using the getItem() function:

\n
localStorage.getItem("id")\n//'123'
\n

Usecase

\n

Local storage has a number of uses due to the fact that data inside it has no default expiry. Think about all those scenarios where you want to store some global data that's accessed often in your application.

\n

Generic

\n

For instance, your user's email id, username, full-name, etc. All these data are widely used throughout different pages of your application. Storing this data inside the local storage will help you prevent unwanted API calls to the server to fetch this data. Also, since this data isn't normally changed often, the chances of having inconsistent data across the browser and the server is quite low.

\n

Application Specific

\n

You can also use it to store application specific data that is immutable throughout a login session of a user. For instance, if you have an ecommerce site, you can store the preferred payment option of the user, default delivery addresses, etc. You can also store user preferences such as the theme a user prefers for your website (dark or light mode).

\n

Cookies vs. Browser Storage

\n

Now that you've understand how browser storage works, you can compare them effectively against cookies. However, let's first look at their similarities.

\n

Similarities

\n

Remember in the beginning I asked you how many times you've seen that cookies popup? Most of these popups also have an option where you can choose not to accept these cookies.

\n

In other words, cookies are blockable by users and so is browser storage. Users can choose not to allow their data to be stored via any of these mechanisms — and hence, your application should never completely rely on these storage mechanisms.

\n

Both cookies and browser storage store key-value pairs as strings and are well supported in all modern browsers. The data inside this can also be easily edited by the user.

\n

Differences

\n

You know that browser storage has a greater storage capacity than cookies. Hence, browser storage is always a better choice than cookies to store large client-side data.

\n

However, since session storage and local storage have different data persistence, you should carefully choose either of them depending on how long you want the data to persist.

\n

Cookies allow you to automatically set a TTL or expiry time; are transferred with every HTTP request to the server; and, can also be accessed by the server. These features are missing in browser storage. Which brings us to the question — where would cookies be actually more useful than browser storage?

\n

\n \n \n

\n

The answer is server side data! If you've dealt with authentication before, you know that at some point you need to store the authentication token or JWT of a user somewhere where it's easily accessible. That's where cookies are helpful. But why can't we use or why shouldn't we use browser storage here?

\n

Storing Your JWT/Auth Token

\n

Data such as JWT or Auth token should not be stored in browser storage because they can be accessed by any client side JavaScript running in the browser. This means that if your application somehow leaves an XSS vulnerability, your user's authentication token could be easily leaked to the attacker.

\n

The attacker could then make false requests, modify your user's data in the database, and do a lot of damage for your application as well as users. Hence, it's always best to store JWTs in http only cookies. Http only cookies are special cookies that cannot be accessed by client side JavaScript. This way they're secure against XSS attacks.

\n

Also, authentication token is often refreshed on expiry and one can use cookies TTL easily to manage that. For simpler cases, one can also store JWT inside regular cookies by setting a TTL.

\n

But all in all, authentication itself can be a tricky subject. If you're looking for a no-code identity platform that can seamlessly handle authentication for your application, consider using LoginRadius.

\n

Wrapping it Up

\n

Now that you understand how powerful browser storage is, don't feel shy to use it in your applications. Use cookies for server side data where you need a TTL, session storage for specific use cases discussed above, and local storage to manage global data in your application.

\n

However, avoid the pattern where your single page application directly interacts with the local storage. For instance, if you're using React with Redux to manage the state in your application, let your reducers take control over what goes and comes out of local storage. Your React components should be abstracted from using local storage directly.

\n

Finally, since local storage data has no default expiry, be vary of when you're clearing this data to avoid data inconsistency between your frontend and backend.

\n","frontmatter":{"date":"January 12, 2022","updated_date":null,"description":"This article helps you understand the differences between browser storage and cookies. By the end, you'll understand when to use cookies and browser storage (both local storage and session storage).","title":"Local Storage vs. Session Storage vs. Cookies","tags":["Cookie","Browser Storage","Authentication","JWT"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/05c0a6d7a4539d8f04241b6ddf720a52/ee604/blog-banner.png","srcSet":"/static/05c0a6d7a4539d8f04241b6ddf720a52/69585/blog-banner.png 200w,\n/static/05c0a6d7a4539d8f04241b6ddf720a52/497c6/blog-banner.png 400w,\n/static/05c0a6d7a4539d8f04241b6ddf720a52/ee604/blog-banner.png 800w,\n/static/05c0a6d7a4539d8f04241b6ddf720a52/f3583/blog-banner.png 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Siddhant Varma","github":"FuzzySid","avatar":null}}}},{"node":{"excerpt":"All React developers love to leverage the benefits React caters to in developing web applications. But developers need to keep in mind the…","fields":{"slug":"/engineering/react-security-vulnerabilities/"},"html":"

All React developers love to leverage the benefits React caters to in developing web applications. But developers need to keep in mind the security postures while creating React web apps. React applications face a vast attack surface and are prone to different vulnerabilities. This article is a checklist of React security best practices that every developer should know before diving into PWA (progressive web application) development.\nIf you are new to progressive web applications and React, let's get familiar with these terminologies first.

\n

What are Progressive Web Applications (PWA)?

\n

Progressive Web Apps (PWA) are apps built using web technologies like HTML, CSS, and JavaScript (JS). But these apps deliver the experience, feel, and functionality of a native app. PWA combines new technologies and integrations to build a reliable, engaging, accessible, and secure application. Developers mostly use React on top of HTML and JavaScript to build a progressive web app.

\n

What is React?

\n

React is popular among progressive web app developers. This open-source, robust JavaScript library helps in building user interfaces based on UI components. React gains popularity in the software development industry because it allows developers to create lightweight apps with additional facilities: security, push notification, app-like look and feel, etc. Some popular companies that have become the early adopters of React are Instagram, Netflix, Airbnb, Uber Eats, Discord, the New York Times, etc.

\n

Security Vulnerabilities in React and How to Prevent Them

\n

React helps developers build a reliable, robust, and secure progressive web app, but these apps face certain security pitfalls also. Developers need to give prior attention to security vulnerabilities, which are often ignored due to faster app development cycles or more focus on product features.\nWith the arrival of each new update in React having more features, the security flaws are getting unnoticed. Such unnoticed actions are increasing security concerns. Here is a list of top React security vulnerabilities that every React developer must address before delivering or deploying their apps.

\n

SQL Injection

\n

SQL Injection (SQLi) is a widely known web application attack. The cybercriminal intends to perform database manipulation logically to access sensitive information that is not supposed to be displayed. Attackers try to sneak into that sensitive information to collect phone numbers, payment details, addresses, passwords, and other credentials.\nThis technique allows the attackers to manage access to the server, pull the data, and manipulate the values in the database. Apart from data modification, hackers can also delete the data.\nLet us take an example. Let us take an example where the code will search for the current user-ID and the login matching the employee name, where the owner is the current user-ID.

\n
string query = "SELECT * FROM logondata WHERE owner = "'"\n+ empID + "' AND empName = '"\n+ EmpName.Text + "'";
\n

Combining both the employee ID and employee name, the following query gets generated.

\n
SELECT * FROM logondata\nWHERE owner =\nAND empName = ;
\n

The problem that pops here is that the main code leverages the concept of concatenation that helps in combining those data. The attacker can use a string like 'empName' OR 'x'='x' as the employee name. 'x' = 'x' is such a condition, which will always evaluates to True. Therefore, the statement returns True for all values within the table. So, the following query becomes:

\n
SELECT * FROM logondata\nWHERE owner = 'karlos'\nAND empName = 'name' OR 'x' = 'x';
\n

There are three major categories of SQL injection based on how attackers gain access to the backend data.

\n\n

Checklist to Fix SQLi Vulnerability in React Apps

\n\n

Cross-Site Scripting (XSS) Vulnerabilities

\n

The comprehensive rendering feature of React makes it a preferable choice over other JavaScript libraries and frameworks. But this rendering feature also drags React-based apps to the most widely exploited vulnerability, cross-site scripting (XSS). Cross-site scripting leverages malicious client-side scripts by injecting them into web applications. When the users trigger those scripts, the attackers gain control over the app and steal sensitive information from the web application.

\n

Injecting malicious scripts into the react app will make the app release some internal app data. Therefore, React developers should prevent the application from running the script. Here is a typical example of cross-site scripting where the attacker can place and execute a malicious script within the application like this:

\n
<input type="search" value="PWA"/>
\n

Now, executing malicious script will make the search look like:

\n
<input type="search" value="Attacker "/> <script> StealCredentials() </script>"> ;
\n

Here, StealCredentials() is a function that contains malicious scripts to steal user information.\nLet us now take a look at the types of XSS.

\n\n

Checklist to Fix XSS Vulnerability in React Apps

\n

This attack gains popularity, not simply because of its potential to harm the target users through the application but because such attacks need more creative and intellectual hackers. But, to prevent such attacks, developers need to become even more creative.

\n\n

Broken Authentication

\n

Broken authentication is a weakness through which attackers can capture one or multiple accounts when authentication or session management is poorly implemented in progressive web apps. This vulnerability helps the attacker take over multiple user accounts, letting the attacker possess the same privileges and access control as the target user.

\n

Attackers usually exploit such a React security vulnerability by detecting the authentication solution or bypassing them. The security team labels the authentication as broken when the cybercriminal can compromise users' passwords, session tokens, digital identities, or account information from the React app. Examples of some common reasons for this attack are:

\n\n

Let us take a situation where the attacker could detect the hashes for the following names.

\n
Sue    4420d1918bbcf7686defdf9560bb5087d20076de5f77b7cb4c3b40bf46ec428s\nKarlos    4420d1918bbcf7686defdf9560bb5087d20076de5f77b7cb4c3b40bf46ec624g\nDee    77b177de23f81d37b5b4495046b227befa4546db63cfe6fe541fc4c3cd216egk
\n

The hash function will store the password in a hashed form rather than plain text. But then, humans can easily read the hash. Now, if two different users enter the same password, then these passwords will generate the same hash. Hackers can perform a dictionary attack, and if they crack one password, they can use the same password to gain access to other accounts that use the same hash.

\n

Checklist to Fix React PWAs from Broken Authentication Vulnerability

\n\n

XML External Entities (XXE)

\n

Attackers can perform XML External Entities attacks on React web applications that parse XML input. Here the outdated XML parsers of your React app become vulnerable. Such vulnerability can lead an attacker to perform denial of service, port scanning, server-side request forgery, etc. Such attacks occur when an XML input gets referred to an external entity but has a weakly configured XML parser. Here are some examples where attackers are attempting XEE on React web applications that parse XML input.

\n\n

Checklist to Fix XXE Vulnerability in React Apps

\n\n

Zip Slip

\n

It is another popular React app vulnerability where the malicious actor exploits the app by submitting zip files having malicious or arbitrary code within them. React developers enable adding zip files to decrease the file size while they get uploaded. When the app unzips the archive, its malicious file(s) can overwrite other files or perform arbitrary code execution. Attackers can either harm the files existing in the target system or gain remote access to the system.

\n

Here is a Zip slip code example demonstrating a ZipEntry path merges to a destination directory without validating that path. Researchers and security professionals have found similar codes in different repositories across many apps.

\n
Enumeration<ZipEntry> entry = zip.getEntries();\n while (entry.hasMoreElements()) {\nZipEntry ez = entry.nextElement();\nFile fil = new File(destinationDir, ez.getName());\nInputStream input = zip.getInputStream(ez);\nIOUtils.copy(input, write(fil));\n }
\n

Here is a link to the repository containing libraries and APIs infected by zip slip.

\n

Checklist to Fix Zip Slip Vulnerability in React Apps

\n\n

Cross-site Request Forgery (CSRF or XSRF)

\n

CSRF is another React web application vulnerability allowing attackers to persuade users to perform unintentional actions without their direct consent. It does not steal the identity of the legitimate user but acts against their will. For rendering such attacks, the attacker sends an email or a web link convincing the victim to achieve a state-changing request in the application.

\n

Before going through the checklist on fixing CSRF vulnerabilities, here is a quick example of how the CSRF GET request will be once the attacker tweaks it.\nA standard GET request for a $250 transfer from person1 to person2 might look like this:

\n

When the attacker induces the user to perform some unintended action or runs a malicious script, the $250 gets transferred to the attacker's account. This malicious request might look something like this:

\n

Some attackers can also put innocent-looking hyperlinks embedding the request.

\n

Checklist to Fix React PWAs from CSRF Vulnerability

\n\n

Vulnerability in Packages and Dependencies

\n

It might happen that you have pushed a React app's code to GitHub. Now an email/notification is popping up saying, \"One of your dependencies has a security vulnerability.\" That is another method where attackers seek the help of malicious packages to gain access to your React applications. Such malicious packages collect valuable app details and user information and send it to a third party.

\n

These packages can also execute malicious code during the package installation phase. These attackers use the concept of typosquatting to make their attacks seamless. Typosquatting is a method of naming the packages based on their original counterparts. It outwits the developers into downloading these malicious packages that can wreak havoc on the React app.

\n

Checklist to Fix Malicious Package Vulnerability in React Apps

\n\n

Wrapping Up

\n

Hope this comprehension has given a crisp idea of the top React vulnerabilities and the different checklists developers can use to fix those security flaws. Developers should know how crucial application security is for both the business and its users. As the React features are increasing, there is an equal delay in the number of days taken by the React community to fix any React security issues.

\n

In this article, we discussed the most well-known vulnerabilities like SQLi, XSS, Broken Authentication, XXE, Zip Slip, CSRF, and Package & dependency vulnerabilities, plus how to prevent React apps from such attacks. So, developers and product managers should cautiously handle all security-related aspects of a React project by following the checklist given in this article.

\n","frontmatter":{"date":"December 24, 2021","updated_date":null,"description":"React security vulnerabilities are hard to detect. However, this article talks about the top 7 vulnerabilities and how to fix them to enjoy all the benefits React caters to in developing Progressive Web Applications.","title":"React Security Vulnerabilities and How to Fix/Prevent Them","tags":["React","Vulnerability"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.2820512820512822,"src":"/static/7d6e838c39ee3573adb83d3237a82ee6/ee604/react-security.png","srcSet":"/static/7d6e838c39ee3573adb83d3237a82ee6/69585/react-security.png 200w,\n/static/7d6e838c39ee3573adb83d3237a82ee6/497c6/react-security.png 400w,\n/static/7d6e838c39ee3573adb83d3237a82ee6/ee604/react-security.png 800w,\n/static/7d6e838c39ee3573adb83d3237a82ee6/f3583/react-security.png 1200w,\n/static/7d6e838c39ee3573adb83d3237a82ee6/5707d/react-security.png 1600w,\n/static/7d6e838c39ee3573adb83d3237a82ee6/b6c0e/react-security.png 1926w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Gaurav Kumar Roy","github":"GauravRoy6","avatar":null}}}},{"node":{"excerpt":"Security has become a fundamental aspect to consider while developing an application. As people become more aware and hackers more notorious…","fields":{"slug":"/engineering/guest-post/securing-php-api-with-jwt/"},"html":"

Security has become a fundamental aspect to consider while developing an application. As people become more aware and hackers more notorious, you need to employ systems that strengthen your application's data security.

\n

Previously, it was common to use session storage to secure applications. In recent times, sessions have proved inefficient, which pushed to migrate to authentication with APIs. Even though this was a superb and robust way to secure web applications, it became obsolete as hackers tried to figure out how to crack this authentication.

\n

As the web evolves to accept more and more users, the research for secure authentication techniques speeds up. In 2010, the world was introduced to a new and secure authentication standard -- JWT. Let's know more about JWT.

\n

What is JWT?

\n

JSON Web Token (JWT) is a safe way to authenticate users on a web app. Using JWT, you can securely transfer encrypted data and information between a client computer and a server.

\n
\n

Learn more about the differences between sessions and JWTs here.

\n
\n

JWT offers many benefits. Here are some of them.

\n

Benefits of Using JWT

\n\n

Now that you've learned about the advantages, it's time to go deeper into the JWT.

\n

The Structure of JWT

\n
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9\n  .eyJpc3MiOiJodHRwczpcL1wvcWEtYXBpLndlbGx2aWJlLmNvbVwvYXBpXC9hdXRoXC9sb2dpbiIsImlhdCI6MTYzMDQ3OTA5NSwiZXhwIjoxNjMwNDgyNjk1LCJuYmYiOjE2MzA0NzkwOTUsImp0aSI6Imtsa3hHUGpMOVlNTzRSdUsiLCJzdWIiOjc3ODE4LCJwcnYiOiIyM2JkNWM4OTQ5ZjYwMGFkYjM5ZTcwMWM0MDA4NzJkYjdhNTk3NmY3IiwidXNlcnNfaWQiOjc3ODE4LCJtZW1iZXJzX2lkIjo3Nzg4MzMsInByb3h5X3VzZXJfbWVtYmVyc19pZCI6bnVsbH0\n  .TxXwLLu1zWBe7cLLYdFYy3P2HX4AaLgc7WfSRtTgeiI
\n

The above string is an example of a JWT authentication string. At first glance, it may appear to be a randomly produced string. But don't underestimate; this string is made up of three separate components that are essential in a JWT.

\n

JWT Header

\n

The header of a JWT is the initial section of the string before the first dot. This header is produced by acquiring plain text and performing cryptographic operations on it. Moreover, the header uses a very efficient Base64 encoding procedure.

\n

You can quickly obtain the JWT's headers using symmetric or asymmetric encryption techniques.

\n

JWT Payload

\n

The string's central component is the JWT's payload part. This string includes all of the important information about a received request and the user or client computer who created the request. There are predefined key-value pair fields in the payload that can be used to offer extra information about the received request. Here is an explanation of common payload fields.

\n\n

JWT Signature

\n

A cryptographic operation is performed on the JWT data to obtain this signature. It takes in the payload, secret key, and header value of a JWT. The signature is then generated by applying a function to these obtained values.

\n

The server and user can verify this signature to know about the data's security and integrity. If this signature matches at both ends, then the data is considered secure, and all other transactions can occur.

\n

Using JWTs to Secure PHP API

\n

As you've understood everything about JWT, let's secure your PHP API using JWT. Follow the code along, and, in the end, you'll create a tamper-proof PHP API.

\n

This article creates a simple login page and authenticates it using JWT. This will help you get started with JWT and PHP.

\n

To follow along, you'll need to have PHP and composer installed on your computer.

\n

If you haven't already installed composer on your computer, you can learn how to install composer here. Once you've installed composer, run the tool from your project folder. Composer will assist you in installing Firebase PHP-JWT, a third-party library for working with JWTs and Apache.

\n

Once the library is installed, you'll need to set up a login code in authenticate.php. While you do this, put a code piece that checks and gets the autoloader from the composer tool. The below code helps you achieve this.

\n
<?php\ndeclare(strict_types=1);\nuse Firebase\\JWT\\JWT;\nrequire_once('../vendor/autoload.php');
\n

When the form gets submitted, you need to check the entered data with a data source or database. For our purpose, let's create a hasValidCredentials variable and set it to true. Setting this variable to true means that the data is checked and valid.

\n
<?php\n// extract credentials from the request\nif ($hasValidCredentials) {
\n

Any further coding will be wrapped in this block itself. The value of the hasValidCredentials variable governs all code related to the production and validation of the required JWT. If its value is true, the JWT shall be created; otherwise, an error will be shown.

\n

Creating JWT

\n

Let's start creating the JWT. First, you need to generate some more variables to aid in this process. As you saw in the payload section, you must create:

\n\n

JWT's can be easily inspected and checked at client-side browsers. So it is better to hide your secret key and other important information in some environment file, which the user cannot access through client-side requests.

\n
$secret_Key  = '68V0zWFrS72GbpPreidkQFLfj4v9m3Ti+DXc8OB0gcM=';\n$date   = new DateTimeImmutable();\n$expire_at     = $date->modify('+6 minutes')->getTimestamp();      // Add 60 seconds\n$domainName = "your.domain.name";\n$username   = "username";                                           // Retrieved from filtered POST data\n$request_data = [\n    'iat'  => $date->getTimestamp(),         // Issued at: time when the token was generated\n    'iss'  => $domainName,                       // Issuer\n    'nbf'  => $date->getTimestamp(),         // Not before\n    'exp'  => $expire_at,                           // Expire\n    'userName' => $username,                     // User name\n];
\n

Now you have all the required data in hand; you can easily create a JWT. Here, you'll use the PHP-JWT package's encode() method. This method helps transform your data array into a JSON object.

\n

Following the conversion to a JSON object, the encode function produces JWT headers and signs the received payload with a cryptographic combination of all the information and the given secret key.

\n

It is essential to supply three arguments to the encode() method to utilize it correctly. The first argument should be the payload information, which is the data array in this instance. Secondly, you must supply the secret key as an argument; and finally, you must define the cryptographic technique that the function should use to sign the JWT.

\n

To obtain and return the JWT, you'll have to use the echo method above the encode method, as shown below.

\n
<?php\n    // Encode the array to a JWT string.\n    echo JWT::encode(\n        $request_data,\n        $secret_Key,\n        'HS512'\n    );\n}
\n

Now that you have obtained the JWT token, you can transfer it to the client-side and save it using any web programming language of your choice. Let's start with a short JS demonstration of the route ahead.

\n

First, when a successful form submission takes place, save the created and received JWT in client-side memory. To display some output about the JWT's success, remove the login form and merely display a button that retrieves and displays the JWT's timestamp to the user when it is clicked.

\n

Here is some sample code for the process mentioned above.

\n
const storeJWT = {}\nconst loginBtn = document.querySelector("#frmLogin")\nconst btnResource = document.querySelector("#btnGetResource")\nconst formData = document.forms[0]\n\n// Inserts the jwt to the store object\nstoreJWT.setJWT = function (data) {\n  this.JWT = data\n}\n\nloginBtn.addEventListener("submit", async e => {\n  e.preventDefault()\n\n  const response = await fetch("/authenticate.php", {\n    method: "POST",\n    headers: {\n      "Content-type": "application/x-www-form-urlencoded; charset=UTF-8",\n    },\n    body: JSON.stringify({\n      username: formData.inputEmail.value,\n      password: formData.inputPassword.value,\n    }),\n  })\n\n  if (response.status >= 200 && response.status <= 299) {\n    const jwt = await response.text()\n    storeJWT.setJWT(jwt)\n    frmLogin.style.display = "none"\n    btnResource.style.display = "block"\n  } else {\n    // Handle errors\n    console.log(response.status, response.statusText)\n  }\n})
\n

You've already produced and submitted the JWT to the user. So now it's time to put the JWT to use on the user side.

\n

Using JWT

\n

As previously stated, if the form submission is successful, you'll display a button to obtain a timestamp. This button will invoke the GET method on the resource.php script. The resource.php script will then set the JWT received after successful authentication in the authentication header.

\n

The following code will help you achieve this feat.

\n
btnResource.addEventListener("click", async e => {\n  const result = await fetch("/resource.php", {\n    headers: {\n      Authorization: `Bearer ${storeJWT.JWT}`,\n    },\n  })\n  const timeStamp = await result.text()\n  console.log(timeStamp)\n})
\n

Once you've written this code, run the program and enter your credentials into the form fields. A GET request will be sent when you click the submit button. Here is a sample GET request to assist you in making the correct identification.

\n
GET /resource.php HTTP/1.1\nHost: yourhost.com\nConnection: keep-alive\nAccept: */*\nX-Requested-With: XMLHttpRequest\nAuthorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwczpcL1wvcWEtYXBpLndlbGx2aWJlLmNvbVwvYXBpXC9hdXRoXC9sb2dpbiIsImlhdCI6MTYzMDQ3OTA5NSwiZXhwIjoxNjMwNDgyNjk1LCJuYmYiOjE2MzA0NzkwOTUsImp0aSI6Imtsa3hHUGpMOVlNTzRSdUsiLCJzdWIiOjc3ODE4LCJwcnYiOiIyM2JkNWM4OTQ5ZjYwMGFkYjM5ZTcwMWM0MDA4NzJkYjdhNTk3NmY3IiwidXNlcnNfaWQiOjc3ODE4LCJtZW1iZXJzX2lkIjo3Nzg4MzMsInByb3h5X3VzZXJfbWVtYmVyc19pZCI6bnVsbH0.TxXwLLu1zWBe7cLLYdFYy3P2HX4AaLgc7WfSRtTgeiI
\n

Validating JWT

\n

If you've followed along until here, everything should be working fine. Now, let's begin with validating the JWT.

\n

To get help with this operation, you've previously added the composer's autoloader function. You'll now use the preg match function to extract the token from the Bearer header. For this extraction, you'll use the preg match function and supply a regular expression.

\n
if (! preg_match('/Bearer\\s(\\S+)/', $_SERVER['HTTP_AUTHORIZATION'], $matches)) {\n    header('HTTP/1.0 400 Bad Request');\n    echo 'Token not found in request';\n    exit;\n}
\n

The code above attempts to extract the token from the Bearer header. In this case, error handling is utilized. Thus if the token is not discovered, an HTTP 404 error is displayed to the user.

\n

To validate the JWT, you must first compare it to the previously created JWT.

\n
$jwt = $matches[1];\nif (! $jwt) {\n    // No token was able to be extracted from the authorization header\n    header('HTTP/1.0 400 Bad Request');\n    exit;\n}
\n

The extracted JWT is saved at the first index of the matches array. If the matching array is empty, it means no JWT was extracted. If the preceding code runs successfully, it implies that the JWT has been extracted, and you may now proceed.

\n

Decoding the received data is required for verifying a JWT. Only the secret key may be used to decode the received data. Once you've obtained the secret key, you may use the static decode function of the PHP-JWT module.

\n

The decode method requires three arguments, which are as follows.

\n\n

If the decode method succeeds, you may proceed to validate the JWT. The code below will assist you in decoding and validating a JWT.

\n
$secret_Key  = '68V0zWFrS72GbpPreidkQFLfj4v9m3Ti+DXc8OB0gcM=';\n$token = JWT::decode($jwt, $secret_Key, ['HS512']);\n$now = new DateTimeImmutable();\n$serverName = "your.domain.name";\n\nif ($token->iss !== $serverName ||\n    $token->nbf > $now->getTimestamp() ||\n    $token->exp < $now->getTimestamp())\n{\n    header('HTTP/1.1 401 Unauthorized');\n    exit;\n}
\n

This code will provide all the necessary parameters to the decode function and save the method's result. Then, to prevent unauthorized access, error handling is employed. If any of the fields in the JWT are unavailable, an HTTP 401 error indicating unauthorized access will be issued to the user.

\n

LoginRadius Authentication for PHP Apps

\n

Instead of using the process discussed above, you can use LoginRadius Identity Platform to authenticate your PHP APIs quickly. You can start by referring to LoginRadius PHP documentation.

\n

In addition, you can use LoginRadius PHP SDK, which, in turn, simplifies signup and login for your users by eliminating the need for remembering an extra set of credentials for your app.

\n

Conclusion

\n

In this tutorial, you've learned about JWT. Then created a PHP web application and secured it with JWT authentication.

\n

You understood how easy and important it is to secure a web application.

\n

You can find the complete code used in this tutorial here.

\n

Don't forget to try this out for your more significant projects.

\n

Finally, if you face any problems following this tutorial or have questions, please feel free to comment below. We'll respond as soon as we can to clarify your questions.

\n","frontmatter":{"date":"December 24, 2021","updated_date":null,"description":"This tutorial helps you understand why you should secure your PHP API. Then, it helps you learn how to use JWT with Apache to secure your PHP API.","title":"How to Secure a PHP API Using JWT","tags":["PHP","JWT","Authentication"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/0d1302ecbb6ca63f354aabd22a131331/ee604/jwt.png","srcSet":"/static/0d1302ecbb6ca63f354aabd22a131331/69585/jwt.png 200w,\n/static/0d1302ecbb6ca63f354aabd22a131331/497c6/jwt.png 400w,\n/static/0d1302ecbb6ca63f354aabd22a131331/ee604/jwt.png 800w,\n/static/0d1302ecbb6ca63f354aabd22a131331/f3583/jwt.png 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Harikrishna Kundariya","github":"espark-biz","avatar":null}}}}]},"markdownRemark":{"excerpt":"Google has prepared a roadmap to restrict third-party cookies in Chrome. Since 04 January 2024, Chrome has rolled out third-party cookie…","fields":{"slug":"/engineering/identity-impact-of-google-chrome-thirdparty-cookie-restrictions/"},"html":"

Google has prepared a roadmap to restrict third-party cookies in Chrome. Since 04 January 2024, Chrome has rolled out third-party cookie restrictions for 1% of stable clients and 20% of Canary, Dev, and Beta clients.

\n

What does it mean for user authentication?

\n

On one hand, Google believes third-party cookies are widely used for cross-site tracking, greatly affecting user privacy. Hence, Google wants to phase out (or restrict) supporting third-party cookies in Chrome by early Q2 2025 (subject to regulatory processes).

\n

On the other hand, Google introduced Privacy Sandbox to support the use cases (other than cross-site tracking and advertising) previously implemented using third-party cookies.

\n

In this article, we’ll discuss:

\n\n

How is User Authentication Affected?

\n

Third-party cookie restrictions affect user authentication in three ways, as follows.

\n

External Identity Providers

\n

If your website or app uses an external Identity Provider (IdP) — like LoginRadius, the IdP sets a third-party cookie when the user authenticates on your app.

\n

Web SSO

\n

If you have multiple apps across domains within your organization and authentication is handled using an IdP (internal or external) with web SSO, you already use third-party cookies to facilitate seamless access for each user using a single set of credentials.

\n

If you have implemented web SSO with one primary domain and multiple sub-domains of the primary domain, third-party cookie restrictions may not apply. For now, Google doesn’t consider the cookies set by sub-domains as third-party cookies, although this stance may change in the future.

\n

For example, you have apps at example.com, travel.example.com, stay.example.com, and web SSO is handled by auth.example.com. In this case, third-party cookie restrictions don’t apply.

\n

Federated SSO

\n

Federated SSO is similar to, albeit different from, web SSO. It can handle multiple IdPs and applications—aka., Service Providers (SPs)—spanning multiple organizations. It can also implement authentication scenarios that are usually implemented through web SSO.

\n

Usually, authentication is handled on a separate pop-up or page when the user wants to authenticate rather than on the application or website a user visits.

\n

For example, you already use federated SSO if you facilitate authentication for a set of apps through multiple social identity providers as well as traditional usernames and passwords.

\n
\n

Note: It is also possible to store tokens locally, not within cookies. In this case, third-party cookie restrictions won’t affect token-based authentication. However, the restrictions still affect authentication where tokens are stored within third-party cookies (a common and secure method).

\n
\n

Chrome’s Alternatives for Third-Party Cookies

\n

Google has been developing alternative features and capabilities for Chrome to replace third-party cookies as part of its Privacy Sandbox for Web initiative.

\n

Specific to authentication, Google recommends the following:

\n
    \n
  1. Cookies Having Independent Partitioned State (CHIPS)
    2. \n
  2. Storage Access API
    3. \n
  3. Related Website Sets
    4. \n
  4. Federated Credential Management (FedCM) API
    5. \n
\n

Cookies Having Independent Partitioned State (CHIPS)

\n

CHIPS are a restricted way of setting third-party cookies on a top-level site without making them accessible on other top-level sites. Thus, they limit cross-site tracking and enable specific cross-site functionalities, such as maps, chat, and payment embeds.

\n

For example, a user visits a.com with a map embed from map-example.com, which can set a partitioned cookie that is only accessible on a.com.

\n

If the user visits b.com with a map embed from map-example.com, it cannot access the partitioned cookie set on a.com. It has to create a separate partitioned cookie specific to b.com, thus blocking cross-site tracking yet allowing limited cross-site functionality.

\n

You should specifically opt for partitioned cookies (CHIPS), which are set with partitioned and secure cookie attributes.

\n

If you’re using an external identity provider for your application, CHIPS is a good option to supplant third-party cookie restrictions.

\n

However, CHIPS may not be ideal if you have a web SSO or federated SSO implementation. It creates separate partitioned cookies for each application with a separate domain, which can increase complexity and create compatibility issues.

\n

Storage Access API

\n

With Storage Access API, you can access the local storage in a third-party context through iframes, similar to when users visit it as a top-level site in a first-party context. That is, it gives access to unpartitioned cookies and storage.

\n

Storage Access API requires explicit user approval to grant access, similar to locations, camera, and microphone permissions. If the user denies access, unpartitioned cookies and storage won’t be accessible in a third-party context.

\n

It is most suitable when loading cross-site resources and interactions, such as:

\n

Verifying user sessions when allowing interactions on an embedded social post or providing personalization for an embedded video.\nEmbedded documents requiring user verification status to be accessible.

\n

As it requires explicit user approval, it is advisable to use Storage Access API when you can’t implement an identity use case with the other options.

\n

Related Website Sets

\n

With Related Website Sets, you can declare a primary website and associatedSites for limited purposes to grant third-party cookie access and local storage for a limited number of sites.

\n

Chrome automatically recognizes related website sets declared, accepted, and maintained in this open-source GitHub repository: Related Website Sets

\n

It provides access through Storage Access API directly without prompting for user approval, but only after the user interacts with the relevant iframe.

\n

It is important to declare a limited number of domains in related website sets that are meaningful and used for specific purposes. Google may block or suspend any exploitative use of this feature.

\n

The top-level site can also request approval for specific cross-site resources and scripts to Storage Access API using resuestStorageAccessFor() API.

\n

If you’re using an external identity provider for your web application, you can declare the domain of the identity provider in the related set to ensure limited third-party cookies and storage access to the identity provider, thus ensuring seamless user authentication.

\n

Related Website Sets can also work to supplement third-party cookie restrictions in web SSO and federated SSO if the number of web applications (or domains) is limited.

\n

Federated Credential Management (FedCM) API

\n

FedCM API enables federated SSO without third-party cookies.

\n

With FedCM API, a user follows these steps for authentication:

\n
    \n
  1. The User navigates to a Service Provider (SP) — aka., Relying Party (RP)
    2. \n
  2. As the user requests to authenticate, the SP requests the browser through FedCM API to initiate authentication.
    3. \n
  3. The browser displays a list of available identity providers (supported by the RP), such as social IdPs like Google, Apple, LinkedIn, and Facebook, or other OAuth IdPs like LoginRadius.
    4. \n
  4. Once the user selects an IdP, the browser communicates with the IdP. Upon valid authentication, the IdP generates a secure token.\nThe browser delivers this secure token to the RP to facilitate user authorization.
    5. \n
\n

You can access a user demo of FedCM here: FedCM.

\n

For more information about implementing federated SSO with FedCM API, go through the FedCM developer guide.

\n\n

Firstly, we’re committed to solving our customers' user identity pain points — and preparing for the third-party cookies phase-out is no different.

\n

We’ll implement the most relevant and widely useful solutions to facilitate a smooth transition for our customers.

\n

Please subscribe to our blog for more information. We’ll update you on how we help with the third-party cookie phase-out.

\n

In Conclusion

\n

The proposed changes to phase out third-party cookies and suggested alternatives are evolving as Google has been actively collaborating and discussing changes with the border community.

\n

Moreover, browsers like Firefox, Safari, and Edge may approach restricting third-party cookies differently than Google does.

\n

From LoginRadius, we’ll keep you updated on what we’re doing as a leading Customer Identity and Access Management (CIAM) vendor to prepare for the third-party cookie phase-out.

\n

Glossary

\n

Top-level site: It is the primary site a user has visited.

\n

First-party cookie: A cookie set by the top-level site.

\n

Third-party cookie: A cookie set by a domain other than the top-level site. For example, let’s assume that a user has visited a.com, which might use an embed from loginradius.com to facilitate authentication. If loginradius.com sets a cookie when the user visits a.com, it is called a third-party cookie as the user hasn’t directly visited loginradius.com.

\n

References

\n\n","frontmatter":{"date":"July 08, 2024","updated_date":null,"description":"Google Chrome has planned to phase out third-party cookies, which will affect different website functionalities depending on third-party cookies. This blog focuses on how this phase-out affects identity and user authentication and discusses alternatives for overcoming challenges.","title":"How Chrome’s Third-Party Cookie Restrictions Affect User Authentication?","tags":["Identity","Cookies","Chrome"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/eb7396060c0adc430dbed2d04b63d431/ee604/third-party-cookies-phaseout-chrome.png","srcSet":"/static/eb7396060c0adc430dbed2d04b63d431/69585/third-party-cookies-phaseout-chrome.png 200w,\n/static/eb7396060c0adc430dbed2d04b63d431/497c6/third-party-cookies-phaseout-chrome.png 400w,\n/static/eb7396060c0adc430dbed2d04b63d431/ee604/third-party-cookies-phaseout-chrome.png 800w,\n/static/eb7396060c0adc430dbed2d04b63d431/f3583/third-party-cookies-phaseout-chrome.png 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Raghunath Reddy","github":"raghunath-r-a","avatar":null}}}},"pageContext":{"limit":6,"skip":24,"currentPage":5,"type":"//engineering//","numPages":52,"pinned":"17fa0d7b-34c8-51c4-b047-df5e2bbaeedb"}},"staticQueryHashes":["1171199041","1384082988","2100481360","23180105","528864852"]}