![\"Flowchart](\"/f29edbf2978577390c7ffa02e9bc4dda/lr-JWT-authentication.webp\")
Ever wondered how apps like Spotify, Netflix, or Slack manage seamless login experiences across devices? Many of them use JWT, or JSON Web Tokens, a compact, stateless method for securely transmitting user identity and session data across services.
\nWith JWT token authentication, identity information is embedded in a signed token, allowing you to maintain user sessions without server-side storage. This approach is highly scalable and ideal for modern architectures like SPAs, mobile apps, and microservices.
\nIn this blog, we’ll walk you through what is JWT, why use it, and how to implement JWT authentication using LoginRadius.
\nYou’ll learn what JWT is, why it’s effective, and how it works in real-world applications. We'll cover both integration methods (IDX and Direct API), generating your signing key, managing sessions, storing the JWT token securely, and applying best practices throughout.
\nWhether you're a developer, product manager, or IAM architect, this guide offers a complete foundation for implementing JWT token authentication into your application stack.
\nJSON Web Token (JWT) is an open standard (RFC 7519) used to transmit information securely between parties as a JSON object. It’s compact, self-contained, and digitally signed, making it a reliable format for authentication and authorization across modern applications.
\nA JWT consists of three parts:
\nExample of a token structure:
\n<base64Header>.<base64Payload>.<signature>
\n
JWT simplifies identity verification, especially when you're building apps that talk to APIs or need to scale without centralized session storage.
\nLoginRadius provides robust support for JWT (JSON Web Token) authentication, which allows for flexible and secure access control across different digital platforms. Whether you're building a fully custom identity flow or using a pre-built interface, the platform supports various integration approaches depending on your architecture.
\nIf you're looking to understand how to implement JWT token authentication effectively, LoginRadius offers two primary implementation models that cater to different levels of customization and control:
\nThe IDX-hosted login approach enables secure, standards-compliant, JWT-based authentication without requiring you to build a custom login interface. This is a strategic option for fast, compliant, and user-friendly deployments.
\n![\"Screenshot](\"/9fb19dd9c88c7916aeebd03ab6e661b7/lr-admin-console.webp\")
{
\n\"access_token\": \"eyJhbGciOiJIUzI1NiIsInR...\",
\n\"expires_in\": 1800
\n}
\nThis integration approach works best for all teams that want effective identity workflows without the complexity of building proprietary login screens, something that is crucial for customer portals, onboarding of mobile applications, and even managing access for business partners.
\nIf you’re building a custom login UI or working in a headless environment, LoginRadius lets you generate and handle JWTs directly through its Authentication APIs. Here’s how you can programmatically perform token authentication using the classic method:
\nSend a POST login request to the LR Authentication URL:
\nPOST /identity/v2/auth/login
\nInclude the user’s credentials (email + password) in the request body.
\n{
\n\"access_token\": \"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...\",
\n\"expires_in\": 3600
\n}
\nWith LoginRadius, it is possible to customize the payload to include user roles and/or any additional metadata. You can set custom JWT claims on the Admin Console.
\nWith this method, you have complete customization over login flows while using LoginRadius to issue signed JWTs for user session management.
\nNOTE- With either method, LoginRadius ensures that JWTs are securely signed, optionally short-lived, and compatible with standard token validation libraries, making integration seamless for everyone.
\nTo get started with JWT implementation, you can read our complete developer documentation.
\n![\"Illustration](\"/15ec02ac98d24a9f1f28e5d0f06b9174/IDX-vs-Direct-API-JWT.webp\")
Session management is how your app keeps track of a user after they log in so they don’t have to prove who they are with every request.
\nIn traditional apps, sessions are stored on the server using session IDs. Every time a request comes in, the server checks that session ID to verify the user.
\nIn modern apps, especially SPAs and APIs, JWTs are used to manage sessions without needing server-side storage; this is called stateless session management. The token itself carries the user’s identity, roles, and expiration details. As long as the token is valid, the user stays logged in.
\nGood session management ensures:
\nUser Logs In
\nClient Stores the Token
\nAccess Token Expiry
\nToken Renewal
\nWhen the user logs out, both the access token and refresh token should be cleared from client storage.
\nHowever, access tokens are stateless and cannot be revoked mid-lifecycle unless:
\nCombining these strategies gives you greater control over token misuse and enables a robust, enterprise-grade logout flow.
\n![\"illustration](\"/e55ae4bbc8ce62e13f03e46e29ebe7cc/api-economy.webp\")
When you implement JWT-based authentication, the client (browser or mobile app) needs a way to store the access token and, optionally, the refresh token after they are issued by the authentication server. This stored token is then attached to every subsequent request to prove the user's identity.
\nChoosing where to store the JWT is a crucial security decision. The most common storage options are:
\nEach option has trade-offs between security, accessibility, and persistence, and the right choice depends on your application's architecture and threat model.
\nAccess Tokens
\nRefresh Tokens
\nJWT authentication with LoginRadius offers a modern, stateless approach to managing sessions across distributed systems. The IDX integration is ideal for rapid deployment, while the Direct API model is best for organizations needing deep customization and integration flexibility.
\nWith robust token signing, refresh capabilities, and centralized control, LoginRadius provides a future-ready foundation for secure, scalable identity architecture. Contact us to know more about JWT authentication and implementation guide.
\nA: JWT authentication securely verifies user identities, enabling stateless session management across web, mobile apps, and microservices without server-side session storage.
\nA: LoginRadius simplifies JWT integration by offering hosted IDX login pages and direct API-based authentication methods, enabling rapid deployment and deep customization.
\nA: Yes, JWT authentication is secure when implemented with best practices like short-lived tokens, secure storage methods, signature validation, and refresh token rotation.
\nA: Yes, LoginRadius allows revocation of JWT refresh tokens explicitly, and supports strategies like short-lived tokens and key rotation to manage token lifecycles securely.
\n","frontmatter":{"date":"April 15, 2025","updated_date":null,"title":"JWT Authentication with LoginRadius: Quick Integration Guide","tags":["JWT","JSON Web Token","Authentication","Authorization"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":0.7782101167315175,"src":"/static/4cedb7829f98208cbc6d5a9aea4e983d/58556/how-to-integrate-jwt.webp","srcSet":"/static/4cedb7829f98208cbc6d5a9aea4e983d/61e93/how-to-integrate-jwt.webp 200w,\n/static/4cedb7829f98208cbc6d5a9aea4e983d/1f5c5/how-to-integrate-jwt.webp 400w,\n/static/4cedb7829f98208cbc6d5a9aea4e983d/58556/how-to-integrate-jwt.webp 800w,\n/static/4cedb7829f98208cbc6d5a9aea4e983d/1cc9f/how-to-integrate-jwt.webp 896w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Kundan Singh","github":null,"avatar":null}}}},{"node":{"fields":{"slug":"/engineering/guest-post/how-to-implement-jwt-authentication-in-deno/"},"html":"It is essential to protect your APIs for a secure experience, and JSON Web Token (JWT) authentication allows you to protect your APIs so that an unauthorized person will not have access.
\nThis is a hands-on tutorial to follow. To get the most out of it, ensure you have:
\nDeno is developed in Rust. It is a modern runtime environment for JavaScript/TypeScript and a WebAssembly that uses the Google V8 engine. It is simple and safe. It implements web platform standards and provides web platform capabilities.
\nDeno’s features are intended to enhance Node.js’s capabilities. It’s secure by default, with no access to files, networks, or the environment except explicitly enabled. And it supports both JavaScript and TypeScript out of the box.
\nDeno is a well-thought-out modular system. Apart from its simplicity and high security, there are so many other reasons to use Deno:
\nJSON Web Token, popularly called JWT, is an open standard that offers a concise and self-contained method for securely transferring data between parties as a JSON object. It holds information in an easy-to-access format for developers and computers; the token's compact size makes it simple to send through URL, POST parameter, or HTTP header. It allows two parties — a client and a server — to share information securely. A secret or public/private key pair is used to digitally sign the information in a JWT.
\nAuthentication is the primary use of JWT. It is assigned to a user after they sign in to an application, and with the assigned JWT, a user can request other routes.
\nWithout too many shenanigans, let's start by installing Deno!
\nDeno installation in Windows isn't as smooth sailing as on Mac or Linux. Unlike in Node.js, where you run a command on your terminal, Deno in Windows can be installed using PowerShell, Scoop (a command-line installer), or Chocolatey (a package manager). Click here for the guide on how to install Deno.
\nTo install Deno with PowerShell, open your PowerShell and run the following command:
\niwr https://deno.land/x/install/install.ps1 -useb | iexRelax while Deno is being installed. When completed, exit PowerShell and close and reopen a terminal. The new PATH is activated by closing and reopening the terminal. Now that you have installed Deno, let's check the version of Deno.
\nTo check the version of your installed Deno, run: deno -V
With installation out of the way, let us set up your project. Create a folder DenoAPI_JWT_Auth; you can call it any name you choose. Create an app.ts file and a folder src in your folder.
Inside your src folder, create the following folders: controllers, database, middlewares, routes, schema, and utils.
Your project directory should look as follows:
\nDenoAPI_JWT_Auth
│\n└─src
\n│ └───controllers
\n│ │\n│ └───database
\n│ │\n│ └───middlewares
\n│ │\n│ └───routes
\n│ │\n│ └───schema
\n│ │\n│ └───utils
\n└─app.ts
Next is to create your Oak server. Oak is a Deno middleware system that provides a router middleware for HTTP servers.
\nGo to app.ts, import Application from the Deno Oak URL, create an instance of the application, define your port, and call a middleware, as follows.
app.ts
import { Application } from "https://deno.land/x/oak/mod.ts";\n\nconst app = new Application();\nconst PORT = 8080;\n\n app.use((ctx, next) => {\n ctx.response.body = 'Welcome';\n next();\n });\n\nconsole.log(`Application is listening on port: ${PORT}`);\n\nawait app.listen({port:PORT});Let's quickly run your server: to run the server, use deno run --allow-net app.ts
Deno will always request permission to use your network. --allow-net gives Deno permission to all network calls.
You should see Application is listening on port: 8080
Now, in your routes folder, create a file called allRoutes.ts, and set up your router by importing Router from the oak URL, then create an instance of the router and export the default router.
routes.allRoutes.ts
import { Router } from "https://deno.land/x/oak/mod.ts";\n\nconst router = new Router();\n\nexport default router;Moving on, you need to modify app.ts. So, go to app.ts and import the router. Let the app use router.routes() and router.allowedMethods() methods, then remove the middleware, so it doesn't overshadow the imported routes. The allowedMethods() tells Deno to include all routes by your router.
app.ts
import { Application } from "https://deno.land/x/oak/mod.ts";\nimport router from "./src/routes/allRoutes.ts";\n\nconst app = new Application();\nconst PORT = 8080;\n\napp.use(router.routes());\napp.use(router.allowedMethods());\n\nconsole.log(`Application is listening on port: ${PORT}`);\n\nawait app.listen({port:PORT});You can rerun your app with the same command: deno run --allow-net app.ts
Now, you need to create user data. But before that, let's connect your application to the MongoDB database.
\ndatabase folderconnectBD.tsdatabase.connectDB.ts
import { MongoClient } from "https://deno.land/x/mongo@v0.30.0/mod.ts";\n\n // Connecting to a Mongo Database\n const client = new MongoClient();\n \n const dbString = "DB_String"\n\n await client.connect(dbString)\n \n console.log("Database connected!");\n \n const db = client.database("deno_auth");\n\n export default db;\n With that out of the way, let's create an interface for your database.
\nIn your schema folder, create a file user.ts, import objectId from deno MongoDB URL, then define and export your schema.
schema.user.ts
import {ObjectId} from "https://deno.land/x/mongo@v0.30.0/mod.ts";\n\nexport interface UserSchema {\n _id: ObjectId;\n username: string;\n password: string;\n }Let's play with some logic: go to your controllers folder, and create a file called users.ts. In the file, import your database and UserSchema.
It's not a good practice to store your password in plain text for security reasons. To has your password, let's import bcrypt from the deno bcrypt URL.
\nSo, create a function called signup that takes username and password. Take the user details from the request body, hash the password, and save them to your database.
controllers.users.ts
import db from "../database/connectBD.ts";\nimport * as bcrypt from "https://deno.land/x/bcrypt/mod.ts";\nimport { UserSchema } from "../schema/user.ts";\n\nconst Users = db.collection<UserSchema>("users");\n\nexport const signup = async({request, response}:{request:any;response:any}) => {\n const {username, password} = await request.body().value;\n const salt = await bcrypt.genSalt(8);\n const hashedPassword = await bcrypt.hash(password, salt);\n\n const _id = await Users.insertOne({\n username,\n password:hashedPassword\n });\n response.status =201;\n response.body = {message: "User created", userId:_id, user:username}\n \n};Now, head over to allRoutes.ts in your routes folder, import the signup function from the controller, and create a POST route for signup, as follows.
routes.allRoutes.ts
import { Router } from "https://deno.land/x/oak/mod.ts";\nimport {signup} from "../controllers/users.ts";\n\nconst router = new Router();\n\n//User routes\nrouter.post("/api/signup", signup)\n\nexport default router;Next, create an authentication route that authenticates your user route. The latest version of Deno does not allow a string as a secret key but accepts a cryptokey generated from a Web Crypto API with the generatekey() method of the SubtleCrypto interface.
So, head over to your utils folder, create a file called apiKey.ts, and in the file, generate your key and export it, as follows.
utils.apiKey.ts
export const key = await crypto.subtle.generateKey(\n { name: "HMAC", hash: "SHA-512" },\n true,\n ["sign", "verify"],\n );Now that you have successfully created your key, you can create a user authentication route so that every user that logs in will get authenticated.
\nHead over to user.ts in your controller, import the API key, create a signin function, and write some validation logic to validate that the user exists in your database. If validation is successful, you create a token to authenticate the user.
Now, let's import Deno JWT (djwt) create function from the URL to create a token. When a user logs in, take the id and username, pass the payload into the JWT create function, generate a token, and use the token to authenticate the user.
controllers.users.ts
import db from "../database/connectDB.ts";\nimport * as bcrypt from "https://deno.land/x/bcrypt/mod.ts";\nimport { UserSchema } from "../schema/user.ts";\nimport { create } from "https://deno.land/x/djwt@v2.4/mod.ts";\nimport { key } from "../utils/apiKey.ts";\n\nconst Users = db.collection<UserSchema>("users");\n\n //create a user\n export const signup = async({request, response}:{request:any;response:any}) => {\n const {username, password} = await request.body().value;\n const salt = await bcrypt.genSalt(8);\n const hashedPassword = await bcrypt.hash(password, salt);\n\n const _id = await Users.insertOne({\n username,\n password:hashedPassword\n });\n response.status =201;\n response.body = {message: "User created", userId:_id, user:username} \n};\n\n //sign in a user\n export const signin = async ({request, response}:{request:any; response:any}) => {\n\n const body = await request.body();\n const {username, password} = await body.value;\n\n const user = await Users.findOne({username});\n\n if(!user) {\n response.body = 404;\n response.body = {message: `user "${username}" not found`};\n return;\n }\n const confirmPassword = await bcrypt.compare(password, user.password);\n if(!confirmPassword){\n response.body = 404;\n response.body = {message: "Incorrect password"};\n return;\n }\n \n //authenticate a user\n const payload = {\n id: user._id,\n name: username\n };\n const jwt = await create({ alg: "HS512", typ: "JWT" }, { payload }, key);\n\n if(jwt) {\n response.status = 200;\n response.body = {\n userId: user._id,\n username: user.username,\n token: jwt,\n }\n } else {\n response.status = 500;\n response.body = {\n message: "internal server error"\n }\n }\n return;\n }So far, you have progressed well. The next thing is to import your signin function in the routes and create a post request for it, as follows.
routes.allRoutes.ts
import { Router } from "https://deno.land/x/oak/mod.ts";\nimport {signup, signin} from "../controllers/users.ts";\n\nconst router = new Router();\n\n//User routes\nrouter.post("/api/signup", signup)\n .post("/api/signin", signin);\n \n\nexport default router;Congratulations on making it this far! You are through with the authentication route. Now, you can register a user, sign in, and authenticate the user.
\nYou need to create your todo CRUD API and protect the routes so that a random person will not be able to access your route except when authenticated.
\nGo to your schema folder, and create a file task.ts. In the file, create your tasks interface and export it.
schema.task.ts
export interface TaskSchema {\n name: string;\n isCompleted: boolean;\n } After successfully creating the task interface, move to our controller, create a file tasks.ts, and import the database, schema, and object Id. Then write the logic for our todo CRUD API.
controllers.tasks.ts
import db from "../database/connectDB.ts";\nimport { TaskSchema } from "../schema/task.ts";\nimport {ObjectId} from "https://deno.land/x/mongo@v0.30.0/mod.ts";\n\nconst tasks = db.collection<TaskSchema>("tasks");\n\nexport const create = async({request, response}:{request:any;response:any}) => {\n const {name, isCompleted} = await request.body().value;\n\n const _id = await tasks.insertOne({\n name,\n isCompleted\n });\n response.body = {message: "Task created!!", id:_id, name:name, Completed:isCompleted}\n };\n\n export const getTasks = async ({response}:{response:any}) => {\n const allTasks = await tasks.find({}).toArray();\n\n response.status = 200;\n response.body = {tasks:allTasks};\n };\n\n export const getById = async ({\n params,\n response\n }:{\n params:{taskId:string};\n response:any;\n }) => {\n const taskId = params.taskId;\n const task = await tasks.findOne({_id:new ObjectId(taskId)});\n\n if(!task){\n response.body = {message: `no task with Id: ${taskId}`};\n return;\n}\n response.status = 200;\n response.body = {task: task}\n};\n\nexport const updateById = async ({\n params,\n request,\n response\n}:{\n params:{taskId:string};\n request:any;\n response:any;\n}) => {\n const taskId = params.taskId;\n const {name, isCompleted} = await request.body().value;\n const task = await tasks.updateOne({_id:new ObjectId(taskId)},\n {$set:{name:name, isCompleted:isCompleted}});\n\n response.status = 200;\n response.body = {message:"Updated task", task:task};\n};\n\nexport const deleteTask = async ({\n params,\n response,\n}:{\n params:{taskId:string};\n response:any;\n}) => {\n const taskId = params.taskId;\n const task = await tasks.deleteOne({_id:new ObjectId(taskId)});\n response.status = 200;\n response.body = {message:"Deleted task", task:task};\n};With that out of the way, you need to create your todo CRUD routes. So, head over to allRoutes.ts and import the CRUD functions from the task controllers, then create the routes for our todo, as follows.
routes.allRoutes.ts
import { Router } from "https://deno.land/x/oak/mod.ts";\nimport {signup, signin} from "../controllers/users.ts";\nimport {create, getTasks, getById, updateById, deleteTask} from "../controllers/tasks.ts";\n\nconst router = new Router();\n\n//User routes\nrouter.post("/api/signup", signup)\n .post("/api/signin", signin);\n\n//Task routes\nrouter.post("/api/tasks", create)\n .get("/api/tasks", getTasks)\n .get("/api/tasks/:taskId", getById)\n .patch("/api/tasks/:taskId", updateById)\n .delete("/api/tasks/:taskId", deleteTask);\n\nexport default router;You need to protect your todo routes so that an unauthorized person will not be able to access them.
\nTo protect the todo routes, go to your middlewares folder: create a file called isAuthorized.ts, import the verify function from deno JWT URL, import Context from deno, import the secret key you've created, and create the authorized function.
The authorize function checks if a user has a JWT token, grant the user access if he does, and deny him access if otherwise.
\nmiddlewares.isAuthorized.ts
import { verify } from "https://deno.land/x/djwt@v2.4/mod.ts";\nimport { key } from "../utils/apiKey.ts";\nimport { Context } from "https://deno.land/x/oak/mod.ts";\n\nexport const authourized = async (ctx: Context, next:any) => {\n try{ \n const headers: Headers = ctx.request.headers;\n const authorization = headers.get('Authorization');\n if(!authorization) {\n ctx.response.status = 401;\n return;\n }\n const jwt = authorization.split(' ')[1];\n\n if(!jwt) {\n ctx.response.status = 401;\n return;\n }\n const payload = await verify(jwt, key);\n\n if(!payload){\n throw new Error("!payload")\n }\n await next();\n \n } catch (error) {\n ctx.response.status = 401;\n ctx.response.body ={message: "You are not authorized to access this route"}\n return;\n }\n};To protect your todo routes, import the authorized middleware function from the isAuthorized.ts middleware file and pass the middleware into the todo routes to protect them from unauthorized people.
routes.allRoutes.ts
import { Router } from "https://deno.land/x/oak/mod.ts";\nimport {signup, signin} from "../controllers/users.ts";\nimport {create, getTasks, getById, updateById, deleteTask} from "../controllers/tasks.ts";\nimport { authourized } from "../middlewares/isAuthorized.ts";\n\nconst router = new Router();\n\n//User routes\nrouter.post("/api/signup", signup)\n .post("/api/signin", signin);\n\n//Task routes\nrouter.post("/api/tasks", authourized, create)\n .get("/api/tasks", authourized, getTasks)\n .get("/api/tasks/:taskId", authourized, getById)\n .patch("/api/tasks/:taskId", authourized, updateById)\n .delete("/api/tasks/:taskId", authourized, deleteTask);\n\nexport default router;Awesome! Your application is ready, but wait! Don't get too excited yet, relax let's test the application :)
\nBelow is what your final project directory looks like:
\nDenoAPI_JWT_Auth
│
\n└─src
\n│ └───controllers
\n│ │ └───users.ts
\n│ │ └───tasks.ts
\n│ │\n│ └───database
\n│ │ └───connectDB.ts
\n│ │
\n│ └───middlewares
\n│ │ └───isAuthorized.ts
\n│ │
\n│ └───routes
\n│ │ └───allRoutes.ts
\n│ │\n│ └───schema
\n│ │ └───user.ts
\n│ │ └───task.ts
\n│ │\n│ └───utils
\n│ │ └───apiKey.ts
\n│ │
\n└─app.ts
Now that your application is ready, you need to test the various routes to ensure they are working. To test the routes, rerun your server with deno run --allow-net app.ts.
![\"deno](\"/62ae9cc872cb4e6726bf38887a6f95f2/apk23wt.webp\")
Great! The app is running on port:8080. You can now head to the postman to test your routes.
\n![\"Sign](\"/2737369979374f3a18b07747fbc29495/d2orbz0.webp\")
![](\"/d122648378e66a04ba9f5ccea186d791/trydtxn.webp\")
![\"Signin](\"/6c3a13c7403199d459243429bd206718/fee5d0s.webp\")
![\"Signin](\"/76e7addc166b0dfbc834423b2f8c664f/wncqtya.webp\")
Amazing! Now that you have signed up and authenticated a user, the returned token, which shows that the user has been authenticated, can be used to access your todo CRUD APIs.
\nFirst, let's try accessing your todo routes without the token...
\n![\"Create](\"/ecc4bd696513d61205cf9a4330f631ed/0bohcxv.webp\")
![\"Create](\"/821f749c0ad4c42017623a3bce8034d2/q6eetmg.webp\")
As you can see, when you tried to create a task, you got a message You are not authorized to access this route because a random person did it without a token.
Now, let's also try accessing the delete by Id route without the token...
\n![\"Delete](\"/3c361eebddb2e01593ae8bbde40dbce6/ngozekb.webp\")
![\"Delete](\"/1490faa5e0338c8995b8f22555595236/cdkr6ad.webp\")
Your todo CRUD APIs have been protected, and the only way a user can access them is by getting authenticated. Now let's log in again and use the returned token to access the todo routes.
\n![\"Tasks\"](\"/540a044d27006d91a86d4db1928b0c73/ehp4zwf.webp\")
So, you have logged a user in and put the returned Bearer's token in the authorization header. You can access our todo APIs now because, with the bearer's token, you are authorized to access the todo APIs.
\n![\"Create](\"/ecc4bd696513d61205cf9a4330f631ed/y9ilrk9.webp\")
![\"Create](\"/0592e46a3e4261079c741e095e5a987e/nbiaskx.webp\")
![\"Get](\"/990cf69f38c62c2d8e240d8f30d49ef8/zosrr9u.webp\")
![\"Get](\"/12178b6a0d02f0b42eb81d6d4c8be97b/zxkgmsm.webp\")
![\"Get](\"/3c361eebddb2e01593ae8bbde40dbce6/hph0xmy.webp\")
![\"Get](\"/a1856e78c8c2916792aefec9834c48f7/get-task-by-id.webp\")
Feel free to test the other routes to see how things work.
\nIn this tutorial, you've built a todo CRUD API and protected the routes from unauthorized access using JSON Web Token (JWT). You have learned how to create an Oak server in Deno, connect MongoDB, implement JWT authentication, as well as create and authenticate CRUD routes in a Deno application.
\nThe code for this tutorial is available here on Github. Feel free to clone and extend the features of the application.
\n","frontmatter":{"date":"July 28, 2022","updated_date":null,"title":"How to Implement JWT Authentication for CRUD APIs in Deno","tags":["JWT","Deno","Authentication"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/ecb7a333dd6ee8ea03a2f5cc6c9633c2/58556/jwt-authentication-with-deno.webp","srcSet":"/static/ecb7a333dd6ee8ea03a2f5cc6c9633c2/61e93/jwt-authentication-with-deno.webp 200w,\n/static/ecb7a333dd6ee8ea03a2f5cc6c9633c2/1f5c5/jwt-authentication-with-deno.webp 400w,\n/static/ecb7a333dd6ee8ea03a2f5cc6c9633c2/58556/jwt-authentication-with-deno.webp 800w,\n/static/ecb7a333dd6ee8ea03a2f5cc6c9633c2/99238/jwt-authentication-with-deno.webp 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Ekekenta Odionyenfe Clinton","github":"icode247","avatar":null}}}},{"node":{"fields":{"slug":"/engineering/guest-post/loopback-rest-api-authentication/"},"html":"Authentication and authorization are critical in every software application to secure user data and allow access to trusted users. In some cases, implementing authentication and authorization is not an easy process.
\nHowever, LoopBack 4 offers an authentication package @loopback/authentication that helps secure your application's API endpoints. It provides custom authentication strategies and a @authenticate decorator that requires minimal boilerplate code.
\nAccording to the LoopBack 4 documentation:
\n\n\nLoopBack is a flexible, open source Node.js and TypeScript framework built on Express. It helps you quickly develop APIs and microservices built on backend systems such as databases and SOAP or REST services.
\n
Loopback provides several features that allow you to build your application with less boilerplate code.
\nJSON Web Token (JWT) is an open standard defined by Internet Engineering Task Force (IETF) in RFC 7519.
\nIt is a standard used for securely transferring claims between two parties over the internet. It uses JSON Web Signature (JWS) for the secure transfer of claims and eliminates the possibility of tampering. Accordingly, JWTs can be signed with either a secret (HMAC technique) or a public/private key pair (RSA or ECDSA).
\nIn simple words, it is used for authentication and secure information sharing. A JWT token is made up of three components that are separated by three dots:
\n\n\nYou can learn more about JWT and its best practices here.
\n
This tutorial is a hands-on demonstration. To follow along, be sure you have the following in place:
\nTo start building your LoopBack REST API, first install LoopBack CLI, which provides the quickest method to create a LoopBack 4 project that follows best practices.
\nUse the command below to install the Loopback CLI globally:
\nnpm i -g @loopback/cliYou can grab a cup of coffee while you wait for the installation to complete. Then open your command line, create an AuthWithLooback folder, and change the directory to the AuthWithLooback folder with commands below:
mkdir AuthWithLooback\ncd AuthWithLoobackSo, you've installed Loopback CLI and created a project directory. Let's run the following command to create a LoopBack project:
\nlb4 appSelect the options as in the following screenshot to complete the prompts.
\n![\"Creating](\"/982c31e4e0a8b99735b9e920e72e898f/l5wg0nTQ.webp\")
After completing the prompts, LoopBack will configure the TypeScript compiler and install all the required dependencies. Change directory to the auth-with-loopback folder.
cd auth-with-loopbackYou've successfully created your Loopback application. Now, let’s create a Model to store the news details with the command below:
\nlb4 modelSelect the options as in the following screenshot to complete the prompts.
\n![\"Creating](\"/3f73bef6f5422b16cc466d5f279701a9/lSCGXHs.webp\")
After the date_created property definition, press the enter key to exit the prompt.
Loopback will create a NewsModel file in the src/models — the folder where NewsModel will be defined.
Next, you need to create a data source to connect to your preferred database. For demonstration, this tutorial connects to a MongoDB database.
\nRun the following command in your terminal to create a data source:
\n lb4 datasourceSelect the options as in the following screenshot to complete the prompts.
\n![\"Creating](\"/aa8582e5de5c7011c46a43242342a5d2/pHvPgEQA.webp\")
After completing the prompts, LoopBack will create the News file in the src/datasource folder.
Then, create a Repository for CRUD operations of your NewModel with the command below:
\nlb4 repositoryAfter completing the prompts, LoopBack will create the NewsModelRepository file in the src/repository folder.
Select NewsDatasource as the data source, NewsModel as the model for generating the repository, and DefaultCrudRepository as the base repository class.
Your selection for the prompts shall look like the screenshot below.
\n![\"Creating](\"/7789349e93d10cfc0800e4f822e581ca/WWH5tYJQ.webp\")
After completing the prompts, LoopBack will create the NewsModelRepository file in the src/repository folder.
Lastly, create a controller for the NewsModel you created with the command below:
lb4 controllerYour selection for the prompts should look like the screenshot below.
\n![\"Creating](\"/a22f45625db4bd560279a422e127665f/iHD6lPCg.webp\")
After completing the prompts, LoopBack will create the NewsController file in the src/controller folder. So far, your project structure, omitting the node_modules folder, should look as follows.
📦auth-with-loopback
\n┣ 📂public
\n┃ ┗ 📜index.html
\n┣ 📂src
\n┃ ┣ 📂tests
\n┃ ┃ ┣ 📂acceptance
\n┃ ┃ ┃ ┣ 📜home-page.acceptance.ts
\n┃ ┃ ┃ ┣ 📜ping.controller.acceptance.ts
\n┃ ┃ ┃ ┗ 📜test-helper.ts
\n┃ ┃ ┗ 📜README.md
\n┃ ┣ 📂controllers
\n┃ ┃ ┣ 📜README.md
\n┃ ┃ ┣ 📜index.ts
\n┃ ┃ ┣ 📜news-controller.controller.ts
\n┃ ┃ ┗ 📜ping.controller.ts
\n┃ ┣ 📂datasources
\n┃ ┃ ┣ 📜README.md
\n┃ ┃ ┣ 📜index.ts
\n┃ ┃ ┗ 📜news.datasource.ts
\n┃ ┣ 📂models
\n┃ ┃ ┣ 📜README.md
\n┃ ┃ ┣ 📜index.ts
\n┃ ┃ ┗ 📜news-model.model.ts
\n┃ ┣ 📂repositories
\n┃ ┃ ┣ 📜README.md
\n┃ ┃ ┣ 📜index.ts
\n┃ ┃ ┗ 📜news-model.repository.ts
\n┃ ┣ 📜application.ts
\n┃ ┣ 📜index.ts
\n┃ ┣ 📜migrate.ts
\n┃ ┣ 📜openapi-spec.ts
\n┃ ┗ 📜sequence.ts
\n┣ 📜.dockerignore
\n┣ 📜.eslintignore
\n┣ 📜.eslintrc.js
\n┣ 📜.gitignore
\n┣ 📜.mocharc.json
\n┣ 📜.prettierignore
\n┣ 📜.prettierrc
\n┣ 📜.yo-rc.json
\n┣ 📜DEVELOPING.md
\n┣ 📜Dockerfile
\n┣ 📜README.md
\n┣ 📜package-lock.json
\n┣ 📜package.json
\n┗ 📜tsconfig.json
Now that you have the Model setup, run the server, and add some custom data to the News collection in MongoDB.
\n #start the server\n npm run startThe above command will start the TypeScript compiler, which will build the project and check for possible errors. If everything goes well with the code, you should see the output on the terminal, as follows:
\n![\"Starting](\"/cf1c4681ababa5101284b580193e8bf3/lSCGXHnw.webp\")
Next, open your favorite browser and navigate to http://localhost:3000. You should see an output as follows:
![\"LoopBack](\"/321018f4c7be6074ce493ab2f711a5c2/hL9y8IIg.webp\")
Now, click on the explorer link, where you can make requests to your LoopBack application. On the explorer page, locate the post endpoint and add some custom data to the news collection by clicking the try it out button with the data below on the request body.
{\n "title": "Upgrade to Loopback V4",\n "body": "The developers of Loopback urges the V3 users to upgrade to V4 as soon as possible",\n "date_created": "2021-12-14T00:57:43.197Z"\n}Then, click the execute button to run the query.
![\"Executing](\"/905e332f7af326f984c298c9a6239c41/jiC_1P0A.webp\")
You can add as many records as you like to experiment with the endpoints. The important thing to note here is that the endpoints are not protected. Anyone may create, read, update, and delete records.
\nIn a moment, this tutorial explains how to secure the endpoints so that only logged-in users can access them.
\nTo begin, install LoopBack authentication and authentication-jwt, as follows:
npm i --save @loopback/authentication @loopback/authentication-jwtTo protect the application, you'll implement user authentication and authorization, which implies that only logged-in users will be able to access your APIs. You'll create two endpoints in the User controller:
\n/Signup endpoint: To handle user’s sign up./Login endpoint: To handle user’s login.You’ll start with the signup controller to enable users to create an account. Create an empty controller with the command below:
\n lb4 controllerYour selection for the prompts should be as follows:
\n![\"Creating](\"/c0653ec5c8a0f68a48e55ff2159137d4/6LCgT-Gw.webp\")
Then, open the src/controllers/user.controller.ts file, and import the required modules with the following code snippet:
import { authenticate, TokenService } from '@loopback/authentication';\n import {\n Credentials,\n MyUserService,\n TokenServiceBindings,\n User,\n UserRepository,\n UserServiceBindings,\n } from '@loopback/authentication-jwt';\n import { inject } from '@loopback/core';\n import { model, property, repository } from '@loopback/repository';\n import {\n get,\n getModelSchemaRef,\n post,\n requestBody,\n SchemaObject,\n } from '@loopback/rest';\n import { SecurityBindings, securityId, UserProfile } from '@loopback/security';\n import { genSalt, hash } from 'bcryptjs';\n import _ from 'lodash';\n ........Next, set up your user credential objects, and verify the user credentials using the UserService, injecting MyUserService into the authentication-jwt extension.
@model()\n export class CreateUser extends User {\n @property({\n type: 'string',\n required: true,\n })\n password: string;\n }\n\n const UserSchema: SchemaObject = {\n type: 'object',\n required: ['email', 'password'],\n properties: {\n email: {\n type: 'string',\n format: 'email',\n },\n password: {\n type: 'string',\n minLength: 6,\n },\n },\n };\n\n export const RequestBody = {\n description: 'The input of login function',\n required: true,\n content: {\n 'application/json': { schema: UserSchema },\n },\n };\n\n export class UserController {\n constructor(\n @inject(TokenServiceBindings.TOKEN_SERVICE)\n public jwtService: TokenService,\n @inject(UserServiceBindings.USER_SERVICE)\n public userService: MyUserService,\n @inject(SecurityBindings.USER, { optional: true })\n public user: UserProfile,\n @repository(UserRepository) protected userRepository: UserRepository,\n ) { }\n ..........Finally, you'll build your signup endpoint, which will listen to POST requests. Here, you shall save the hashed version of the user's password in the database to keep it safe.
\n @post('/signup', {\n responses: {\n '200': {\n description: 'User',\n content: {\n 'application/json': {\n schema: {\n 'x-ts-type': User,\n },\n },\n },\n },\n },\n })\n async signUp(\n @requestBody({\n content: {\n 'application/json': {\n schema: getModelSchemaRef(CreateUser, {\n title: 'NewUser',\n }),\n },\n },\n })\n newUserRequest: CreateUser,\n ): Promise<User> {\n const password = await hash(newUserRequest.password, await genSalt());\n const savedUser = await this.userRepository.create(\n _.omit(newUserRequest, 'password'),\n );\n\n await this.userRepository.userCredentials(savedUser.id).create({ password });\n\n return savedUser;\n }\n .........Now that you've set up the signup endpoint, create the login endpoint so that registered users may log in to the API.
\nUsing the code snippet below, set up the login route in the src/controllers/user.controller.ts file. In the event of a successful log-in, a token is sent to the user.
@post('/signin', {\n responses: {\n '200': {\n description: 'Token',\n content: {\n 'application/json': {\n schema: {\n type: 'object',\n properties: {\n token: {\n type: 'string',\n },\n },\n },\n },\n },\n },\n },\n })\n async signIn(\n @requestBody(RequestBody) credentials: Credentials,\n ): Promise<{ token: string }> {\n const user = await this.userService.verifyCredentials(credentials);\n const userProfile = this.userService.convertToUserProfile(user);\n const token = await this.jwtService.generateToken(userProfile);\n return { token };\n }Perhaps, you can show the currently logged-in user by adding a /whoami endpoint.
In the src/controllers/user.controller.ts file, get the details of the currently logged-in user using the code snippet below. Users should access this endpoint only when they are logged in.
@authenticate('jwt')\n @get('/whoami', {\n responses: {\n '200': {\n description: 'Return current user',\n content: {\n 'application/json': {\n schema: {\n type: 'string',\n },\n },\n },\n },\n },\n })\n async whoAmI(\n @inject(SecurityBindings.USER)\n loggedInUserProfile: UserProfile,\n ): Promise<string> {\n return loggedInUserProfile[securityId];\n }Now, open src/application.ts and bind the authentication components to your application class. First, import Loopback AuthenticationComponent, JWTAuthenticationComponent, and NewsDataSource from your datasources using the following code snippet:
//...\nimport { AuthenticationComponent } from "@loopback/authentication"\nimport {\n JWTAuthenticationComponent,\n UserServiceBindings,\n} from "@loopback/authentication-jwt"\nimport { NewsDataSource } from "./datasources"\n//...Then, mount the jwt authentication system and bind your NewsDataSource to the UserService data source.
//...\n// ------ ADD SNIPPET INSIDE THE CONTRUCTOR BLOCK ---------\nthis.component(AuthenticationComponent)\nthis.component(JWTAuthenticationComponent)\nthis.dataSource(NewsDataSource, UserServiceBindings.DATASOURCE_NAME)\n//...Finally, add the authenticate action in the Sequence. Also, modify the error when authentication fails to return status code 401 (Unauthorized). Open the src/sequence.ts file and add the code snippet below:
import { FindRoute, InvokeMethod, MiddlewareSequence, ParseParams, Reject, RequestContext, Send, SequenceActions, SequenceHandler } from '@loopback/rest';\n import {\n AuthenticateFn,\n AuthenticationBindings,\n AUTHENTICATION_STRATEGY_NOT_FOUND,\n USER_PROFILE_NOT_FOUND,\n } from '@loopback/authentication';\n import { inject } from "@loopback/core"\n export class MySequence implements SequenceHandler {\n constructor(\n @inject(SequenceActions.FIND_ROUTE) protected findRoute: FindRoute,\n @inject(SequenceActions.PARSE_PARAMS)\n protected parseParams: ParseParams,\n @inject(SequenceActions.INVOKE_METHOD) protected invoke: InvokeMethod,\n @inject(SequenceActions.SEND) protected send: Send,\n @inject(SequenceActions.REJECT) protected reject: Reject,\n @inject(AuthenticationBindings.AUTH_ACTION)\n protected authenticateRequest: AuthenticateFn,\n ) { }\n async handle(context: RequestContext) {\n try {\n const { request, response } = context;\n const route = this.findRoute(request);\n //call authentication action\n await this.authenticateRequest(request);\n // Authentication successful, proceed to invoke controller\n const args = await this.parseParams(request, route);\n const result = await this.invoke(route, args);\n this.send(response, result);\n } catch (error) {\n if (\n error.code === AUTHENTICATION_STRATEGY_NOT_FOUND ||\n error.code === USER_PROFILE_NOT_FOUND\n ) {\n Object.assign(error, { statusCode: 401/* Unauthorized */ });\n }\n this.reject(context, error);\n return;\n }\n }\n }So far, you've implemented user authentication for your API. Now, protect your News endpoints so that only authenticated users can access those routes.
\nOpen the src/controllers/news.controller.ts file, and import authenticate from jwt authentication.
import { authenticate } from "@loopback/authentication"Then on each of the endpoints in your news controller, add @authenticate('jwt') before the NewsController class, which will protect all the routes in NewsController.
//...\n @authenticate('jwt')\n //...Perhaps, you may not want to protect all the routes, simply add the @authenticate('jwt') method before the route you wish to protect. You can protect the POST route as follows:
@authenticate('jwt')\n @post('/news-models')\n @response(200, {\n description: 'NewsModel model instance',\n content: { 'application/json': { schema: getModelSchemaRef(NewsModel) } },\n })\n async create(\n @requestBody({\n content: {\n 'application/json': {\n schema: getModelSchemaRef(NewsModel, {\n title: 'NewNewsModel',\n exclude: ['id'],\n }),\n },\n },\n })\n newsModel: Omit<NewsModel, 'id'>,\n ): Promise<NewsModel> {\n return this.newsModelRepository.create(newsModel);\n }You've implemented user authentication in your REST API and secured the routes against unauthorized users. Let's put your application to the test. Press CTRL-C to exit the server and restart it with the following command:
npm startIf you open the explorer page, you should see the UserController endpoints.
![\"User](\"/1f93015b74e330c7dd57e99d9145a9d8/IaV4R43g.webp\")
If you try to execute any query on NewsController, you get a 404 (Unauthorized) error. So, sign up by clicking the /signup endpoint — and log in from the /users/login endpoint. On successful login, copy the token, scroll to the top, click on the Authorize button, and paste the token.
![\"Authorizing](\"/3308ca6960b64dab62adf3646b42032a/atU6nqmA.webp\")
Now you can execute queries on the NewController endpoints.
LoginRadius is a customer identity and access management (CIAM) platform for developers.
\nWhat does this mean for developers like you?
\nLoginRadius simplifies the process of user authentication, authorization, and management across web and mobile apps and APIs. It helps developers quickly implement this functionality so that developers, like you, can focus more on building core features that are essential to their apps.
\nLoginradius includes a plethora of enticing CIAM features such as passwordless authentication and social SSO (Twitter, Facebook, etc., based single sign-on).
\nImplementing user authentication with LoginRadius is a simple procedure. First, sign up for a Developer Pro trial or simply sign up for a forever free account here.
\nAnd you can explore what LoginRadius can do by using it for a Node.js application. You can learn more by going through LoginRadius Node.js developer documentation
\nThis tutorial taught you how to create user authentication in a LoopBack REST API by creating a small news database application.
\nYou can use the steps outlined in this tutorial to create any type of LoopBack REST API that requires user authentication and authorization.
\nI hope you enjoyed this tutorial! Feel free to contact me on Twitter.
\n","frontmatter":{"date":"February 04, 2022","updated_date":null,"title":"How to Secure Your LoopBack REST API with JWT Authentication","tags":["Authentication","LoopBack","JWT","Node.js"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/4a5b6d544acaf9e9a42893f7df9dd057/58556/secure-loopback-rest-api-with-jwt.webp","srcSet":"/static/4a5b6d544acaf9e9a42893f7df9dd057/61e93/secure-loopback-rest-api-with-jwt.webp 200w,\n/static/4a5b6d544acaf9e9a42893f7df9dd057/1f5c5/secure-loopback-rest-api-with-jwt.webp 400w,\n/static/4a5b6d544acaf9e9a42893f7df9dd057/58556/secure-loopback-rest-api-with-jwt.webp 800w,\n/static/4a5b6d544acaf9e9a42893f7df9dd057/99238/secure-loopback-rest-api-with-jwt.webp 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Ekekenta Odionyenfe Clinton","github":"icode247","avatar":null}}}},{"node":{"fields":{"slug":"/engineering/guest-post/nodejs-authentication-guide/"},"html":"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.
\nYou 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.
\nThis tutorial helps you:
\nYou have installed the following:
\nYou already understand JavaScript E56 Syntax.
\nNow that everything is in place, let's set up your database.
\nYou'll store all your user data — which includes username, password, and role — in MongoDB.
\nInstall a node package called Mongoose that will connect to MongoDB. Then create a user schema for your application.
npm init\nnpm install mongoosenpm init sets up your new project and creates a package.json file with the credentials.
After installing mongoose, create a new file db.js in the project's directory and require mongoose.
const Mongoose = require("mongoose")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 = connectDBThe code snippet here connects to mongodb://localhost:27017 and then specifies the name of the database /role_auth.
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.
You need to install some dependencies that you'll use in this tutorial.
\n npm i express nodemonExpress.js is a Node.js framework for building web applications quickly and easily.
\nNodemon is a tool that watches the file system and automatically restarts the server when there is a change.
\nYou 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:
const express = require("express")\nconst app = express()\nconst PORT = 5000\napp.listen(PORT, () => console.log(`Server Connected to port ${PORT}`))The next step is to test your application. Open up your package.json file and add the following to scripts:
"scripts": {\n "start": "node server.js",\n "dev": "nodemon server.js"\n}Open your terminal and run npm run dev to start the server.
Earlier, you've created a function that connects to MongoDB and exported that function. Now import that function into your server.js:
const connectDB = require("./db");\n...\n//Connecting the Database\nconnectDB();You also need to create an error handler that catches every unhandledRejection error.
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})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.
Schema is like a blueprint that shows how the database will be constructed.
\nYou'll structure a user schema that contains username, password, and role.
\nCreate 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:
// 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})In the schema, the username will be unique, required, and will accept strings.
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.
Now, you need to create a user model and export it:
\nconst User = Mongoose.model("user", UserSchema)\nmodule.exports = UserYou've created the user model by passing the UserSchema as the second argument while the first argument is the name of the model user.
You'll create functions that handle:
\nAs the name implies, this function will handle the registrations of users.
\nLet's create a new folder named Auth. It will contain the Authentication file and the Route set-up file.
After creating the Auth folder, add two files — Auth.js and Route.js.
Now open up our Auth.js file and import that User model:
const User = require("../model/User")The next step is to create an async express function that will take the user's data and register it in the database.
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:
const app = express()\napp.use(express.json())Let's go back to your Auth.js file and create the register function:
// 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}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.
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:
const express = require("express")\nconst router = express.Router()\nconst { register } = require("./auth")\nrouter.route("/register").post(register)\nmodule.exports = routerThe last step is to import your route.js file as middleware in server.js:
app.use("/api/auth", require("./Auth/route"))The server will use the router middleware function if there is a request to /api/auth.
You'll use Postman to test all the routes.
\nOpen up Postman to send a POST request to http://localhost:5000/api/auth/register and pass the username and password to the body:
![\"Register](\"/1ac77cdb1d6c5ebf46cf5171d74cf4a0/registerRoute.webp\")
You've created a function that adds registered users to the database. You have to create another function that will authenticate user credentials and check if the user is registered.
\nOpen the Auth.js file and create the Login function, as follows:
// 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}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:
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}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.
To set up the login route, import the login function into your route.js:
const express = require("express");\nconst router = express.Router();\nconst { register, login } = require("./auth");\n...\nrouter.route("/login").post(login);\nmodule.exports = router;Make a POST request at http://localhost:5000/api/auth/login and pass a valid username and password to the body:
![\"login](\"/bdcb632806567d22933fc46296bc322c/loginroute.webp\")
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:
//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}The first if statement verifies if role and id are present in the request body.
The second if statement checks if the value of role is admin. You should do this to avoid having over two roles.
After finding a user with that ID, you'll create a third if block that will check for the role of the user:
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 ...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\nThe numerous
\nifstatements might be a little bit tricky but understandable. Please read the comments in the above code block for better understanding.
Import the update function in your route.js, as follows:
const { register, login, update } = require("./auth");\n...\nrouter.route("/update").put(update);Send a put request to http://localhost:5000/api/auth/update:
![\"update](\"/0a64d4ef9c1c8955d9aed82aaf869472/updateroute.webp\")
The deleteUser function will remove a specific user from the database. Let's create this function in our auth.js file:
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}You remove the user based on the id you get from req.body.
deleteUser RouteOpen your route.js file to create a delete request to /deleteUser, using the deleteUser as its function:
const { register, login, update, deleteUser } = require("./auth");\n...\nrouter.route("/deleteUser").delete(deleteUser);deleteUser RouteSend a delete request to http://localhost:5000/api/auth/deleteUser by passing a valid id to the body:
![\"Delete](\"/5f7478fb8c45b5a5def8d442ab1d259c/deleteroute.webp\")
Saving user passwords in the database in plain text format is reckless. It is preferable to hash your password before storing it.
\nFor instance, it will be tough to decipher the passwords in your database if they are leaked. Hashing passwords is a cautious and reliable practice.
\nLet's use bcryptjs to hash your user passwords.
Lets install bcryptjs:
npm i bcryptjsAfter installing bcryptjs, import it into your auth.js
const bcrypt = require("bcryptjs")Instead of sending a plain text format to your database, lets hash the password using bcrypt:
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};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.
bcrypt will return a promise with the hashed password; then, send that hashed password to the database.
Send a POST request to http://localhost:5000/api/auth/register and pass the username and password to the body:
![\"Register](\"/1ac77cdb1d6c5ebf46cf5171d74cf4a0/Hashedregisterroute.webp\")
exports.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 try {\n const user = await User.findOne({ username })\n if (!user) {\n res.status(400).json({\n message: "Login not successful",\n error: "User not found",\n })\n } else {\n // comparing given password with hashed password\n bcrypt.compare(password, user.password).then(function (result) {\n result\n ? res.status(200).json({\n message: "Login successful",\n user,\n })\n : res.status(400).json({ message: "Login not succesful" })\n })\n }\n } catch (error) {\n res.status(400).json({\n message: "An error occurred",\n error: error.message,\n })\n }\n}bcrypt.compare checks if the given password and the hashed password in the database are the same.
Send a POST request to http://localhost:5000/api/auth/login and pass a valid username and password to the body:
![\"Hashed](\"/632b08fece37d70e9641393af6d9dbcd/hashedloginroute.webp\")
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.
\nJWT 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.
\nYou've to install JWT before using it in your application:
\nnpm i jsonwebtokenWhen 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:
node\nrequire("crypto").randomBytes(35).toString("hex")Output:
\n![\"Crypto\"](\"/ffc516c1cf1c578ae020aab9ea7bef3d/crypto.webp\")
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.
\nStore your secret string in a variable:
\nconst jwtSecret =\n "4715aed3c946f7b0a38e6b534a9583628d84e96d10fbc04700770d572af3dce43625dd"Once you've created your jwtSecret, import jsonwebtoken as the token in the register function:
...\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};The code snippet created the token using JWT's sign function. This function takes in three parameters:
jwtSecret as the second parameter; and,After passing all these arguments, JWT will generate a token. After the token is generated, send it as a cookie to the client.
\nAlso, generate a token for logged in users:
\nexports.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};To prevent unauthenticated users from accessing the private route, take the token from the cookie, verify the token, and redirect users based on role.
\nYou'll get the token from the client using a node package called cookie-parser. Let's install the package before using it:
npm i cookie-parserAfter installing it, import it into your server.js file and use it as a middleware:
const cookieParser = require("cookie-parser");\n...\napp.use(cookieParser());You'll create your middleware that verifies the token and grants access to your private route.
\nLet's create a new folder in the project's folder named middleware and create a file called auth.js.
Open the auth.js file and create the middleware:
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}The code snippet requests a token from the client, checks if a token is available, and verifies that token.
\nJWT verifies your token with your jwtSecret and returns a callback function. This function returns status code 401 if the token fails the authentication test.
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.
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:
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}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:
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"));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.
route.js:
const { adminAuth } = require("../middleware/auth")\nrouter.route("/update").put(adminAuth, update)\nrouter.route("/deleteUser").delete(adminAuth, deleteUser)You need to create an admin user in your database. Open up your terminal, and let's run some MongoDB methods:
\nmongoAfter mongo is started, you need to use the role_auth database:
use role_authBefore 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:
const password = require("bcryptjs").hash("admin", 10)\npasswordAfter you've created the constant password, you need to enter the password in the node terminal to get your hashed password.
![\"Node](\"/d3c1b2d70849b827aac61c69995a2f8f/nodebycrypt.webp\")
You'll use the hashed password to create your admin:
\ndb.users.insert({\n username: "admin",\n password: "$2a$10$mZwU9AbYSyX7E1A6fu/ZO.BDhmCOIK7k6jXvKcuJm93PyYuH2eZ3K",\n role: "admin",\n})To check if it was successfully created, run db.users.find().pretty() — this will output all users in the database.
You'll use Embedded JavaScript (EJS) to create a front-end for your application.
\nInstall the ejs package:
npm i ejsAfter you've installed ejs, you need to set ejs as your default view engine in your server.js file:
app.set("view engine", "ejs")When making a GET request to specific routes, you'll render an ejs file:
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"))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
Your home page will contain the links to /login and /register ejs file. Open up home.ejs and add these links:
<!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>Embedded JavaScript (EJS) supports HTML syntax. You'll create the registration form in register.ejs using HTML syntax:
<!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>You need to get the username and password that the user entered and pass it to the body when making the POST request:
...\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>The code snippet uses JavaScript's in-built library called fetch to send a POST request to /api/auth/register.
After the request has been sent, it stores the response to a constant res.
res.json will return the JSON you've passed as a response in the API.
When res.json returns the data, you store that data in a constant data.
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.
\nCreating your login form and adding functionality to it will be similar to that of your registration. Open login.ejs and create this form:
<!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> <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>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.
Open auth.js file in Auth folder:
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}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.
user RouteYou've rendered user.ejs when accessing the /user route. Now, you'll display all registered users to that route.
user.ejs:
<!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>You'll also display registered users to the admin route but add update and delete functionality to the route:
admin.ejs:
<!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>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:
<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>Deleting Users from the database should be the duty of an admin.
\nadmin.ejs:
<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>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\nPlease ensure the admin user is first on the list to avoid populating the database with an admin user again.
\n
To log out users, you need to remove the token from the client and redirect the client to the home page.
\nYou'll create a GET request to /logout in the server.js file:
app.get("/logout", (req, res) => {\n res.cookie("jwt", "", { maxAge: "1" })\n res.redirect("/")\n})The code snippet replaced the JWT token with an empty string and gave it a lifespan of 1 second.
\nAfter creating the GET request, add a logout button to the admin's route and user's route:
...\n<ul></ul>\n<button class="logout"><a href="/logout">Log Out</a></button>\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.
\nIn 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.
\nBasically, LoginRadius handles user registration, login, and authentication. Other features of LoginRadius include:
\nJWT, you can use this token to authenticate usersTo 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.
\nThis section briefly covers how authentication works with LoginRadius.
\nAfter signing up for LoginRadius, choose a name for your Node.js app.
\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.
![\"LoginRadius](\"/3c5de91ef87963f5ea96eb10556ba358/loginradius1.webp\")
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:
![\"LoginRadius](\"/faed37adab3b93cbf078cb49970ff8a6/loginradius.webp\")
https://<LoginRadius-APP-Name>.hub.loginradius.com/auth.aspx?action=login&return_url=<Return-URL>An instance of the link is given below:
\nhttps://noderoleauth.hub.loginradius.com/auth.aspx?action=login&return_url=http://localhost:5000You'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.
\nIn 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.
\nThen 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.
\nYou’ll then see how you can contrast the features, advantages, and disadvantages of each and also highlight specific use cases of each.
\nYou’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.
\nHow many times have you seen a popup on a website that says:
\n\n\nThis website is using cookies to store your information.
\n
I'm guessing so often that you've lost the count!
\nCookies 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.
\nHowever, 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.
\nIn 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.
\nLet's have a refresher on the history of cookies.
\nBack 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.
\nAs 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.
\nThat'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.
\nAlso, 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.
\nWhere 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.
\nWith 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.
\nBrowsers rolled out two storage mechanisms — local storage and session storage. So let's explore and understand them in detail.
\nLet's first take a peek at where the session storage resides in the browser:
\nOpen the developer tools in the browser and head over to the \"Application\" tab.
\n![\"Application](\"/0ebf0cdf4a93f440703feca7905c12d7/application-tab-screenshot.webp\")
Under the storage section, you'll find a section named \"Session Storage\".
\n![\"Session](\"/06434490c7d0ce18eb26570b842e3c03/session-storage-tab-screenshot.webp\")
There it is! Now, let's look at the features of browser's session storage.
\nSession 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!
\nAs 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.
\nYou can access the session storage in the window object:
window.sessionStorage\n//Storage {length: 0}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.
Let's add a key-value pair to the session storage using the setItem function available in the sessionStorage object:
sessionStorage.setItem("id", "123")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:
sessionStorage\n//Storage {id: '123', length: 1}You now get your recently added data back!
\nYou'll also see this inside the session storage section of the browser's application tab:
\n![\"Session](\"/b1a0553ff05f85ebaf162682253e4b26/session-storage-example-1.webp\")
Let's add a bit more complex JSON object in the session storage that looks like this:
\nconst 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}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:
sessionStorage.setItem("user_data", JSON.stringify(data))It should now appear inside the session storage of the browser's application tab:
\n![\"Complex](\"/f50ac32714fdfb933b604c04ba24e30b/session-storage-example-2.webp\")
Awesome! Let's take a look at retrieving this data.
\nYou 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.
sessionStorage.getItem("id")\n//'123'If you're retrieving an object, you'll need to use JSON.parse first to convert the string into a JavaScript object:
JSON.parse(sessionStorage.getItem("user_data"))Since data in session storage persists only across a browser tab, there are some unique usecases for session storage.
\nSession 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.
\nSince 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.
\nBlogging 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.
\nEvery 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.
\nUnder the application tab where session storage resides, you'll find a section called local storage right underneath it.
\n![\"Local](\"/416bc127a50f7d6d1aa5f726c5fe32d8/local-storage-tab-screenshot.webp\")
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.
\nUnlike 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.
\nThat means that data in a local storage persists even after a particular tab or browser window is closed.
\nYou 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.
For instance, you can add an item to the localStorage, as follows:
localStorage.setItem("id", "123")Consequently, you can retrieve an item using the getItem() function:
localStorage.getItem("id")\n//'123'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.
\nFor 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.
\nYou 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).
\nNow that you've understand how browser storage works, you can compare them effectively against cookies. However, let's first look at their similarities.
\nRemember 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.
\nIn 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.
\nBoth 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.
\nYou 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.
\nHowever, 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.
\nCookies 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![\"Comparison](\"/e8316b6440c807470cda0e44ad49aede/comparison-table.webp\")
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?
\nData 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.
\nThe 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.
\nAlso, 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.
\nBut 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.
\nNow 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.
\nHowever, 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.
\nFinally, 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,"title":"Local Storage vs. Session Storage vs. Cookies","tags":["Cookie","Browser Storage","Authentication","JWT"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/e9788df6bdd55f91b1eccb4382f05573/58556/blog-banner.webp","srcSet":"/static/e9788df6bdd55f91b1eccb4382f05573/61e93/blog-banner.webp 200w,\n/static/e9788df6bdd55f91b1eccb4382f05573/1f5c5/blog-banner.webp 400w,\n/static/e9788df6bdd55f91b1eccb4382f05573/58556/blog-banner.webp 800w,\n/static/e9788df6bdd55f91b1eccb4382f05573/99238/blog-banner.webp 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Siddhant Varma","github":"FuzzySid","avatar":null}}}},{"node":{"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.
\nPreviously, 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.
\nAs 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.
\nJSON 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\nLearn more about the differences between sessions and JWTs here.
\n
JWT offers many benefits. Here are some of them.
\nNow that you've learned about the advantages, it's time to go deeper into the JWT.
\neyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9\n .eyJpc3MiOiJodHRwczpcL1wvcWEtYXBpLndlbGx2aWJlLmNvbVwvYXBpXC9hdXRoXC9sb2dpbiIsImlhdCI6MTYzMDQ3OTA5NSwiZXhwIjoxNjMwNDgyNjk1LCJuYmYiOjE2MzA0NzkwOTUsImp0aSI6Imtsa3hHUGpMOVlNTzRSdUsiLCJzdWIiOjc3ODE4LCJwcnYiOiIyM2JkNWM4OTQ5ZjYwMGFkYjM5ZTcwMWM0MDA4NzJkYjdhNTk3NmY3IiwidXNlcnNfaWQiOjc3ODE4LCJtZW1iZXJzX2lkIjo3Nzg4MzMsInByb3h5X3VzZXJfbWVtYmVyc19pZCI6bnVsbH0\n .TxXwLLu1zWBe7cLLYdFYy3P2HX4AaLgc7WfSRtTgeiIThe 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.
\nThe 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.
\nYou can quickly obtain the JWT's headers using symmetric or asymmetric encryption techniques.
\nThe 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.
\nA 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.
\nThe 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.
\nAs 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.
\nThis article creates a simple login page and authenticates it using JWT. This will help you get started with JWT and PHP.
\nTo follow along, you'll need to have PHP and composer installed on your computer.
\nIf 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.
\nOnce 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.
<?php\ndeclare(strict_types=1);\nuse Firebase\\JWT\\JWT;\nrequire_once('../vendor/autoload.php');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.
<?php\n// extract credentials from the request\nif ($hasValidCredentials) {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.
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:
\nJWT'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];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.
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.
\nIt 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.
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}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.
\nFirst, 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.
\nHere is some sample code for the process mentioned above.
\nconst 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})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.
\nAs 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.
The following code will help you achieve this feat.
\nbtnResource.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})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.
\nGET /resource.php HTTP/1.1\nHost: yourhost.com\nConnection: keep-alive\nAccept: */*\nX-Requested-With: XMLHttpRequest\nAuthorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwczpcL1wvcWEtYXBpLndlbGx2aWJlLmNvbVwvYXBpXC9hdXRoXC9sb2dpbiIsImlhdCI6MTYzMDQ3OTA5NSwiZXhwIjoxNjMwNDgyNjk1LCJuYmYiOjE2MzA0NzkwOTUsImp0aSI6Imtsa3hHUGpMOVlNTzRSdUsiLCJzdWIiOjc3ODE4LCJwcnYiOiIyM2JkNWM4OTQ5ZjYwMGFkYjM5ZTcwMWM0MDA4NzJkYjdhNTk3NmY3IiwidXNlcnNfaWQiOjc3ODE4LCJtZW1iZXJzX2lkIjo3Nzg4MzMsInByb3h5X3VzZXJfbWVtYmVyc19pZCI6bnVsbH0.TxXwLLu1zWBe7cLLYdFYy3P2HX4AaLgc7WfSRtTgeiIIf you've followed along until here, everything should be working fine. Now, let's begin with validating the JWT.
\nTo 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.
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}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.
\nTo 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}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.
\nDecoding 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.
\nThe decode method requires three arguments, which are as follows.
\nIf 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}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.
\nInstead 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.
\nIn 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.
\nIn this tutorial, you've learned about JWT. Then created a PHP web application and secured it with JWT authentication.
\nYou understood how easy and important it is to secure a web application.
\nYou can find the complete code used in this tutorial here.
\nDon't forget to try this out for your more significant projects.
\nFinally, 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,"title":"How to Secure a PHP API Using JWT","tags":["PHP","JWT","Authentication"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/b9e157a812c5801bd8d6ca83f317ee88/58556/jwt.webp","srcSet":"/static/b9e157a812c5801bd8d6ca83f317ee88/61e93/jwt.webp 200w,\n/static/b9e157a812c5801bd8d6ca83f317ee88/1f5c5/jwt.webp 400w,\n/static/b9e157a812c5801bd8d6ca83f317ee88/58556/jwt.webp 800w,\n/static/b9e157a812c5801bd8d6ca83f317ee88/99238/jwt.webp 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Harikrishna Kundariya","github":"espark-biz","avatar":null}}}},{"node":{"fields":{"slug":"/engineering/cookie-based-vs-cookieless-authentication/"},"html":"Securing communications between a client and a server often requires credentials to identify both parties. That is where the different authentication techniques comes in. Two popular authentication methods are cookie-based and cookieless authentication. However, choosing any one of them depends on the organization's requirements. Both come with their benefits and challenges. This article will give a quick walkthrough of cookie-based and cookieless authentication along with their advantages and disadvantages.
\nCookies are pieces of data used to identify the user and their preferences. The browser returns the cookie to the server every time the page is requested. Specific cookies like HTTP cookies are used to perform cookie-based authentication to maintain the session for each user.
\nThe entire cookie-based authentication works in the following manner:
\nThe server verifies the user by querying the user data. If the authentication request is valid, the server generates the following:
\nThe server then passes the session ID to the browser that keeps it. The server also keeps track of the active sessions.
\nCookieless authentication, also known as token-based authentication, is a technique that leverages JSON web tokens (JWT) instead of cookies to authenticate a user. It uses a protocol that creates encrypted security tokens. These tokens allow the user to verify their identity. In return, the users receive a unique access token to perform the authentication. The token contains information about user identities and transmits it securely between the server and client.\nThe entire cookieless authentication works in the following manner:
\nLoginRadius provides multiple methods to implement a cookieless login workflow leveraging industry and security best practices. As a consumer-centric Identity platform, LoginRadius ensures that modern implementation methodologies comply with the changing security landscape. The cookieless authentication workflows detailed below are systems that LoginRadius has developed support for even before the recent browser-based privacy policies and are a core part of the LoginRadius platform.
\nThe LoginRadius API has been architected and designed to function as a cookieless authentication system. Once authentication occurs, a session token gets returned to the requesting client in the form of an access token which can be leveraged to take further authorized actions against the Consumer account. It is a core part of the LoginRadius authentication workflows, and APIs developed based on Oauth 2.0 protocols.
\nThese APIs provide flexibility in generating access tokens based on consumer authentication requests and are automatically validated and signed leveraging the LoginRadius API Key and Secret. Detailed API documentation is available here.
\nIn addition to the LoginRadius APIs, JWTs are a standard method to handle cookieless login. Once authentication is completed and verified, a signed token can be generated(leveraging LoginRadius APIs) to pass the consumer session to the client.
\nJWTs are a standard industry mechanism leveraged by various service providers and tools, making them ideal for interoperability with multiple applications. Find additional details on how to use JWT as part of your authentication workflows here.
\nIn addition to the above two options, LoginRadius provides flexibility and support for various authentication and authorization standards that support a cookieless authentication approach. Outbound authentication workflows such as OIDC and Oauth 2.0 allow for a modern standardized approach to authentication.
\nThese are industry-recognized and recommended authentication and authorization protocols that comply with security and privacy best practices, including supporting a cookieless authentication approach. Check out our dedicated documentation on outbound workflows.
\nCookieless authentication can facilitate more secure and scalable authentication. You should decide how to authenticate consumers considering your requirements and the benefits and challenges of cookie-based and cookieless authentication.
\n","frontmatter":{"date":"December 14, 2021","updated_date":null,"title":"Cookie-based vs. Cookieless Authentication: What’s the Future?","tags":["Authentication","JWT","Cookie"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/0be9d40cc7bb77e9feb433ff59d7514a/58556/coverImage.webp","srcSet":"/static/0be9d40cc7bb77e9feb433ff59d7514a/61e93/coverImage.webp 200w,\n/static/0be9d40cc7bb77e9feb433ff59d7514a/1f5c5/coverImage.webp 400w,\n/static/0be9d40cc7bb77e9feb433ff59d7514a/58556/coverImage.webp 800w,\n/static/0be9d40cc7bb77e9feb433ff59d7514a/99238/coverImage.webp 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Kundan Singh","github":null,"avatar":null}}}},{"node":{"fields":{"slug":"/engineering/guest-post/securing-flask-api-with-jwt/"},"html":"Authentication is an essential part of any web application. But unfortunately, it is not always easy to implement.
\nAuthentication is a process of verifying that an entity is who they claim to be. For example, a user might authenticate by providing a username and password. If the username and password are valid, the system will check if the user can access the resource. After the system checks the user's details against its database and if the details are valid, the user is thus authenticated and can access available resources.
\nThe following factors are used to authenticate a user.
\nThis authentication is used when a user provides a username/email/phone number and a password. This is the most common and weakest authentication factor. The user simply inputs the email and password, and the system checks if the data is valid; if valid, the user gets authenticated and can access the resource. What happens if another person who is not a legitimate user tries to access the resource? The system denies access to the resource.
\nThis authentication uses more than one factor to authenticate a user. For example, the user tries to log in with, say, email and password; if the data is correct, a code is sent to the user's phone number, and the user is asked to input the code. If the user enters the code, the user gets logged in; otherwise, the user is not authenticated. Some applications even go a step further by not using two factors but using three factors.
\nThere are three types of authentication, as follows:
\nKnowledge authentication.In most applications, knowledge and property authentication are used as an extra layer of authentication.
\nThe following are the differences between authentication and authorization:
\nIn this tutorial, you'll work on authentication in flask middleware for an existing API built with Flask and PyMongo. The API is a book library API using which users can create books and upload cover images for the books and relevant data. PyMongo is used to connect to the mongo database. You'll use the PyJWT library to generate and verify JWT tokens for auth in flask.
\n\n\nYou can learn more about JSON Web Tokens (JWT) here.
\n
To get started, clone the repository and set up the application by running the following commands:
\ngit clone https://github.com/LoginRadius/engineering-blog-samples.git # Clone the repository\ncd /Flask/loginRadius-flask-auth # change directory\npython3 -m venv env # create virtual environment; if you're using Windows, `py -m venv env`\nsource env/bin/activate # activate virtual environment, if you're using windows, env/Scripts/activate\npip install -r requirements.txt # install dependencies\n# https://packaging.python.org/en/latest/guides/installing-using-pip-and-virtual-environments/The application is now set up and ready to run. You can run the app using the command flask run in the project directory. You can test that all the endpoints are working by testing the app in an API testing tool, like Postman.
As you've noticed, anybody can access the API; you need to restrict access to the API. Create new book data if they have the correct data, then add, delete, and update book data, but you don't want that. To do this, you need to implement an authentication middleware.
\nWhen we talk about authentication with flask, middlewares are created in Flask by creating a decorator; a function can have multiple middlewares, and the order matters a lot.
\nTo create your auth middleware, you need to install PyJWT -- the library you'll use to generate tokens. You’ll also use Pillow to alter image data before saving them to disk. Run the following command to install the packages:
\npip install pyjwt pillowYou need to add a secret key to your application; this is what you should pass to JWT.
\nAdd the following to your app.py file below the app declaration.
# app = Flask(__name__)\n\nSECRET_KEY = os.environ.get('SECRET_KEY') or 'this is a secret'\nprint(SECRET_KEY)\napp.config['SECRET_KEY'] = SECRET_KEYLet's create a file called auth_middleware.py in the root of your application and place the following inside this file:
from functools import wraps\nimport jwt\nfrom flask import request, abort\nfrom flask import current_app\nimport models\n\ndef token_required(f):\n @wraps(f)\n def decorated(*args, **kwargs):\n token = None\n if "Authorization" in request.headers:\n token = request.headers["Authorization"].split(" ")[1]\n if not token:\n return {\n "message": "Authentication Token is missing!",\n "data": None,\n "error": "Unauthorized"\n }, 401\n try:\n data=jwt.decode(token, current_app.config["SECRET_KEY"], algorithms=["HS256"])\n current_user=models.User().get_by_id(data["user_id"])\n if current_user is None:\n return {\n "message": "Invalid Authentication token!",\n "data": None,\n "error": "Unauthorized"\n }, 401\n if not current_user["active"]:\n abort(403)\n except Exception as e:\n return {\n "message": "Something went wrong",\n "data": None,\n "error": str(e)\n }, 500\n\n return f(current_user, *args, **kwargs)\n\n return decoratedThe function above is simply a decorator function. Inside this function, you check if there is an Authorization field in the headers part of the request; if this is missing, you return an authorization error.
Next, you check if it exists but is not valid; if it is not valid, you also return an authorization error.
\nIf everything goes fine, then the view function is called. As you can see, you return f(current_user, *args, **kwargs), where f is the next decorator or function that's being called after this decorator -- in your case, the view function, which means that the first argument of any view function that uses this decorator must be current_user.
You currently have a route to creating a new user, but you don't have one to log in. From what you have above, you're checking if the token passed as the header is valid, but now the question is -- how do you get to know the token. Basically, the login route fetches the token and sends it to the client.
\nAdd the following function below the add_user function:
@app.route("/users/login", methods=["POST"])\ndef login():\n try:\n data = request.json\n if not data:\n return {\n "message": "Please provide user details",\n "data": None,\n "error": "Bad request"\n }, 400\n # validate input\n is_validated = validate_email_and_password(data.get('email'), data.get('password'))\n if is_validated is not True:\n return dict(message='Invalid data', data=None, error=is_validated), 400\n user = User().login(\n data["email"],\n data["password"]\n )\n if user:\n try:\n # token should expire after 24 hrs\n user["token"] = jwt.encode(\n {"user_id": user["_id"]},\n app.config["SECRET_KEY"],\n algorithm="HS256"\n )\n return {\n "message": "Successfully fetched auth token",\n "data": user\n }\n except Exception as e:\n return {\n "error": "Something went wrong",\n "message": str(e)\n }, 500\n return {\n "message": "Error fetching auth token!, invalid email or password",\n "data": None,\n "error": "Unauthorized"\n }, 404\n except Exception as e:\n return {\n "message": "Something went wrong!",\n "error": str(e),\n "data": None\n }, 500So far, you've been able to create your auth middleware, but you need to use this middleware to protect routes. All you need to do is to pass this middleware immediately after the app.route middleware, then make current_user the first argument of the view function, as follows:
@app.route('/')\n@token_required\ndef user(current_user):\n return jsonify(current_user)\n\n@app.route('/<pdt_id>')\n@token_required\ndef product(current_user, pdt_id):\n return jsonify(Product.find({'user_id': pdt_id}))Add this middleware (@token_required) to every function you only want authenticated users to access. In the end, your whole app.py file should look as follows.
import jwt, os\nfrom dotenv import load_dotenv\nfrom flask import Flask, request, jsonify\nfrom save_image import save_pic\nfrom validate import validate_book, validate_email_and_password, validate_user\n\nload_dotenv()\n\napp = Flask(__name__)\nSECRET_KEY = os.environ.get('SECRET_KEY') or 'this is a secret'\nprint(SECRET_KEY)\napp.config['SECRET_KEY'] = SECRET_KEY\n\nfrom models import Books, User\nfrom auth_middleware import token_required\n\n@app.route("/")\ndef hello():\n return "Hello World!"\n\n@app.route("/users/", methods=["POST"])\ndef add_user():\n try:\n user = request.json\n if not user:\n return {\n "message": "Please provide user details",\n "data": None,\n "error": "Bad request"\n }, 400\n is_validated = validate_user(**user)\n if is_validated is not True:\n return dict(message='Invalid data', data=None, error=is_validated), 400\n user = User().create(**user)\n if not user:\n return {\n "message": "User already exists",\n "error": "Conflict",\n "data": None\n }, 409\n return {\n "message": "Successfully created new user",\n "data": user\n }, 201\n except Exception as e:\n return {\n "message": "Something went wrong",\n "error": str(e),\n "data": None\n }, 500\n\n@app.route("/users/login", methods=["POST"])\ndef login():\n try:\n data = request.json\n if not data:\n return {\n "message": "Please provide user details",\n "data": None,\n "error": "Bad request"\n }, 400\n # validate input\n is_validated = validate_email_and_password(data.get('email'), data.get('password'))\n if is_validated is not True:\n return dict(message='Invalid data', data=None, error=is_validated), 400\n user = User().login(\n data["email"],\n data["password"]\n )\n if user:\n try:\n # token should expire after 24 hrs\n user["token"] = jwt.encode(\n {"user_id": user["_id"]},\n app.config["SECRET_KEY"],\n algorithm="HS256"\n )\n return {\n "message": "Successfully fetched auth token",\n "data": user\n }\n except Exception as e:\n return {\n "error": "Something went wrong",\n "message": str(e)\n }, 500\n return {\n "message": "Error fetching auth token!, invalid email or password",\n "data": None,\n "error": "Unauthorized"\n }, 404\n except Exception as e:\n return {\n "message": "Something went wrong!",\n "error": str(e),\n "data": None\n }, 500\n\n\n@app.route("/users/", methods=["GET"])\n@token_required\ndef get_current_user(current_user):\n return jsonify({\n "message": "successfully retrieved user profile",\n "data": current_user\n })\n\n@app.route("/users/", methods=["PUT"])\n@token_required\ndef update_user(current_user):\n try:\n user = request.json\n if user.get("name"):\n user = User().update(current_user["_id"], user["name"])\n return jsonify({\n "message": "successfully updated account",\n "data": user\n }), 201\n return {\n "message": "Invalid data, you can only update your account name!",\n "data": None,\n "error": "Bad Request"\n }, 400\n except Exception as e:\n return jsonify({\n "message": "failed to update account",\n "error": str(e),\n "data": None\n }), 400\n\n@app.route("/users/", methods=["DELETE"])\n@token_required\ndef disable_user(current_user):\n try:\n User().disable_account(current_user["_id"])\n return jsonify({\n "message": "successfully disabled acount",\n "data": None\n }), 204\n except Exception as e:\n return jsonify({\n "message": "failed to disable account",\n "error": str(e),\n "data": None\n }), 400\n\n@app.route("/books/", methods=["POST"])\n@token_required\ndef add_book(current_user):\n try:\n book = dict(request.form)\n if not book:\n return {\n "message": "Invalid data, you need to give the book title, cover image, author id,",\n "data": None,\n "error": "Bad Request"\n }, 400\n if not request.files["cover_image"]:\n return {\n "message": "cover image is required",\n "data": None\n }, 400\n\n book["image_url"] = request.host_url+"static/books/"+save_pic(request.files["cover_image"])\n book["user_id"] = current_user["_id"]\n is_validated = validate_book(**book)\n if is_validated is not True:\n return {\n "message": "Invalid data",\n "data": None,\n "error": is_validated\n }, 400\n book = Books().create(**book)\n if not book:\n return {\n "message": "The book has been created by user",\n "data": None,\n "error": "Conflict"\n }, 400\n return jsonify({\n "message": "successfully created a new book",\n "data": book\n }), 201\n except Exception as e:\n return jsonify({\n "message": "failed to create a new book",\n "error": str(e),\n "data": None\n }), 500\n\n@app.route("/books/", methods=["GET"])\n@token_required\ndef get_books(current_user):\n try:\n books = Books().get_by_user_id(current_user["_id"])\n return jsonify({\n "message": "successfully retrieved all books",\n "data": books\n })\n except Exception as e:\n return jsonify({\n "message": "failed to retrieve all books",\n "error": str(e),\n "data": None\n }), 500\n\n@app.route("/books/<book_id>", methods=["GET"])\n@token_required\ndef get_book(current_user, book_id):\n try:\n book = Books().get_by_id(book_id)\n if not book:\n return {\n "message": "Book not found",\n "data": None,\n "error": "Not Found"\n }, 404\n return jsonify({\n "message": "successfully retrieved a book",\n "data": book\n })\n except Exception as e:\n return jsonify({\n "message": "Something went wrong",\n "error": str(e),\n "data": None\n }), 500\n\n@app.route("/books/<book_id>", methods=["PUT"])\n@token_required\ndef update_book(current_user, book_id):\n try:\n book = Books().get_by_id(book_id)\n if not book or book["user_id"] != current_user["_id"]:\n return {\n "message": "Book not found for user",\n "data": None,\n "error": "Not found"\n }, 404\n book = request.form\n if book.get('cover_image'):\n book["image_url"] = request.host_url+"static/books/"+save_pic(request.files["cover_image"])\n book = Books().update(book_id, **book)\n return jsonify({\n "message": "successfully updated a book",\n "data": book\n }), 201\n except Exception as e:\n return jsonify({\n "message": "failed to update a book",\n "error": str(e),\n "data": None\n }), 400\n\n@app.route("/books/<book_id>", methods=["DELETE"])\n@token_required\ndef delete_book(current_user, book_id):\n try:\n book = Books().get_by_id(book_id)\n if not book or book["user_id"] != current_user["_id"]:\n return {\n "message": "Book not found for user",\n "data": None,\n "error": "Not found"\n }, 404\n Books().delete(book_id)\n return jsonify({\n "message": "successfully deleted a book",\n "data": None\n }), 204\n except Exception as e:\n return jsonify({\n "message": "failed to delete a book",\n "error": str(e),\n "data": None\n }), 400\n\n@app.errorhandler(403)\ndef forbidden(e):\n return jsonify({\n "message": "Forbidden",\n "error": str(e),\n "data": None\n }), 403\n\n@app.errorhandler(404)\ndef forbidden(e):\n return jsonify({\n "message": "Endpoint Not Found",\n "error": str(e),\n "data": None\n }), 404\n\n\nif __name__ == "__main__":\n app.run(debug=True)Before running the application, let's look at the save_pic function inside the save_image.py file. This is the function responsible for saving uploaded pictures.
from PIL import Image\nimport secrets, os\nfrom flask import current_app as app\n\ndef save_pic(picture):\n file_name = secrets.token_hex(8) +os.path.splitext(picture.filename)[1]\n if not os.path.isdir(os.path.join(app.root_path, 'static')):\n os.mkdir(os.path.join(app.root_path,"static"))\n os.mkdir(os.path.join(app.root_path,"static/images"))\n os.mkdir(os.path.join(app.root_path,"static/images/books"))\n if not os.path.isdir(os.path.join(app.root_path, 'static/images')):\n os.mkdir(os.path.join(app.root_path,"static/images"))\n os.mkdir(os.path.join(app.root_path,"static/images/books"))\n if not os.path.isdir(os.path.join(app.root_path, 'static/images/books')):\n os.mkdir(os.path.join(app.root_path,"static/images/books"))\n file_path = os.path.join(app.root_path, "static/images/books", file_name)\n picture = Image.open(picture)\n picture.thumbnail((150, 150))\n picture.save(file_path)\n return file_nameYou should also add the following functions as helper methods of the User model class.
def disable_account(self, user_id):\n user = db.users.update_one(\n {"_id": bson.ObjectId(user_id)},\n {"$set": {"active": False}}\n )\n user = self.get_by_id(user_id)\n return user\n\ndef encrypt_password(self, password):\n return generate_password_hash(password)\n\ndef login(self, email, password):\n """Login a user"""\n user = self.get_by_email(email)\n if not user or not check_password_hash(user["password"], password):\n return\n user.pop("password")\n return userYour models.py file should look as follows:
"""Application Models"""\nimport bson, os\nfrom dotenv import load_dotenv\nfrom pymongo import MongoClient\nfrom werkzeug.security import generate_password_hash, check_password_hash\n\nload_dotenv()\n\nDATABASE_URL=os.environ.get('DATABASE_URL') or 'mongodb://localhost:27017/myDatabase'\nprint(DATABASE_URL)\nclient = MongoClient(DATABASE_URL)\ndb = client.myDatabase\n\nclass Books:\n """Books Model"""\n def __init__(self):\n return\n\n def create(self, title="", description="", image_url="", category="", user_id=""):\n """Create a new book"""\n book = self.get_by_user_id_and_title(user_id, title)\n if book:\n return\n new_book = db.books.insert_one(\n {\n "title": title,\n "description": description,\n "image_url": image_url,\n "category": category,\n "user_id": user_id\n }\n )\n return self.get_by_id(new_book.inserted_id)\n\n def get_all(self):\n """Get all books"""\n books = db.books.find()\n return [{**book, "_id": str(book["_id"])} for book in books]\n\n def get_by_id(self, book_id):\n """Get a book by id"""\n book = db.books.find_one({"_id": bson.ObjectId(book_id)})\n if not book:\n return\n book["_id"] = str(book["_id"])\n return book\n\n def get_by_user_id(self, user_id):\n """Get all books created by a user"""\n books = db.books.find({"user_id": user_id})\n return [{**book, "_id": str(book["_id"])} for book in books]\n\n def get_by_category(self, category):\n """Get all books by category"""\n books = db.books.find({"category": category})\n return [book for book in books]\n\n def get_by_user_id_and_category(self, user_id, category):\n """Get all books by category for a particular user"""\n books = db.books.find({"user_id": user_id, "category": category})\n return [{**book, "_id": str(book["_id"])} for book in books]\n\n def get_by_user_id_and_title(self, user_id, title):\n """Get a book given its title and author"""\n book = db.books.find_one({"user_id": user_id, "title": title})\n if not book:\n return\n book["_id"] = str(book["_id"])\n return book\n\n def update(self, book_id, title="", description="", image_url="", category="", user_id=""):\n """Update a book"""\n data={}\n if title: data["title"]=title\n if description: data["description"]=description\n if image_url: data["image_url"]=image_url\n if category: data["category"]=category\n\n book = db.books.update_one(\n {"_id": bson.ObjectId(book_id)},\n {\n "$set": data\n }\n )\n book = self.get_by_id(book_id)\n return book\n\n def delete(self, book_id):\n """Delete a book"""\n book = db.books.delete_one({"_id": bson.ObjectId(book_id)})\n return book\n\n def delete_by_user_id(self, user_id):\n """Delete all books created by a user"""\n book = db.books.delete_many({"user_id": bson.ObjectId(user_id)})\n return book\n\n\nclass User:\n """User Model"""\n def __init__(self):\n return\n\n def create(self, name="", email="", password=""):\n """Create a new user"""\n user = self.get_by_email(email)\n if user:\n return\n new_user = db.users.insert_one(\n {\n "name": name,\n "email": email,\n "password": self.encrypt_password(password),\n "active": True\n }\n )\n return self.get_by_id(new_user.inserted_id)\n\n def get_all(self):\n """Get all users"""\n users = db.users.find({"active": True})\n return [{**user, "_id": str(user["_id"])} for user in users]\n\n def get_by_id(self, user_id):\n """Get a user by id"""\n user = db.users.find_one({"_id": bson.ObjectId(user_id), "active": True})\n if not user:\n return\n user["_id"] = str(user["_id"])\n user.pop("password")\n return user\n\n def get_by_email(self, email):\n """Get a user by email"""\n user = db.users.find_one({"email": email, "active": True})\n if not user:\n return\n user["_id"] = str(user["_id"])\n return user\n\n def update(self, user_id, name=""):\n """Update a user"""\n data = {}\n if name:\n data["name"] = name\n user = db.users.update_one(\n {"_id": bson.ObjectId(user_id)},\n {\n "$set": data\n }\n )\n user = self.get_by_id(user_id)\n return user\n\n def delete(self, user_id):\n """Delete a user"""\n Books().delete_by_user_id(user_id)\n user = db.users.delete_one({"_id": bson.ObjectId(user_id)})\n user = self.get_by_id(user_id)\n return user\n\n def disable_account(self, user_id):\n """Disable a user account"""\n user = db.users.update_one(\n {"_id": bson.ObjectId(user_id)},\n {"$set": {"active": False}}\n )\n user = self.get_by_id(user_id)\n return user\n\n def encrypt_password(self, password):\n """Encrypt password"""\n return generate_password_hash(password)\n\n def login(self, email, password):\n """Login a user"""\n user = self.get_by_email(email)\n if not user or not check_password_hash(user["password"], password):\n return\n user.pop("password")\n return userHere's an example of the user request:
\n{\n "name" : "abc xyz",\n "email" : "xyz@gmail.com",\n "password" : "Abc@123"\n}Here, the name should have two words, and the password should have at least an uppercase later, a lower case letter, a digit, and a special character.
\nAnd an example of the book request:
\n{\n "title":"name of book",\n "cover_image": "path to image file locally",\n "category": "['romance', 'peotry', 'politics', 'picture book', 'science', 'fantasy', 'horror', 'thriller'],\n "description":"description",\n "user_id":"user_id"\n}While passing a book request, pass it via the form-data tab in Postman.
This article has explained flask JWT authentication .
\nIn some cases, handling flask authentication yourself may not be good enough or efficient -- to overcome this, you can simply use third-party authentication providers like LoginRadius. You can check out this tutorial to learn how to add LoginRadius to your Flask application.
\nYou can find the complete code for this article on Github. You can reach out to me on Twitter if you've any questions.
\n","frontmatter":{"date":"December 09, 2021","updated_date":null,"title":"Using JWT Flask JWT Authentication- A Quick Guide","tags":["Flask","JWT","API"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/1cfc51c7d9ade423f3b1992809ba5b1b/58556/coverImage.webp","srcSet":"/static/1cfc51c7d9ade423f3b1992809ba5b1b/61e93/coverImage.webp 200w,\n/static/1cfc51c7d9ade423f3b1992809ba5b1b/1f5c5/coverImage.webp 400w,\n/static/1cfc51c7d9ade423f3b1992809ba5b1b/58556/coverImage.webp 800w,\n/static/1cfc51c7d9ade423f3b1992809ba5b1b/99238/coverImage.webp 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Babatunde Koiki","github":"Babatunde13","avatar":null}}}},{"node":{"fields":{"slug":"/engineering/guest-post/jwt-authentication-best-practices-and-when-to-use/"},"html":"One of the most used authentication standards in web applications is the JSON Web Token standard. It is mostly used for authentication, authorization, and information exchange.
\nJSON Web tokens are made of three parts separated by dots (.) — and look like this typically: xxxxx.yyyyy.zzzzz. These correspond to the Header, the Payload, and the Signature. You can learn more about JWT tokens here.
And before using them and continuing to read this article, you might want to check the advantages compared to the session authentication method. You can learn more about JWTs vs. Sessions here.
\nAuthentication is done when a client successfully proves its identity via a login endpoint. If it's successful, the server will create JSON Web Token and send it in response to the client.
\nThe client will use this JWT on every request for a protected resource.
\nA server built on JWT for authorization will create a JWT when a client logs in. This JWT is signed, so any other party can’t alter it.
\nEach time the client has access to protected resources, the server will verify that the JWT’s signature matches its payload and header to determine that the JWT is valid.
\nThen if the JWT is successfully verified, it can grant or deny access to the resource.
\nJWT is also a great way to secure information transmission between parties — two servers, for example — and because you can verify the validity of the token (signature, structure, or the standards claimed in the JWT).
\nJWT doesn’t require any lookup of the database, so revoking them before the expiration is quite difficult.
\nRevocation is very important in many cases.
\nFor example, when logging out users or banning users, or changing permissions or passwords instantly, if the token hasn't been revoked, it might be possible for the user to continue to make requests even if this user no longer has the required authorization to do so.
\nJWT is usually signed to protect against data manipulation or alteration. With this, the data can be easily read or decoded.
\nSo, you can’t include sensitive information such as the user’s record or any identifier because the data is not encrypted.
\nThe size of a JWT is greater than the size of a session token. And this can quickly increase linearly as you add more data to the JWT. And because you need to send the JWT at each request, you're increasing the payload size. This can become heavily complex if there is a low-speed internet connection.
\nJWT can be used as an access token to prevent unwanted access to a protected resource. They're often used as Bearer tokens, which the API will decode and validate before sending a response.
\nAuthorization: Bearer <token>How do you get a new access token if this one is expired? The natural first idea is to log in again. But from a User Experience point, this can be quite painful.
\nJWT can be used as refresh tokens; these tokens are used to retrieve a new access token.
\nFor example, when a client requests a protected resource and receives an error, which can mean that the access token has expired, the client can be issued a new access token by sending a request with a refresh token in the headers or the body.\nIf the refresh token is valid, a new access token will be created and sent as a response.
\nNote that the refresh token is obtained at authentication and has a bigger lifetime.
\nInterestingly enough, JWT can be signed using many different algorithms. But let’s quickly talk about the alg value in the JWT header. When it’s decoded:
The alg value in JWT headers simply tells you how the JWT was signed. For example, with an alg value of RS512.
RS512 => RS 512 where RS is the signature algorithm and SHA-512 is the hashing algorithm.
SHA-512 will produce a 512-bits hash while SHA-256 will produce a 256-bit hash. And each of these algorithms gives you 50% of their output size of security level. This means that, for example, SHA-512 will provide you with 256-bits security.
In any case, make sure to use a minimum of 128-bit security.
JWTs are hard to revoke when they are created. Most of the time, you’ll have to wait until expiry. That’s why you should use a short expiration time.
\nAdditionally, you can implement your own revocation system.
\nJWT comes with a time-based claim iat — issued at. It can be used to reject tokens that are too old to be used by the resource server.\nAnd clock skew specifies the allowed time difference (in seconds) between the server and the client clocks when verifying exp and nbf time-based claims. The default recommended default value is 5.
The last part of a JWT is the signature, which is simply a MAC (or Message Authentication Code). This signature is created by the server using a secret key. This secret key is an important part of the JWT signature.
\nThere are two things to respect to decrease the probability of a secret key leaking or a successful brute force attack:
\nThe minimum key length must be equal to the size of bits of the hash function used along with the HMAC algorithm.
\n\n\n\"A key of the same size as the hash output (for instance, 256 bits for \"HS256\") or larger MUST be used with this algorithm.\" - JSON Web Algorithms (RFC 7518), 3.2 HMAC with SHA-2 Functions
\n
The easiest ways to store a token on the client side are localStorage and sessionStorage. However, both are vulnerable to XSS attacks, and sessionStorage is cleaned if the browser is closed.
A better, secure way is to store JWT in cookies. Cookies are not accessible via JavaScript, they can’t be read and written, and interestingly, they are automatically sent to the server.
\nOne of the main benefits of HTTPS is that it comes with security and trust. HTTP path and query parameters are encrypted when using HTTPS.
Then, there is no risk of someone intercepting the request, particularly the token in transit. These types of attacks are commonly called MitM (man in the middle) attacks that can be successful on compromised or insecure networks.
\nThis article discussed JWT and some best practices to fully use its potential.
\nJWT is simply an authentication standard with its pros and cons. Thus, knowing some best practices can really help you use JWT better.
\n","frontmatter":{"date":"October 14, 2021","updated_date":null,"title":"JWT Authentication — Best Practices and When to Use","tags":["JWT","Authentication"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/2f8d7e959c4e58511a3d83168d15cd6f/58556/cover-image.webp","srcSet":"/static/2f8d7e959c4e58511a3d83168d15cd6f/61e93/cover-image.webp 200w,\n/static/2f8d7e959c4e58511a3d83168d15cd6f/1f5c5/cover-image.webp 400w,\n/static/2f8d7e959c4e58511a3d83168d15cd6f/58556/cover-image.webp 800w,\n/static/2f8d7e959c4e58511a3d83168d15cd6f/99238/cover-image.webp 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Kolawole Mangabo","github":"koladev32","avatar":null}}}},{"node":{"fields":{"slug":"/engineering/guest-post/jwt-vs-sessions/"},"html":"In web applications, you try to decide when to use either JSON Web Tokens (JWTs) or sessions (cookies) for authentication. When you browse the web you use HTTP, which is a stateless protocol. So, the only way to remember the states of your application is using either sessions or tokens.
\nThis article deep dives into:
\nDeciding to choose between JWT or session is not just choosing one over the other. You need to look at some factors to determine which one to use in an application. In order to figure this out, you need to compare both approaches -- JWT and session -- to authenticate users.
\nThis article starts with how server-side sessions with a session store work, then looks at how client-side sessions with JWT work.
\n![\"authentication](\"https://paper-attachments.dropbox.com/s_483BCD9E50710AD4C34073FFCB4BDCD46B2FB758D7EDCF747C5F8981B4094012_1628279671087_How+sessions+work.webp\")
Suppose, you have a website with a login form. You enter your email ID and password, and your browser sends a request to the server. Your server compares the password hashes, and if those hashes match, a session is created with a specific session ID. Then, the server returns a cookie with the session ID and the cookie is HTTP only, so it can not be read by any javascript that is not yours. It is also secured so that the cookie is never transferred over an insecure connection; that is, something that is not encrypted. Otherwise, someone can intercept the communication, like a man in the middle attack.
\n![\"server-side](\"https://paper-attachments.dropbox.com/s_483BCD9E50710AD4C34073FFCB4BDCD46B2FB758D7EDCF747C5F8981B4094012_1628279971421_sessionswork2.webp\")
If you make a follow-up request, your browser automatically sends this cookie along. Take a look at the session ID and fish it out.
\n![\"client-side](\"https://paper-attachments.dropbox.com/s_483BCD9E50710AD4C34073FFCB4BDCD46B2FB758D7EDCF747C5F8981B4094012_1628281019519_Clientside.webp\")
Instead of creating a session in your session store, you check whether the password hashes match. And if they do match, you can just create a JSON signature token and the token is signed with the secret. If someone tries to modify the payload, you will know and the signature validation will fail.
\nYou can return the web signature token that can be put in a cookie, which is way better. Because, if you don't do that, there is a possibility that a third-party javascript can access it.
\nImagine a scenario in which a bank customer's info has been breached and the customer calls the bank to lock the account. This will be an issue if the bank uses JWT for authentication as JWT is stateless. Although you can find a workaround to do this by introducing state, it just defeats the purpose of having a JWT token in the first place, standing a chance of logging everyone out including the customer.
\nWith Sessions, logging out that one particular customer won’t be a problem at all as the customer's state is stored.
\nWhen using server-side sessions, you don't know who is currently logged into your application as this can be useful to inflict the history of what a person is currently doing. It’s a better idea to use sessions in industries like health care, banking, insurance, or companies that deal with money. It's also good to note that JWT is signed and anyone can read it or get an idea of how data or ID is structured, or how many rows data has, which is not the case for sessions as the data is not visible to users.
\nSession cookies take up very little bandwidth, whereas the bandwidth consumption will be higher in the JWT-based approach because the tokens tend to get bigger and you have the signature you have to send along for each follow up request; whereas if you have the session cookie, it's really small because its just the session ID that is being sent over.
\nA lot of breaches that happen in companies is a result of an internal breach from an employee or insider that is stealing data or doing weird things. It is really important to be able to revoke privileges immediately. Imagine a scenario where one person is locked in and has admin rights. Say, the token is valid for ten minutes or so. If for whatever reason you don't want that person to have admin privileges anymore, you can easily revoke the person's access if you use sessions, but might find it difficult if you use JSON web tokens.
\nThis section discusses the advantages of using JWT over sessions and scenarios where sessions do not cut it.
\nOne of the “issues” with sessions is scalability. The argument is that sessions are stored in memory and servers are duplicated to handle the application load, therefore, limiting the scalability of the application. JWT, on the other hand, has higher scalability due to its statelessness. If you use a load balancer, you can easily pass along your users to several servers without worrying, as there is no state or session data stored anywhere, making it easy for gigantic scale workloads like that of Google and Facebook.
\nA downside of the sessions is their maintainability, as the sessions need to be maintained. Somewhere on someone's server, a record will need to be created every time a user is authenticated. This is done in memory. The more the users are authenticated, the greater the overhead on your server. There is no need for maintainability in JWT as no state is stored, making it a better choice in this scenario.
\nWhen using sessions in an applications, there will come a time when you need to scale or expand the data for it to be used on multiple devices. Then, you'll need to worry about things like cross-origin resource sharing or even forbidden requests.
\nBut with JWT, you don't have to bother about CORS as you can provide data to all sorts of devices and applications. Setting up a quick header configuration gets rid of any CORS problem you would have encountered.
\nAccess-Control-Allow-Origin: *As long as a valid user has a valid token, data and resources are made available from any domain.
\nYou can easily allow selective permissions for third-party applications with the help of JWT. Say, you build an application that you like to share permissions with other applications; for instance, sharing a video you watched on Facebook to friends on Instagram. You can also get creative building APIs that hand the special tokens to other applications so that user data can be accessed.
\nAuth tokens are usually sent over the network and as such are vulnerable to attack. These kinds of attacks are:
\nAlthough it may seem that these types of attacks are not likely to happen, it's important to take security seriously and implement appropriate measures. The vulnerability of the system is based on the cumulative probabilities of all the types of attacks. In some ways, you can mitigate the above attacks:
\nDatabase and filesystem access: To control damage caused by unauthorized access to your database or filesystem, you could do the following:
\nSome people who use JSON web tokens return the token and store it in local storage. This can be very dangerous as third party javascript, browser extensions, and malicious CDN scripts can have access to the token. But if you put it in a cookie, no javascript access, or even you has access to it.
\nAnother thing to note is that when using cookies, you need to mitigate CSRF. Preventing it most of the time will have to do with installing a library and writing a few lines of code.
\nIn the article, you've learned the differences in using sessions and JSON web tokens for authentication, how serverside session store works, the advantages of sessions over JWT, and other things concerning the structure of JWT.
\n","frontmatter":{"date":"August 26, 2021","updated_date":null,"title":"How to Authenticate Users: JWT vs. Session","tags":["Authentication","JWT","Sessions"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/3b6b3c675a1895002bda9c771b6829e2/58556/ArticleHead.webp","srcSet":"/static/3b6b3c675a1895002bda9c771b6829e2/61e93/ArticleHead.webp 200w,\n/static/3b6b3c675a1895002bda9c771b6829e2/1f5c5/ArticleHead.webp 400w,\n/static/3b6b3c675a1895002bda9c771b6829e2/58556/ArticleHead.webp 800w,\n/static/3b6b3c675a1895002bda9c771b6829e2/99238/ArticleHead.webp 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Uma Victor","github":"uma-victor1","avatar":null}}}},{"node":{"fields":{"slug":"/engineering/implementing-authentication-on-vuejs-using-jwt/"},"html":"In this tutorial, we will be covering some authentication concepts and learn about authentication and how to use JSON JWTweb tokens to authorize a Vue app. To continue in this tutorial, you should be comfortable using vue, vuex, and express.
\nIn our app, we have a login form. The user enters a username and password that is then posted to an endpoint. The flow of the app is the user opens the app, then the login page appears, the user submits the login form, which makes a post request to a login endpoint, then we check if the username and password check out, then we return a JWT and store the token in vuex and depending on the token we display a different page.
\n![\"App](\"https://paper-attachments.dropbox.com/s_E8FB3BC64D80223D4CC4AFEEE119F2426D27A7EBE018696513C17DED12022079_1622019813698_AppWorkflow.webp\")
You can start a new project using the vue cli, but you have to install the CLI first by running-
\nnpm install -g @vue/cli\n OR\nyarn global add @vue/cliafter the cli is installed, you can create a new project by running-
vue create jwt-auth-appYou will then be prompted to select some basic setup. In your setup, select Babel, Linter, Vue Router, and Vuex!. That’s all we need.
\nTo set up our server, we need to install cors, dotenv, express, and nodemon
npm install cors dotenv expressOur server.js file is simplistic in a way that we just import express, tell it what port to listen to, and return “hello world” when we hit the base URL, and then we listen on that port.
\nrequire("dotenv").config();\nconst express = require("express");\nconst cors = require("cors");\nconst app = express();\nconst port = 3000;\napp.use(cors());\napp.use(express.json());\n\napp.get('/', (req, res) => {\n res.send('Hello World!')\n})\napp.listen(port, () => {\n console.log(`Example app listening at http://localhost:${port}`)\n})In our views folder, we add login.vue and welcome.vue files, and in the login.vue file, we build out the login form. But before that, we want to add a route to our vue router so that we can navigate to the login and welcome page.\nSo for the index.js file of our router folder, we import the login and welcome view, and we add login and welcome routes for the components to point to.
import Vue from "vue";\nimport VueRouter from "vue-router";\nimport Login from "../views/Login.vue";\nimport Welcome from "../views/Welcome.vue";\nVue.use(VueRouter);\nconst routes = [\n {\n path: "/",\n name: "Welcom",\n component: Welcome,\n },\n {\n path: "/login",\n name: "Login",\n component: Login,\n },\n];\nconst router = new VueRouter({\n mode: "history",\n base: process.env.BASE_URL,\n routes,\n});\nexport default router;We can now navigate to both pages. On our welcome page, we want to check if the user is not logged in, then present the link they can click to navigate to the login page. We use a router link to achieve this.
\n<template>\n <div>\n <h1>Welcome</h1>\n <router-link to="/login"><button>Login</button></router-link> \n </div>\n</template>In our login view, we scaffold our form. In the form, we are going to have two input boxes, one is the username input, and the other is a password. We then add a button with the type submit to submit the form. When we submit, we perform a login function in our script then set preventDefault on our form to stop the page from refreshing each time we click the login button.\nIn the script of our application, we model our input data by doing a two-way binding to the data state.
<template>\n <div>\n <h1>LOGIN</h1>\n <form @submit.prevent="login">\n <input v-model="username" placeholder="username" />\n <br />\n <br />\n <input v-model="password" placeholder="password" type="password" />\n <br />\n <br />\n <button type="submit">Login</button>\n </form>\n </div>\n</template>\n<script>\nexport default {\n data: () => {\n return {\n username: "",\n password: "",\n };\n },\n};\n</script>![\"login](\"https://paper-attachments.dropbox.com/s_E8FB3BC64D80223D4CC4AFEEE119F2426D27A7EBE018696513C17DED12022079_1622020162212_loginForm.webp\")
For the login method that runs when you click the button, we would like to perform an HTTP request to our express backend. We want to make a post request to our /login route we will create in our server.\nIn the fetch method, the first parameter is the URL you are sending a request to. Then the second is the object you are posting containing the headers, which contain information about the request, and the body containing the form data.
<script>\nexport default {\n data: () => {\n return {\n username: "",\n password: "",\n };\n },\n methods: {\n login() {\n fetch("http://localhost:3000/login", {\n method: "POST",\n headers: {\n "Content-Type": "application/json",\n },\n body: JSON.stringify({\n username: this.username,\n password: this.password,\n }),\n });\n },\n },\n};\n</script>In our server.js, we create a post request to the /login route and send back some json to test it out. Now, if we click login now, we get back a 200 ok message.
Note: Make sure you set up *cors* so that you don't encounter an error message when hitting the */login* route
app.post("/login?", (req, res) => {\n res.json({\n message: "hello ma guy"\n })\n})The next step is to check if the username or password exists in a database or somewhere else. To not waste time dealing with a database, we can use a hardcoded username and password. In the post route, if somebody tries to log in with the exact login information we just hardcoded, we want to give the person a green light and log the person into the application; otherwise, we throw an error.
\nUsing the login payload we got from submitting the form, we can now check if the username and password are the same; else, we throw an error and respond with a status of 403 and a wrong login information message.
\napp.post("/login", (req, res) => {\n const USERNAME = "uma victor";\n const PASSWORD = "8888";\n const { username, password } = req.body;\n if (username === USERNAME && password === PASSWORD) {\n const user = {\n id: 1,\n name: "uma victor",\n username: "uma victor",\n };\n } else {\n res.status(403);\n res.json({\n message: "wrong login information",\n });\n }\n});This is the interesting part of the tutorial. Now, if you provide the correct login information and it checks out, the next step is to sign a JWT web token. Let’s first install the JWT plugin.
\nnpm install jsonwebtokenalso, make sure to import it at the top of your server.js file
const jwt = require("jsonwebtoken");Then when the user login is successful, we want to send a JWT that is signed. So we import the JWTpackage. Then you sign in with a unique password. In a real application, we will want to have a .env file where we store the secret key. Then use process.env to grab and use it when signing our user model. Imagine we have a user object which we got back from our database with a unique ID, name, and username.
app.post("/login", (req, res) => {\n const USERNAME = "uma victor";\n const PASSWORD = "8888";\n const { username, password } = req.body;\n if (username === USERNAME && password === PASSWORD) {\n const user = {\n id: 1,\n name: "uma victor",\n username: "uma victor",\n };\n const token = jwt.sign(user, process.env.JWT_KEY);\n res.json({\n token,\n user,\n });\n } else {\n res.status(403);\n res.json({\n message: "wrong login information",\n });\n }It is the user object we want to sign, so when you send it to the client. We can uniquely identify them. The unique ID is also very important because when a server gets a request with a token, we want to know what uniquely identifies the request.\nNow when we enter the username and password in our form, we can see in the console that our JWT token is generated but is not encrypted.
\nYou can visit jwt.io and paste in the token that was generated, and your token will be decoded and return information about your payload
\nNote: The token is not encrypted, and anyone who gets access to the token can hit your server with it. Tokens normally have an expiry period of between 30 - 60 minutes
\nIn our fetch method in the login view, we want to get back the token and the user and store it somewhere. Now we make our login method async, then we set our response to equal to the fetch method that returns the user and token, and we get back the user and token from the response.
<script>\nexport default {\n data: () => {\n return {\n username: "",\n password: "",\n };\n },\n methods: {\nasync login(e) {\n e.preventDefault();\n const response = await fetch("http://localhost:3000/login", {\n method: "POST",\n headers: {\n "Content-Type": "application/json",\n },\n body: JSON.stringify({\n username: this.username,\n password: this.password,\n }),\n });\n },\n },\n};\n</script>In our store, we add the user and token data in our state and set them to null initially. You can use the token to see if the user is logged in or not. If the token is null, then we are not logged in, but if it’s set to something, then we are probably logged in.\nWe create a setUser mutation in our mutation object that sets the state to the user object. We also create a setToken mutation to assign our token.
import Vue from "vue";\nimport Vuex from "vuex";\nVue.use(Vuex);\nexport default new Vuex.Store({\n state: {\n user: null,\n token: null,\n },\n mutations: {\n setUser(state, user) {\n state.user = user;\n },\n setToken(state, token) {\n state.token = token;\n },\n },\n actions: {},\n getters: {},\n});Note: It is best practice to always call mutations from our actions, but since our mutations can easily be traced, we are calling the mutations directly
\nIn the login view, we can import mapMutations from vuex and map the setUser and setToken mutation. We can now call the mutations from the login method.
<script>\nimport { mapMutations } from "vuex";\nexport default {\n data: () => {\n return {\n username: "",\n password: "",\n };\n },\n methods: {\n ...mapMutations(["setUser", "setToken"]),\n async login(e) {\n e.preventDefault();\n const response = await fetch("http://localhost:3000/login", {\n method: "POST",\n headers: {\n "Content-Type": "application/json",\n },\n body: JSON.stringify({\n username: this.username,\n password: this.password,\n }),\n });\n const { user, token } = await response.json();\n this.setUser(user);\n this.setToken(token);\n },\n },\n};\n</script>Now that we're logged in, our state has been mutated and updated with the information from our form. But after we login, we want to redirect to our welcome page using the $router.push(\"/\") method to redirect to the home page, which is also our welcome page.
this.$router.push("/");// image of the welcome page here\nSince you are logged in, you don’t want the login button showing anymore on the welcome page. You can use a getter from our store to do this. We check if the token is null or not and return true or false.
getters: {\n isLoggedIn(state) {\n return !!state.token;\n },\n},then in our welcome component template, we can use now map to our Getter and use the v-if directive to display the login button if isLoggedIn is true or false
<template>\n <div>\n Welcome\n <router-link v-if="!isLoggedIn" to="/login"><button>Login</button></router-link>\n </div>\n</template>\n<script>\nimport { mapGetters } from "vuex";\nexport default {\n computed: {\n ...mapGetters(["isLoggedIn"])\n }\n};\n</script>In this tutorial, we looked at how to authenticate a person using the JSON web token. We created a login form and used an express server for the login route in the application using Vue.js as a frontend framework.
\nAs we all know, JSON Web Tokens are a way of sending information between parties in a way where the sender's authenticity can be verified. It is essentially a JSON object with a signature. Using this signature, services that issue these tokens can verify that they are the ones who issued this token and thus can trust the claims which are contained within.
\nThe trustworthiness of these tokens make them popular for use in authorization and authentication scenarios:
\nFor this post, we'll be focusing on the former use case. So having a token with trustworthy claims is great; we can take the token at its word, and trust all of the information that it has contained within as gospel. Our server is unburdened from having to potentially make database calls to verify the user's role, their permissions, their existence, or even if they're logged in. Once the server has generated the token, as far as it is concerned, no state has to be maintained regarding the validity of the token. It will expire once its expiration time included in its claim has passed.
\nBut before we go ahead and use this for all of our authorization needs, we have to remember that while JSON Web Tokens themselves are stateless, to have a robust, feasible, and controllable authorization workflow, we'll have to maintain some state one way or another.
\nYou can think of an authorization token as an elementary school hall pass. The teacher (resource server) knows that it is a legitimate hall pass because it is green, 6 cm x 12 cm and has a signature from another member of the faculty. Now imagine that you've issued a hall pass, but now you need to take it back (you've changed your mind, or the kid did something bad). Your options are:
\nOther than the 3rd option which may or may not be feasible depending on your use case (most likely not), we can see that it is not possible to reliably remove or revoke a token without maintaining state. The solutions that I've looked upon Stack Overflow for invalidating these tokens boil down to relying on some form of state, one way or another. Don't get me wrong however, this is not a bad thing in my opinion. Using JSON Web Tokens can and do allow us to minimize the state that we do have to maintain, with minimal added complexity.
\nSo let's look at some ways that we can couple state and JSON Web Tokens that allow us to invalidate these tokens effectively.
\nWe can maintain a database table containing all of the tokens issued by our server that we would like to accept as valid. This would be a 1:1 session store, with every transaction occurring requiring this table to be checked to prevent an invalidated token from being accepted. While we would not be able to reduce the amount of state being maintained on our server, JSON Web Tokens still provide us with the utility of its trusted claims (and the performance benefits of not needing to check those).
\nWe can maintain a database table containing all of the tokens issued by our server that we do NOT want to accept as valid. Every transaction that occurs will require this table to be checked, to prevent an invalidated token from being accepted. Each record would only have to be maintained until the token itself expires. I can't think of any use case where a table of invalidated tokens would regularly be larger than a table of active tokens, so I'd imagine that the table maintained would almost always be smaller than maintaining a table of active tokens.
\nThis solution still needs a database lookup, but interestingly requires no state. For this, we can use the hash of a piece of data to sign the token itself. For example, by using the hash of a user's password, when the user changes their password, subsequent transactions involving an old token will fail, as the signature will fail to be verified. The effectiveness of this, however, would depend on your requirements, as this would be limited to invalidating tokens based on changing data (such as changing roles, passwords, etc.). It would not allow you to invalidate a token whenever you want.
\nI think that JSON Web Tokens coupled with a token blacklist is a fantastic way to manage authorization in web applications. This allows you to leverage the benefits of these tokens in reducing the network calls needed to secure your application, reduce the amount of data you need to store to manage sessions, and do so in a reliable way without introducing too much complexity.
\n","frontmatter":{"date":"January 18, 2021","updated_date":null,"title":"Invalidating JSON Web Tokens","tags":["JSON Web Tokens","JWT"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/0c11b157497c5b54f5a0149f01ce15ac/58556/unsplash.webp","srcSet":"/static/0c11b157497c5b54f5a0149f01ce15ac/61e93/unsplash.webp 200w,\n/static/0c11b157497c5b54f5a0149f01ce15ac/1f5c5/unsplash.webp 400w,\n/static/0c11b157497c5b54f5a0149f01ce15ac/58556/unsplash.webp 800w,\n/static/0c11b157497c5b54f5a0149f01ce15ac/99238/unsplash.webp 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Nick Chim","github":"nickc95","avatar":null}}}},{"node":{"fields":{"slug":"/engineering/jwt-signing-algorithms/"},"html":"When JSON Web Tokens are created, they are typically signed by its issuer. This allows the recipient of the token to validate that the token received contains all of the information encoded by the issuer unmodified and as intended.
\nA signature is not to be mistaken for encryption! The fact that a JSON token is signed does not mean that the data enclosed is unreadable by third parties. All a signature does is ensure that the message is authentic, which it achieves by allowing the recipient to compare the data they’ve received with a trusted claim included in the data (the signature).
\nJWTs are most commonly signed using one of two algorithms: HS256 (HMAC using SHA256), and RS256 (RSA using SHA256).
\nA signature can only be created by someone possessing a secret key, and the original payload. Signatures are generally formed by combining the data to be signed with a secret key, either by appending them together and hashing them (HS256), or by encrypting a representation of that data (a hash) using the secret key (RS256).
\nIn both signing algorithms, the data is formatted into an immutable representation in a way that a recipient can check that the creator of the signature was in possession of that particular secret key.
\nHS256 is a symmetric signing method. This means that the same secret key is used to both create and verify the signature.
\nThe issuer appends the JWT header and payload with the secret key, and hashes the result using SHA256, creating a signature. The recipient uses their copies of the secret key, JWT header and payload in the same way to reproduce the signature, checking to see if they match.
\nAside from some incredibly unlikely scenarios, the only way for these signatures to be consistent is if the JWT header, payload and secret shared between the two parties are identical.
\nRS256 is an asymmetric encryption method. This differs from a symmetric scheme in that rather than using a single secret key, a pair of seperate keys are used to encrypt and decrypt the data.
\nThe issuer generates a hash of the JWT header and payload using SHA256, and encrypts it using the RSA encryption algorithm, and their private key. The recipient uses their public key to decrypt the signature ciphertext, and then compares it to a hash they’ve reproduced using their copy of the JWT header and payload, checking for consistency.
\nThe only way that these resulting hashes are consistent is if the JWT header and payload shared between the two parties are identical, and the public key corresponds to the private key used to encrypt the hash.
\nBoth signing schemes are effectively secure, with HS256 being a little faster. However, given this use case, the difference in speed is not particularly relevant.
\nThe main consideration on which to use, is in my opinion the symmetric vs asymmetric property of each:
\nHaving an unsecured publicly available key is useful in many cases. For example, it can be published openly on the internet as part of a metadata endpoint, allowing JWT configurators to automatically retrieve the key, making for a straightforward and automatic JWT setup. As such, RS256 may be more suitable for situations where data is exchanged between two independent parties.
\nHaving a shared secret key can however also be useful in some cases. For example, if the issuer and recipient were both managed by a single party, the two applications would be able to share configurations without having to manage two separate keys. As such, HS256 may be more suitable for situations where data is exchanged within a single party
\n","frontmatter":{"date":"September 24, 2020","updated_date":null,"title":"JWT Signing Algorithms","tags":["JWT","JSON Web Tokens"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/2fd4c7f86c996d936d9b217235d6257d/58556/unsplash.webp","srcSet":"/static/2fd4c7f86c996d936d9b217235d6257d/61e93/unsplash.webp 200w,\n/static/2fd4c7f86c996d936d9b217235d6257d/1f5c5/unsplash.webp 400w,\n/static/2fd4c7f86c996d936d9b217235d6257d/58556/unsplash.webp 800w,\n/static/2fd4c7f86c996d936d9b217235d6257d/99238/unsplash.webp 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Nick Chim","github":"nickc95","avatar":null}}}},{"node":{"fields":{"slug":"/engineering/jwt-authentication-with-deno/"},"html":"In this blog, we’ll see how to create and validate a JWT(JSON Web Token) in Deno. For this, we’ll be using djwt, the absolute minimum library to make JSON Web Tokens in deno and Oak framework
\nThis tutorial assumes you have:
\nJSON Web Token is an internet standard used to create tokens for an application. These tokens hold JSON data and are cryptographically signed.
\nHere is how a sample Json Web Token looks like
\neyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6Im9sYXR1bmRlZ2FydWJhQGdtYWlsLmNvbSIsImJWT is a good way of securely sending information between parties. Because JWTs can be signed—for, you can be sure the senders are who they say they are. And, as the signature is generated using the header and the payload, you can also verify that the content hasn't been tampered with.
\nJWT can contain user information in the payload and also can be used in the session to authenticate the user.
\nIf you want to know more about JSON Web Token, We have a very good article about it.
\nFirst, let's set up a Deno server to accept requests, for it, we are using Oak framework, it is quite simple and few lines of codes as you can see below.
\n// index.ts\nimport { Application, Router } from "https://deno.land/x/oak/mod.ts";\n\nconst router = new Router();\nrouter\n .get("/", (context) => {\n context.response.body = "JWT Example!";\n })\n\nconst app = new Application();\napp.use(router.routes());\napp.use(router.allowedMethods());\n\nawait app.listen({ port: 8000 });Once our program is ready for accepting request Let's import djwt functions to generate JWT token, In below code we can use a secret key, expiry time for JWT token in 1 hour from the time program will run and we are using HS256 algorithm.
\nAdd the below code in index.ts and update the router as shown below, you can now get a brand new token on http://localhost:8000/generate
// index.ts\n...\n\nimport { makeJwt, setExpiration, Jose, Payload } from "https://deno.land/x/djwt/create.ts";\n\nconst key = "secret-key";\nconst payload: Payload = {\n iss: "Jon Doe",\n exp: setExpiration(new Date().getTime() + 60000),\n};\nconst header: Jose = {\n alg: "HS256",\n typ: "JWT",\n};\n\n\nconst router = new Router();\nrouter\n .get("/", (context) => {\n context.response.body = "JWT Example!";\n })\n .get("/generate", (context) => {\n context.response.body = makeJwt({ header, payload, key }) + "\\n";\n })\n\n...Once you get a JWT token you can validate the token by validateJwt function in djwt, let us import the validateJwt and add one more route /validate/:token
Now you can verify any token by passing it to a route like - http://localhost:8000/validate/jwt_token (jwt_token is a placeholder, please replace it with a real JWT token)
// index.ts\n...\n\nimport { validateJwt } from "https://deno.land/x/djwt/validate.ts";\n\n...\n\nrouter\n .get("/", (context) => {\n context.response.body = "JWT Example!";\n })\n .get("/generate", (context) => {\n context.response.body = makeJwt({ header, payload, key }) + "\\n";\n })\n .get("/validate/:token", async (context) => {\n if ( context.params && context.params.token && (await validateJwt(context.params.token, key)).isValid) {\n context.response.body = "Valid JWT\\n";\n } else {\n context.response.body = "Invalid JWT\\n";\n }\n });\n\n...Now you know how to generate and verify a JWT token in Deno, you can easily use it in your application, The complete source code used in this blog can be found in this Github Repo
\n","frontmatter":{"date":"July 10, 2020","updated_date":null,"title":"How to create and validate JSON Web Tokens in Deno","tags":["Deno","JWT","JSON Web Token"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.492537313432836,"src":"/static/2ca148ad6e08643634262607131d918e/58556/deno_jwt.webp","srcSet":"/static/2ca148ad6e08643634262607131d918e/61e93/deno_jwt.webp 200w,\n/static/2ca148ad6e08643634262607131d918e/1f5c5/deno_jwt.webp 400w,\n/static/2ca148ad6e08643634262607131d918e/58556/deno_jwt.webp 800w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Puneet Singh","github":"puneetsingh24","avatar":null}}}},{"node":{"fields":{"slug":"/engineering/nodejs-and-mongodb-application-authentication-by-jwt/"},"html":"In this blog, we’ll be implementing authentication with JWT in a NodeJS web application. For this, we’ll be using jsonwebtoken package
\nJWT(JSON Web Token) is a token format. It is digitally-signed, self-contained, and compact. It provides a convenient mechanism for transferring data. JWT is not inherently secure, but the use of JWT can ensure the authenticity of the message so long as the signature is verified and the integrity of the payload can be guaranteed. JWT is often used for stateless authentication in simple use cases involving non-complex systems.
\nHere's an example of JWT:
\neyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6Im9sYXR1bmRlZ2FydWJhQGdtYWlsLmNvbSIsImNow, let's authenticate/protect some routes.
\nPre-requisites:
\nyou can install all required packages by using following command:
\nnpm install express mongoose bcrypt --saveStep 1. First, create a directory structure as below :
\nJWTApp
-api\n--models\n----userModel.js\n--controllers\n----userController.js\n--route\n----userRoute.js\n--server.js npm install jsonwebtoken -- saveIn the api/models folder, create a file called user userModel.js by running touch api/models/userModel.js.
\nIn this file, create a mongoose schema with the following properties:
\nAdd the following code
\n'use strict';\n\nvar mongoose = require('mongoose'),\n bcrypt = require('bcrypt'),\n Schema = mongoose.Schema;\n\n/**\n * User Schema\n */\nvar UserSchema = new Schema({\n fullName: {\n type: String,\n trim: true,\n required: true\n },\n email: {\n type: String,\n unique: true,\n lowercase: true,\n trim: true,\n required: true\n },\n hash_password: {\n type: String\n },\n created: {\n type: Date,\n default: Date.now\n }\n});\n\nUserSchema.methods.comparePassword = function(password) {\n return bcrypt.compareSync(password, this.hash_password);\n};\n\nmongoose.model('User', UserSchema);In the api/controllers folder, create a file called user userController.js by running touch api/controllers/userController.js
\nIn the userController file, create three different handlers to handle by using the following code
\n'use strict';\n\nvar mongoose = require('mongoose'),\n jwt = require('jsonwebtoken'),\n bcrypt = require('bcrypt'),\n User = mongoose.model('User');\n\nexports.register = function(req, res) {\n var newUser = new User(req.body);\n newUser.hash_password = bcrypt.hashSync(req.body.password, 10);\n newUser.save(function(err, user) {\n if (err) {\n return res.status(400).send({\n message: err\n });\n } else {\n user.hash_password = undefined;\n return res.json(user);\n }\n });\n};\n\nexports.sign_in = function(req, res) {\n User.findOne({\n email: req.body.email\n }, function(err, user) {\n if (err) throw err;\n if (!user || !user.comparePassword(req.body.password)) {\n return res.status(401).json({ message: 'Authentication failed. Invalid user or password.' });\n }\n return res.json({ token: jwt.sign({ email: user.email, fullName: user.fullName, _id: user._id }, 'RESTFULAPIs') });\n });\n};\n\nexports.loginRequired = function(req, res, next) {\n if (req.user) {\n next();\n } else {\n\n return res.status(401).json({ message: 'Unauthorized user!!' });\n }\n};\nexports.profile = function(req, res, next) {\n if (req.user) {\n res.send(req.user);\n next();\n } \n else {\n return res.status(401).json({ message: 'Invalid token' });\n }\n};Note: A hash password was saved in the database using bcrypt.
\nStep 6. In the api/route folder, create a file called user userRoute.js and add the following code:
\n'use strict';\nmodule.exports = function(app) {\n var userHandlers = require('../controllers/userController.js');\n // todoList Routes\n app.route('/tasks')\n .post(userHandlers.loginRequired, userHandlers.profile);\n app.route('/auth/register')\n .post(userHandlers.register);\n app.route('/auth/sign_in')\n .post(userHandlers.sign_in);\n};'use strict';\n\nvar express = require('express'),\n app = express(),\n port = process.env.PORT || 3000,\n\n\n User = require('./api/models/userModel'),\n bodyParser = require('body-parser'),\n jsonwebtoken = require("jsonwebtoken");\n\nconst mongoose = require('mongoose');\nconst option = {\n socketTimeoutMS: 30000,\n keepAlive: true,\n reconnectTries: 30000\n};\n\nconst mongoURI = process.env.MONGODB_URI;\nmongoose.connect('mongodb://127.0.0.1:27017/?compressors=disabled&gssapiServiceName=mongodb', option).then(function(){\n //connected successfully\n}, function(err) {\n //err handle\n});\n\napp.use(bodyParser.urlencoded({ extended: true }));\napp.use(bodyParser.json());\n\napp.use(function(req, res, next) {\n if (req.headers && req.headers.authorization && req.headers.authorization.split(' ')[0] === 'JWT') {\n jsonwebtoken.verify(req.headers.authorization.split(' ')[1], 'RESTFULAPIs', function(err, decode) {\n if (err) req.user = undefined;\n req.user = decode;\n next();\n });\n } else {\n req.user = undefined;\n next();\n }\n});\nvar routes = require('./api/routes/userRoutes');\nroutes(app);\n\napp.use(function(req, res) {\n res.status(404).send({ url: req.originalUrl + ' not found' })\n});\n\napp.listen(port);\n\nconsole.log(' RESTful API server started on: ' + port);\n\nmodule.exports = app;Step 9. Now you just need to run the project by using the following command and try logging by using the JWT.
\nnpm startStep 10. Open Postman and create a post request to localhost:3000/auth/register as below:
\n![\"Postman](\"/a6eec58240d18cb17146ca11b5d49dcd/register.webp\")
Step 11. After this, let’s sign with this URL localhost:3000/auth/sign_in . Enter the keys and values for email and password
\n![\"Postman](\"/5cb1b965f14b8f3b4d254d7d310c789d/signIn.webp\")
Under the value, add JWT and the token with a space between, like so:
\nJWT eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6Im9sYXR1bmRlZ2FydWJhQGdtYWlsLmNvbSIsImZ1bGxOYW1lIjoiT2xhdHVuZGUgR2FydWJhIiwiX2lkIjoiNThmMjYzNDdiMTY1YzUxODM1NDMxYTNkIiwiaWF0IjoxNDkyMjgwMTk4fQ.VcMpybz08cB5PsrMSr25En4_EwCGWZVFgciO4M-3ENEStep 11. Then, enter the parameters for the key and value for fetching the profile. You want to create as shown below and send:
\n![\"Postman](\"/42b50f8f60ca459023e492ce1b802845/profile.webp\")
As we have seen it is fairly easy to build a JWT authentication system with NodeJS, You can found the complete code used in this tutorial here.
\n","frontmatter":{"date":"March 20, 2020","updated_date":null,"title":"NodeJS and MongoDB application authentication by JWT","tags":["NodeJs","JWT","MongoDB","Authentication","JSON Web Token"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.6666666666666667,"src":"/static/2b39d6f99b1ca5d4bc89d3bfccb6e29d/e9589/jwt.webp","srcSet":"/static/2b39d6f99b1ca5d4bc89d3bfccb6e29d/61e93/jwt.webp 200w,\n/static/2b39d6f99b1ca5d4bc89d3bfccb6e29d/1f5c5/jwt.webp 400w,\n/static/2b39d6f99b1ca5d4bc89d3bfccb6e29d/e9589/jwt.webp 500w","sizes":"(max-width: 500px) 100vw, 500px"}}},"author":{"id":"Ashish Sharma","github":"ashish8947","avatar":null}}}},{"node":{"fields":{"slug":"/engineering/using-jwt-with-oauth2-when-and-why/"},"html":"JWT(Json Web Token) is a token format. It is digitally-signed, self-contained, and compact. It provides a convenient mechanism for transferring data. JWT is not inherently secure, but the use of JWT can ensure the authenticity of the message so long as the signature is verified and the integrity of the payload can be guaranteed. JWT is often used for stateless authentication in simple use cases involving non-complex systems.
\nOAuth2 is an authorization protocol that builds upon the original OAuth protocol created in 2006, arising out of a need for authorization flows serving different kinds of applications from web and mobile apps to IoT. OAuth2 specifies the flows and standards under which authorization token exchanges should occur. OAuth2 does not encompass authentication, only authorization. For more information on OAuth2, please see IETF
\nJWT and OAuth2 are entirely different and serve different purposes, but they are compatible and can be used together. The OAuth2 protocol does not specify the format of the tokens, therefore JWTs can be incorporated into the usage of OAuth2.
\nFor example, the access_token returned from the OAuth2 Authorization Server could be a JWT carrying additional information in the payload. This could potentially increase performance by reducing round trips for the required information between the Resource Server and the Authorization Server. This is a good use case for incorporating JWT into OAuth2 implementations when transparent tokens are acceptable - there are scenarios requiring token opacity where this is not optimal.
\nAnother common way to use JWT in conjunction with OAuth2 is to issue two tokens: a reference token as access_token, and a JWT containing identity information in addition to that access token. In use cases where this implementation seems necessary, it is probably worth looking into OpenID Connect - an extension built upon OAuth2 and provides additional standardizations, including having an access_token and an id_token.
\nA common misconception is that using JWT with OAuth2 increases the security of an application, this is not true. As mentioned earlier, JWT is not an inherently secure mechanism, and the security of OAuth2 is upheld through the definitions of the actors involved in the authorization process and the specific steps to be taken for this process in different use cases. Security concerns regarding OAuth2 are best addressed by choosing the appropriate OAuth2 grant flow for the application based on use case, not the token format.
\nThe advantages of using JWT in addition to OAuth2 is in increased performance and decreased process complexity when it comes to certain flows; however, this may increase development complexity. When deciding whether to use JWT on top of OAuth2, it is best to begin by considering whether the performance gain is meaningful to your application, and whether that is worth the additional work required for development.
\n","frontmatter":{"date":"March 11, 2019","updated_date":null,"title":"How to Use JWT with OAuth","tags":["JWT","Oauth","JSON Web Token"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/6bb161407bb0fc97a9525faaae5de564/58556/photo-1454165804606-c3d57bc86b40.webp","srcSet":"/static/6bb161407bb0fc97a9525faaae5de564/61e93/photo-1454165804606-c3d57bc86b40.webp 200w,\n/static/6bb161407bb0fc97a9525faaae5de564/1f5c5/photo-1454165804606-c3d57bc86b40.webp 400w,\n/static/6bb161407bb0fc97a9525faaae5de564/58556/photo-1454165804606-c3d57bc86b40.webp 800w,\n/static/6bb161407bb0fc97a9525faaae5de564/99238/photo-1454165804606-c3d57bc86b40.webp 1200w,\n/static/6bb161407bb0fc97a9525faaae5de564/5616c/photo-1454165804606-c3d57bc86b40.webp 1350w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Ti Zhang","github":null,"avatar":null}}}},{"node":{"fields":{"slug":"/engineering/jwt/"},"html":"A JSON Web Token (JWT) is a JSON object that is defined in RFC 7519 as a safe way of transmitting information between two parties. Information in the JWT is digitally-signed, so that it can be verified and trusted.
\nJWT Properties
\nJWT Use Cases
\nJWT contains three parts: Header, Payload, and Signature which are separated by a dot.
\nHeader.Payload.Signature
Header
\nThe JWT Header consists of 2 parts:
\n{ \n "typ" : "JWT", \n "alg" : "HS256" \n}Header Algorithm Types:
\nalg Value
\nDigital Signature or MAC Algorithm
\n| Algo | \nDescription | \n
|---|---|
| HS256 | \nHMAC using SHA-256 hash algorithm | \n
| HS384 | \nHMAC using SHA-384 hash algorithm | \n
| HS512 | \nHMAC using SHA-512 hash algorithm | \n
| RS256 | \nRSASSA using SHA-256 hash algorithm | \n
| RS384 | \nRSASSA using SHA-384 hash algorithm | \n
| RS512 | \nRSASSA using SHA-512 hash algorithm | \n
| ES256 | \nECDSA using P-256 curve and SHA-256 hash algorithm | \n
| ES384 | \nECDSA using P-384 curve and SHA-384 hash algorithm | \n
| ES512 | \nECDSA using P-521 curve and SHA-512 hash algorithm | \n
The Base64Url-encoded Header, which is first part of our JWT, looks like the following:
\neyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Payload
\nThe Payload, also known as the JWT claim, contains all of the information we want to transmit.
\nDifferent types of claims can be used to build the Payload:
\n| Code | \nName | \nDescription | \n
|---|---|---|
| iss | \nissuer | \nIdentifies the principal that issued the JWT. | \n
| sub | \nsubject | \nIdentifies the principal that is the subject of the JWT. | \n
| aud | \naudience | \nIdentifies the recipients that the JWT is intended for. | \n
| exp | \nExpiration time | \nIdentifies the expiration time on or after which the JWT MUST NOT be accepted for processing. | \n
| nbf | \nNot before | \nIdentifies the time before which the JWT MUST NOT be accepted for processing. | \n
| iat | \nIssue at | \nIdentifies the time at which the JWT was issued. | \n
| jti | \nJWT id | \nUnique identifier for the JWT, can be used to prevent the JWT from being replayed. | \n
Example Payload:
\n{ \n "sub": "1234567890", \n "name": "Frank Emic", \n "jti": "4b5fcea6-2a5e-4a9d-97f2-3d8631ea2c5a", \n "iat": 1521191902, \n "exp": 1521195630 \n}This example contains a combination of registered and public claims. “sub”,”jti”,”iat”, and “exp” are registered claims and “name” is a public claim.
\nThe Base64Url-encoded Payload, which is the second part of our JWT, looks like the following:
\neyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkZyYW5rIEVtaWMiL \nCJqdGkiOiI0YjVmY2VhNi0yYTVlLTRhOWQtOTdmMi0zZDg2MzFlYTJjNWEiLCJpYXQiOjE1MjExOTE5MDIsImV4cCI6MTUyMTE5NTYzMH0Signature
\nThe final part of our JWT is the Signature. To create the Signature, we need 3 components:
\nvar encodedString = base64UrlEncode(header) + \".\" + base64UrlEncode(payload);
\nHMACSHA256(encodedString, 'secret');
The secret is the Signature held by the server in order to verify tokens and sign new ones.
\nThe above Base64Url-encoded Header and Payload are combined with a dot, and then digitally-signed using the secret. This generates the Signature as the third part of the our JWT:
\nwGDoDSxfKj3Ns379NVxocwM9TOiwxhxWl
\nPutting It All Together
\neyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkZyYW5rIEVtaWMiL \nCJqdGkiOiI0YjVmY2VhNi0yYTVlLTRhOWQtOTdmMi0zZDg2MzFlYTJjNWEiLCJpYXQiOjE1MjExOTE5MDIsImV4cCI6MTUyMTE5NTYzMH0.wGDoDSxfKj3Ns379NVxocwM9TOiwxhxWlThis is our final JWT, containing the Header, Payload, and Signature joined together with dots. It can be passed as a URL parameter, a POST parameter, or in the HTTP header to authenticate or exchange information.
\nNote: JWT does not hide information; it just encodes information using the digitally-signed signature and verifies that the information has not been altered over the network. So, do not add any sensitive information in the JWT claim.
\nConclusion
\nJWT comprises three encoded parts: Header, Payload, and Signature. It can be passed as a URL or POST parameter, or in an HTTP header. Due to JWT's lightweight, self-containing, and versatile strucutre, it remains a popular tool for information exchange and authentication.
\n","frontmatter":{"date":"July 11, 2018","updated_date":null,"title":"What is JSON Web Token","tags":["JWT","JSON Web Token"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.7699115044247788,"src":"/static/fca016963236696b6d07a52d211c1354/58556/jwt.webp","srcSet":"/static/fca016963236696b6d07a52d211c1354/61e93/jwt.webp 200w,\n/static/fca016963236696b6d07a52d211c1354/1f5c5/jwt.webp 400w,\n/static/fca016963236696b6d07a52d211c1354/58556/jwt.webp 800w,\n/static/fca016963236696b6d07a52d211c1354/99238/jwt.webp 1200w,\n/static/fca016963236696b6d07a52d211c1354/135cd/jwt.webp 1280w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Mayank Agarwal","github":"mayankagrwal","avatar":null}}}},{"node":{"fields":{"slug":"/engineering/alternate-authentication-asp/"},"html":"Introduction
\nAuthentication and authorization both are most important things for any system and application. This blog starts with authentication and authorization concepts and after that explains the three default important ways and three custom authentication ways for doing authentication and authorization i.e. windows, forms ,passport, multipass, JWT and SAML authentication. Plus, in this blog I will explain some fundamental concepts about the different authentication system.
\nAuthentication and Authorization
\nAuthentication is the process for checking the identity of a user based on the user’s credentials. Generally, user’s credentials are in the form of user ID and password, and we check their credentials from database or equivalent alternative, if it exists then user is a valid candidate for next process - authorization.
\nAuthorization also known as “Permission Control” will come after authentication. Authorization is the process of deciding what kind of resource a user can access based on their identity and checking whether the authenticated user has sufficient rights to access the requested resources. Typically a resource can be an ASP.NET web page, media files (MP4, GIF, JPEG etc), compressed file (ZIP, RAR) etc.
\nASP.NET default authentication Providers
\n1. Form Authentication
\nNormally, form authentication is based on cookies, the authentication and permission settings are stored in cookies. However, we can also use form authentication without cookies, and in cookie-less form authentication we can use query string for passing user details. Remember, the key concept is always ONLY allow the user with correct credential also enough permission to view certain resources, so we need to capture their information and compare with what we have stored in the database. And no matter what kind of form authentication we use, after we receive the data on server end, we will compare them with the data stored in any storage method/provider. For example, we can store username and password in the web.config file, a JSON file, or a database table.
\nForms authentication flow:
\n2. Passport Authentication
\nPassport authentication is a centralized authentication service provided by Microsoft. The .NET Passport single sign-in service. When we use passport authentication then user authentication in your application is managed by Microsoft's passport service. Passport authentication uses encrypted cookies to manage the authentication.
\nHow Password authentication works Users do not need to retype their sign-in name and password when moving from site to site. Those .NET Passport–enabled sites will issue a set of encrypted cookies in the .NET Passport central servers' domain to facilitate silent and seamless sign-in across sites. In some cases, sites owners will first redirect their end-users to .NET Passport sign-in and to authenticate upon first viewing of their site. If the users are logged in already, they'll get authenticated by ASP.NET, and if they are not logged in they will get redirected to passport servers (i.e hotmail, Live etc.) to login first. If user successfully authenticates himself, it will return a token to your website.
\n3. Windows Authentication
\nWe use windows authentication when we are creating a web application for a limited number of users who already have Windows account and this type of authentication is quite useful in an intranet environment. This authentication method uses local users windows account 'credentials' for to validate the user. Dot Net web application generally hosted on IIS(Internet Information Server) so the requests go directly to IIS to provide the authentication process in a Windows-based authentication model.
\nThe entire responsibility of authentication is done by IIS. It first takes the user’s credentials from the domain login. If this process fails, IIS displays an alert dialog box so the user can enter or re-enter his login information.
\nWindows authentication have some advantages and disadvantages:
\nWindows authentication Advantage
\nWindows authentication dis-Advantage
\n4. Custom authentication Provider
\nMultipass authentication is a single sign on authentication. Suppose you have multiple sites and you want to create a single account for a user on both sites then you can use Single Sign-On. Single Sign-On is authentication system it allow user to share his authentication details with your there site. This allows a seamless experience for your users without forcing them to create a separate account on your second site. A multipass is simply a hash of keys and values, provided as an AES encrypted JSON hash.
\nJWTs represent a set of claims as a JSON object that is encoded in a JWS and/or JWE structure. This JSON object is called “JWT Claims Set”. The JSON object consists of zero or more name/value pairs (or members), where the names are strings and the values are arbitrary JSON values. These members are the claims represented by the JWT.
\nYour JWTs can contain any information you want; the user's name, birthdate, email, etc. You do this with claims based authorization. You then just tell your provider to make a JWT with these claims from the claims principle.
\nSAML - Security Assertion Markup Language SAML. SAML is developed by the Security Services Technical Committee of \"Organization for the Advancement of Structured Information Standards\" (OASIS). SAML is an XML-based framework for exchanging user authentication. The purpose of SAML is to enable Single Sign-On for web applications across various domains.
\nSAML have three components: assertions, protocol, and binding. Assertions are authentication, attribute, and authorization. Authentication assertion validates the user's identity. Attribute assertion contains specific information about the user. And authorization assertion identifies user role and permissions.
\nSAML works with multiple protocols including Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP) and also supports SOAP
\nSummary
\nDifferent authentication methods are available, and website’s owner always gets confused about which authentication method they should use, here I have explained some of the popular authentication and authorization methods, hope it made it a little bit clear for you. And I will provide some in-depth details about each type of authentication in my next blog, happy coding.
\n","frontmatter":{"date":"October 01, 2015","updated_date":null,"title":"Types of Authentication in Asp.Net","tags":["Engineering","Authentication","Asp.Net","Multipass","JWT","JSON Web Token"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1,"src":"/static/051582b8bfe0e3796cdccd575e275a97/e7487/alternate-authentication-asp-dot-net1-150x150.webp","srcSet":"/static/051582b8bfe0e3796cdccd575e275a97/e7487/alternate-authentication-asp-dot-net1-150x150.webp 150w","sizes":"(max-width: 150px) 100vw, 150px"}}},"author":{"id":"Team LoginRadius","github":"LoginRadius","avatar":null}}}}]}},"pageContext":{"tag":"JWT"}},"staticQueryHashes":["1171199041","1384082988","2100481360","23180105","528864852"]}