![\"The](\"/75cf5afcae41ee6a1ea963da104389ff/console-received-chunk-of-size-x.gif\")
There are many use cases of a system where machine-to-machine (M2M) communication is required, or you need to manage access for internal and external APIs. The example of M2M communications are:
\nIn such cases, the generic authentication methods such as email/password and social login — requiring human intervention — don’t fit well. These interactions also need a secure and easy-to-use authorization process for permission-based data access.
\nM2M Authorization fulfills both these requirements. Let’s know more about what it is and how it works.
\nM2M Authorization is the process of providing remote systems with secure access to information. Using this process, business systems can communicate autonomously and execute business functions based on predefined authorization.
\nIt is exclusively used for scenarios in which a business system authenticates and authorizes a service rather than a user.
\nLoginRadius M2M Authorization uses the Client Credentials Grant Flow (defined in OAuth 2.0 RFC 6749), in which the client passes along secure credentials to authenticate themselves and receive an authorization token.
\nSuppose an organization has a microservices environment consisting of multiple services running locally. The organization also has data storage on a different network and requires:
\nAs a standard process and security measure, services require authorization while saving and reading the data to and from the storage. The organization can use LoginRadius for autonomous authorization by creating two dedicated M2M apps with write and read permissions.
\nThe following two scenarios explain how you can use LoginRadius M2M Authentication and Authorization to share permission-based access of APIs to any internal or external systems:
\n\n\nImportant: M2M App referred to in the scenarios below must be created individually for each internal or external system you want to grant access to. Upon app creation, you receive the Client Id and Client Secret.
\n
Scenario 1: To grant desired access to your LoginRadius Management APIs.
\nTo start using the M2M Authorization for this scenario, you need to create an M2M App and define the desired scope of API(s), as explained here.
\nThe client (partner, API, service, etc.) requests the access token using the following API:
\nAPI endpoint: https://api.loginradius.com/services/oauth/token
The following is an example request:
\nPOST https://<LoginRadiusAppName>.hub.loginradius.com/service/oauth/token\nContent-Type: application/json\n{\n "audience": "`https://api.loginradius.com/identity/v2/manage",`\n "grant_type": "client_credentials",\n "client_id": "<YOUR_CLIENT_ID>",\n "client_secret": "<YOUR_CLIENT_SECRET>"\n}LoginRadius Authorization Server validates the request. Upon validation, it returns the JWT access token to the client.
\nThe following is an example response with an access token:
\n{\n "access_token": "eyJz93a...k4laUWw",\n "token_type": "Bearer",\n "expires_in": 86400,\n}\n\nJWT Token Details\n{\n "iss": "https://<LoginRadiusAppName>.hub.loginradius.com/",\n "sub": "<OAuth APPs APIKey>@client",\n "jti": "<unique Identifier>"\n "aud":"`https://api.loginradius.com/identity/v2/manage", //or https://service.example.com/api/v2`\n "cid": "<APPConfig APIKey>",\n "sid": "<LR access Token>" \n "exp": 1311281970,\n "iat": 1311281670,\n "scp": [\n "profile:read",\n "profile:create",\n ],\n "gty":"client_credentials"\n}The client can call APIs (as per the defined scope) using the JWT token. APIs will work based on permissions without the use of Client Secret.
\ncurl --request GET \\\n --url `https://api.loginradius.com/identity/v2/manage/account/{uid} \\`\n --header 'authorization: Bearer eyJhb……….jVZ2w'\n --header 'X-LoginRadius-ApiKey: {apiKey}The client (partner, API, service, etc.) requests the access token using the following API:\nAPI endpoint: https://
POST https://<LoginRadiusAppName>.hub.loginradius.com/service/oauth/token\nContent-Type: application/json\n{\n"audience": "<business API endpoint>",\n"grant_type": "client_credentials",\n"client_id": "<YOUR_CLIENT_ID>",\n"client_secret": "<YOUR_CLIENT_SECRET>"\n}\n\nNote: Where
\n<LoginRadiusAppName>is the name of your LoginRadius App.\nIn response, the client will get an access token.
Use the generated JWT token in the authorization for APIs.
\ncurl --request GET \\\n--url < API URL > \\\n--header 'authorization: Bearer eyJh………VZ2w'Overall, M2M Authorization offers secure access to improve business efficiency — and ultimately enhances user experience. In detail, the benefits include but are not limited to:
\nM2M Authorization is a secure and reliable method of autonomous interactions. It aids business systems in achieving greater efficiency and eliminates the need for human involvement. It also enables businesses to provide flexible machine-to-machine communication while enforcing granular access, authorization, and security requirements.
\n","frontmatter":{"date":"April 29, 2022","updated_date":null,"description":"How can you ensure APIs, web services, and business systems communicate and access the information securely without human intervention? The answer is machine-to-machine (M2M) authorization.","title":"M2M Authorization: Authenticate Apps, APIs, and Web Services","tags":["M2M","Authorization","Authentication"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/55b15bddf195e3eaa39cb0e655abac95/ee604/m2m-authorization-for-apis-apps-and-web-services.png","srcSet":"/static/55b15bddf195e3eaa39cb0e655abac95/69585/m2m-authorization-for-apis-apps-and-web-services.png 200w,\n/static/55b15bddf195e3eaa39cb0e655abac95/497c6/m2m-authorization-for-apis-apps-and-web-services.png 400w,\n/static/55b15bddf195e3eaa39cb0e655abac95/ee604/m2m-authorization-for-apis-apps-and-web-services.png 800w,\n/static/55b15bddf195e3eaa39cb0e655abac95/f3583/m2m-authorization-for-apis-apps-and-web-services.png 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Kundan Singh","github":null,"avatar":null}}}},{"node":{"excerpt":"When your webapp has a large amount of data to visualize, you don't want your users to wait 10 seconds before seeing something. One…","fields":{"slug":"/engineering/guest-post/http-streaming-with-nodejs-and-fetch-api/"},"html":"When your webapp has a large amount of data to visualize, you don't want your users to wait 10 seconds before seeing something.
\nOne technique that is often overlooked is HTTP streaming. It's broadly supported, works well, and doesn't require fancy libraries.
\nWe're going to go through how we can use HTTP streaming in our applications and what to consider when we do so.
\nWhen building web applications, we typically have a REST API with GET endpoints that do something like this:
\nThe API will typically wait for each step to complete before going on to the next one, and by step 4, the database result and the JSON objects are all in memory before the request is handled, and everything can be cleaned up.
\nThis works, and there is nothing wrong with it (KISS, right?) as long as your database query results are small and quickly available.
\nBut let's say you want to render a chart with 10k data points. Querying will not be as smooth anymore.\nThe simple way will work, but ideally, you don't want to accumulate all the data in memory before sending the response.
\nWith HTTP streaming, you can start rendering the chart even before your query is complete.
\nTo make it happen:
\nIn this example, we use Koa for the API, but you can use other libraries like Express or plain Node.js. Most will have support for streaming.
\nLet's create an API:
\nconst Koa = require('koa');\nconst app = new Koa();\n\napp.use(async (ctx) => {\n if (ctx.request.url === '/measurements.json') {\n ctx.response.set('content-type', 'application/json');\n // This is where the magic happens: set a stream as the response body\n ctx.body = fs.createReadStream('./measurements.json');\n }\n});\n\nhttp.createServer(app.callback()).listen(3000);This code creates an API with 1 endpoint GET /measurements that will respond with the contents of a JSON file with 10k measurements.
The file looks like this:
\n[\n { "id": "1", "timestamp": "2022-01-19T10:39:00.000Z", "value": 239.34 },\n { "id": "2", "timestamp": "2022-01-19T10:40:00.000Z", "value": 820.14 },\n { "id": "3", "timestamp": "2022-01-19T10:41:00.000Z", "value": 926.03 },\n { "id": "4", "timestamp": "2022-01-19T10:42:00.000Z", "value": 513.01 },\n // ...\n { "id": "99998", "timestamp": "2022-03-29T21:16:00.000Z", "value": 13.81 },\n { "id": "99999", "timestamp": "2022-03-29T21:17:00.000Z", "value": 465.28 },\n { "id": "100000", "timestamp": "2022-03-29T21:18:00.000Z", "value": 71.95 }\n]We're creating an HTTP/1.1 server with Node's http module. By setting ctx.body to a stream, data will be sent to the requester as soon as it is loaded using a mechanism called chunked transfer encoding.
This saves time and memory of your API because it doesn't have to accumulate the whole result in memory before sending the response.
\nIn a real application, you're probably using a database instead of a pre-created JSON file.\nIf you're using MongoDB, you can create a stream with the cursor's stream() method.
The GET /measurements endpoint we created can be consumed with any HTTP client, but you have to use the Fetch API to take advantage of streaming.
fetch() will set response.body to a ReadableStream for streaming responses.
Here's how you can read a streaming response:
\nfetch('http://localhost:3000/measurements.json')\n .then(async (response) => {\n // response.body is a ReadableStream\n const reader = response.body.getReader();\n for await (const chunk of readChunks(reader)) {\n console.log(`received chunk of size ${chunk.length}`);\n }\n });\n\n// readChunks() reads from the provided reader and yields the results into an async iterable\nfunction readChunks(reader) {\n return {\n async* [Symbol.asyncIterator]() {\n let readResult = await reader.read();\n while (!readResult.done) {\n yield readResult.value;\n readResult = await reader.read();\n }\n },\n };\n}If you run the API that we created and then run the code above in a web browser, you'll see received chunk of size x several times in the console with varying x:
To see it more clearly, open up Developer Tools (F12) and set network throttling to 3G. It will take longer for the file to download, so you can see that the chunks are being processed gradually.
\nThat's all very nice, but the chunks themselves are not very useful. You want to process the measurements that are in these chunks. Ideally, you would have an async iterable that gradually yields the JSON objects as they come in so that you can use for await to iterate over the measurements instead of the chunks.
JavaScript doesn't have a JSON parser that can deal with streams. Let's assume we have a function that can do this called parseJsonStream(readableStream). More details and a simple implementation can be found in \"Streaming Considerations\" below.
We would then be able to do this:
\nfetch('http://localhost:3000/measurements.json')\n .then(async (response) => {\n let measurementsReceived = 0;\n for await (const measurement of parseJsonStream(response.body)) {\n measurementsReceived++;\n // To prevent the console from flooding we only show 1 in every 100 measurements\n if (measurementsReceived % 100 === 0) {\n console.log(`measurement with id {${measurement.id}} at time ${measurement.timestamp} has value [${measurement.value}]`);\n }\n }\n });This is the result:
\n![\"The](\"/e2d673ca68b3af5f9fa335ce755032ed/console-measurements.gif\")
This is a very powerful mechanism. Instead of console.log() statements, imagine a line chart where the measurements gradually become visible as more data comes in.
This is an example created with Apache ECharts:
\n![\"A](\"/76f92b76f2a2c36236b5610800abb88c/chart-loading-gradually.gif\")
Before the Fetch API, it was impossible to do this because the alternative, XMLHttpRequest, will load the whole response into memory before providing it to your code.
Modern applications don't use XMLHttpRequest directly, but a lot of libraries like Axios or Angular's HttpClient rely on it to make requests.
People would rely on more advanced technologies like WebSockets to stream data.
\nYou might have heard that HTTP/2 has a more efficient mechanism for streaming, and you would be right. So let's see if we can use HTTP/2.
\nFrom the side of your webapp, the browser will automatically determine if it can communicate with the server over HTTP/2 and use it if it's available. The Fetch API will do this transparently, so you do not need to make any changes to your webapp.
\nWhat you need to do is make your API available over HTTP/2:
\nconst Koa = require('koa');\nconst app = new Koa();\n\napp.use(async (ctx) => {\n if (ctx.request.url === '/measurements.json') {\n ctx.response.set('content-type', 'application/json');\n ctx.body = fs.createReadStream('./measurements.json');\n }\n});\n\nhttp2.createSecureServer(\n {\n key: fs.readFileSync(path.resolve('path/to/localhost-key.pem')),\n cert: fs.readFileSync(path.resolve('path/to/localhost.pem')),\n },\n app.callback(),\n).listen(3000);This code is mostly the same as for HTTP/1.1 with two notable differences:
\nhttp2 module instead of http.HTTPS instead of plain HTTP because this is mandatory for HTTP/2. You can set up HTTPS and get the cert and key files using mkcert. Or, use one of the other mechanisms described in this article: Use HTTPS for Local DevelopmentThat's it!
\nIf you restart the API and check the network tab in Developer Tools, you'll see that your application will now stream over HTTP/2 (don't forget to update the URL in your webapp, start with https:// instead of http://).
In the code above, we assumed that there was a function parseJsonStream(readableStream) that would parse a ReadableStream containing JSON into an async iterable of objects.
The difficulty is that reading from a ReadableStream will give you chunks of data that don't necessarily correspond to anything meaningful. To illustrate, let's take a look at this example:
[\n { "id": "1", "timestamp": "2022-01-19T10:39:00.000Z", "value": 239.34 },\n { "id": "2", "timestamp": "2022-01-19T10:40:00.000Z", "value": 820.14 },\n { "id": "3", "timestamp": "2022-01-19T10:41:00.000Z", "value": 926.03 },\n { "id": "4", "timestamp": "2022-01-19T10:42:00.000Z", "value": 513.01 }\n]We could receive this JSON in chunks like this:
\n[\n { "id": "1", "timestamp": "2022-01-19T10:39:00.000Z", "value": 239.34 },\n { "id": "2", "tim\n\n\n\n estamp": "2022-01-19T10:40:00.000Z", "value": 820.14 },\n { "id": "3", "timestamp": "2022-01-19T10:41:00.000Z", "value": 926.03 },\n { "id": "4", "timestamp": "2022-01-19T10:42\n\n\n\n:00.000Z", "value": 513.01 }\n]You need some way to determine where one measurement object starts and ends. To simplify this, we created a JSON file where each line contains precisely one object. Parsing the stream becomes manageable when we can make this assumption.
\nHere is the implementation of parseJsonStream(readableStream)
async function *parseJsonStream(readableStream) {\n for await (const line of readLines(readableStream.getReader())) {\n const trimmedLine = line.trim().replace(/,$/, '');\n\n if (trimmedLine !== '[' && trimmedLine !== ']') {\n yield JSON.parse(trimmedLine);\n }\n }\n}\n\nasync function *readLines(reader) {\n const textDecoder = new TextDecoder();\n let partOfLine = '';\n for await (const chunk of readChunks(reader)) {\n const chunkText = textDecoder.decode(chunk);\n const chunkLines = chunkText.split('\\n');\n if (chunkLines.length === 1) {\n partOfLine += chunkLines[0];\n } else if (chunkLines.length > 1) {\n yield partOfLine + chunkLines[0];\n for (let i=1; i < chunkLines.length - 1; i++) {\n yield chunkLines[i];\n }\n partOfLine = chunkLines[chunkLines.length - 1];\n }\n }\n}\n\nfunction readChunks(reader) {\n return {\n async* [Symbol.asyncIterator]() {\n let readResult = await reader.read();\n while (!readResult.done) {\n yield readResult.value;\n readResult = await reader.read();\n }\n },\n };\n}If you have control over the API you're calling, you can use the \"1 object per line\" formatting as part of the contract, but know that it could be prone to breaking. For robust JSON support, we need a real streaming parser.
\nOther options include using a format with one object per line by default, like CSV, or a more advanced format with built-in support for streaming like Apache Arrow.
\nError handling becomes more difficult because HTTP status code 200 will be sent as soon as streaming starts. What do we do when something goes wrong in the middle of the stream?
\nWhen something goes wrong, your API should close the stream. Your webapp can then determine if the stream was complete and show a fitting message to the user if it's not. For example: when using a JSON response, as we discussed, you can check that the last line contains only \"]\".
\nYou have learned how to stream HTTP data efficiently using Node.js and HTTP without congesting or burdening the memory. You have also understood the advantages and disadvantages of HTTP streaming.
\n","frontmatter":{"date":"April 27, 2022","updated_date":null,"description":"Do you know that you can stream HTTP data for efficient visualization? Learn more about how you can stream data with HTTP using Node.js and Fetch API.","title":"Implement HTTP Streaming with Node.js and Fetch API","tags":["Node.js","Fetch API","Streaming"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/15f56fac896fb3f3370431c08e4ffbac/ee604/http-streaming-with-nodejs-and-fetch-api.png","srcSet":"/static/15f56fac896fb3f3370431c08e4ffbac/69585/http-streaming-with-nodejs-and-fetch-api.png 200w,\n/static/15f56fac896fb3f3370431c08e4ffbac/497c6/http-streaming-with-nodejs-and-fetch-api.png 400w,\n/static/15f56fac896fb3f3370431c08e4ffbac/ee604/http-streaming-with-nodejs-and-fetch-api.png 800w,\n/static/15f56fac896fb3f3370431c08e4ffbac/f3583/http-streaming-with-nodejs-and-fetch-api.png 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Nick Van Nieuwenhuyse","github":"Nivani","avatar":null}}}},{"node":{"excerpt":"Introduction It is an indisputable reality that authentication is critical in any application or system if you want to secure user data and…","fields":{"slug":"/engineering/guest-post/session-authentication-with-nestjs-and-mongodb/"},"html":"It is an indisputable reality that authentication is critical in any application or system if you want to secure user data and enable secure access to information. Authentication is the procedure of establishing or demonstrating that something is true, legitimate, or valid.
\nThis tutorial is a hands-on demonstration. To follow along, ensure you have the following in place:
\n\nNest (NestJS) is a Node.js server-side application framework for building scalable, efficient applications.
\nIt is written in TypeScript and built on Express, a very minimalistic framework that is great on its own but lacks structure. It combines programming paradigms such as object-oriented programming, functional programming, and functional reactive programming.
\nIt is a framework to use if you want a lot of structure on your backend. Its syntax and structure are very similar to AngularJS, a front-end framework. And it uses TypeScript, services, and dependency injection in the same way that AngularJS does.
\nIt employs modules and controllers, and you can build controllers for a file using the command-line interface.
\nNestJS modules allow you to group related controllers and service providers into a single code file. Simply put, a NestJS module is a TypeScript file with the @Module annotation (). This decorator informs the NestJS framework about which controllers, service providers, and other associated resources will be instantiated and used by the app code later.
\nSession-based authentication is a method of user authentication in which the server creates a session after a successful log-in, with the session ID stored in a cookie or local storage in your browser.
\nUpon subsequent requests, your cookie is validated against the session ID stored on the server. If there is a match, the request is considered valid and processed.
\nWhen using this authentication method, it is critical to keep the following security best practices in mind:
\nSession-based authentication is more secure than most authentication methods because it is simple, secure, and has a limited storage size. It is also thought to be the best option for websites in the same root domain.
\nStart your project setup by installing Nest CLI globally. You don’t need to do this if you already have NestJS CLI installed.
\nThe Nest CLI is a command-line interface tool for setting up, developing, and maintaining Nest applications.
\nnpm i -g @nestjs/cliNow, let’s set up your project by running the following command:
\nnest new session-based-authThe above command creates a Nest application with some boilerplates, then prompts you to choose your preferred package manager to install the required modules to run your application. For demonstration, this tutorial uses npm. Hit the enter key to continue with npm.
\nThe above command installs Passport.js, a popular nest.js authentication library. Also, install the types for the strategy with the command below: It contains type definitions for To set up and connect your database, install the Mongoose package and the NestJS wrapper with the following command: The Mongoose NestJS wrapper helps you use Mongoose in the NestJS application and gives approved TypeScript support. Now, head over to your Setting up your database connection in For separation concerns, to make your code clean and well organized, create a module specifically for users using the NestJS CLI by running the following command: The above command creates a Also, create Note that you can create your folders and files manually without using the nest CLI, but using the CLI automatically updates the necessary folders and makes your life easier. The next step is to create your UserSchema, but first, add a This should be the shape of our application To create Also, create an interface for your Model that extends mongoose, a document that helps you populate your MongoDB collections. Head over to your This will enable you to share the file anywhere with the help of dependency injection. In It's usually a good idea to encapsulate the business logic in a separate class. Such a class is known as a service. The job of this class is to process the controller's requests and perform the business logic. In Now that the The most critical aspect of the registration procedure is the users’ passwords, which must not be saved in plain text. It is the responsibility of the user to create a strong password, but it is your obligation as a developer to keep their passwords secure. If a database breach occurs, the users' passwords would be exposed. And what happens if it’s stored in plain text? I believe you know the answer. To address this, hash the passwords using bcrypt. So, install With that out of the way, set up your controller. First, import your The registration happens in the Congratulations! You are done with the registration. You can now register a user with a username and password. Now, with registration out of the way, add a Just as for users, create an auth module and service specifically for all the authentications/verifications. To do that, run the following commands: The above will create an auth folder, At this point, the shape of your application The above generate command will update your Go to your In your To add some basic validations, check if the user exists in the database, and compare the given password with the one in your database to ensure it matches. If it exists, return the user in the Going further, create a new file and name it Create a constructor and inject the Go back to your Now, add the login route to your Now that you have all these put in place, you still cannot log in a user because there is nothing to trigger the login route. Here, use Guards to achieve that. Create a file and name it Add the Finally, you can log in a user with a registered username and password. You have successfully set up user authentication. Now, protect your routes from unauthorized access by limiting access to just authenticated users. Go to your The protected route in the above code will return an empty object instead of returning the user’s details when a logged-in user makes a request to it because it already lost the login. To get that sorted, this is where the session-based authentication comes in. In session-based authentication, when a user logs in, the user is saved in a session so that any subsequent request by the user after login will grab the details from the session and grant the user easy access. The session expires when the user logs out. To start session-based auth, install express-session and the NestJS types using the following command: When the installation is completed, go to your Import everything from It is preferable to keep your secret key in your environment variables. Add a new file, In the above code, the request is gotten from the context and checked if authenticated. To trigger the login, in your At this point, it still fails because you've only configured When a user logs in, you need to save the user in a session so that the user can access other routes with the session. One thing to keep in mind is that by default, the Before it goes into the session, you need to serialize the user. As it comes out of the session, deserialize the user. So, create a new file in the auth folder for serializer and deserializer, name it At this point, the shape of our application Go back to your Add some codes within the Call the If you log in now, you will see the session ID stored in a cookie, which is just a key to the session store, and the cookie gets saved in the browser. The cookie is automatically attached to the rest of the request. Now that the session is working, you can access the protected route; it will return the expected user’s details. As mentioned earlier, once a user logs out, you destroy all sessions. To log out a user, go to the So, once you log out, it returns a message notifying you that the user session has ended. The code for this tutorial is hosted here on my Github repository. You have successfully implemented user signup, authentication, and protected the route to enable authorized access only. It’s time to test the application. If everything is in order, your server should be running. Else, restart your server with the following command: Head over to your Postman. And let’s finally test our application. LoginRadius provides a variety of registration and authentication services to assist you in better connecting with your consumers. On any web or mobile application, LoginRadius is the developer-friendly Identity Platform that delivers a complete set of APIs for authentication, identity verification, single sign-on, user management, and account protection capabilities like multi-factor authentication. To implement LoginRadius in your NestJS application, follow this tutorial: NestJS User Authentication with LoginRadius API. Congratulations! In this tutorial, you've learned how to implement session-based authentication in a NestJS application with the MongoDB database. You've created and authenticated a user and protected your routes from unauthorized access. You can access the sample code used in this tutorial on GitHub. Note: Session storage is saved by default in 'MemoryStore,' which is not intended for production use. So, while no external datastore is required for development, once in production, a data store such as Redis or another is suggested for stability and performance. You can learn more about session storage here. Finding it challenging to integrate invisible reCAPTCHA only on specific web pages? This short tutorial helps you implement invisible reCAPTCHA at specific and distinct containers, such as login and forgot password. This tutorial uses LoginRadius to demonstrate this. Google reCAPTCHA is a security service that helps protect your websites from fraud and abuse. Currently, LoginRadius supports two different versions of Google v2reCAPTCHA. You want to enable invisible reCAPTCHA on a specific page — a login page, for demonstration. To achieve this, first login to your LoginRadius dashboard. Or, sign up here for a free account or 21-day free trial for the Developer Pro plan. If you're new to LoginRadius, follow our Getting Started documentationdocs/references/javascript-library/getting-started/) to get going. So, you will need to do the following client-side setup for adding the invisible reCAPTCHA on a specific page only — for example, on the login page. Now, add the following code to render the captcha only at the login page, and here The above code used the utility method The last step is to stop resetting the reCAPTCHA before reCAPTCHA submission. So, add the following code: When you check your hosted page, invisible reCAPTCHA will appear only on the login page. Similarly, you can follow the above steps to enable invisible reCAPTCHA on the registration(signup) page or any other page. You have learned how to use invisible reCAPTCHA on specific web pages and forms with LoginRadius to improve user experience and prevent malicious bot traffic from being effective. Protecting customer data is paramount to every business organization. Even though businesses deploy the most stringent security measures to safeguard data, malicious actors somehow find security shortcomings to access network systems and cause data breaches, compromising the confidentiality, integrity, and availability of information. Cybersecurity firms like Okta, which provides identity management solutions and deals in authentication space, make the backbone of an organization's cybersecurity posture. Okta serves 15000+ customers worldwide. The Okta data breach by Lapsus$ is a recent example of what can happen if business organizations depend on third-party solution providers who show laxity in implementing robust cybersecurity strategies, frameworks, and controls. It is also a cautionary tale for cybersecurity MSPs (Managed Services Providers) and ITSPs (IT Solution Providers) to ensure that they have the best of security controls in place to prevent incidents like this. Okta is an identity platform and offers identity and access management solutions such as Single sign-on (SSO), Multi-Factor Authentication (MFA), etc., for an organization's customers and employees. Okta’s CSO (Chief Security Officer) David Bradbury recently published an official statement about a support engineer whose computer was accessed by malicious actors for five days in mid-January (between January 16 to 21, 2022) and said they detected the unsuccessful attempt early on. Okta has now confirmed that malicious actors had access to one of its employees' laptops for five days in January 2022 but maintained there has been no data breach and remains fully operational. However, they concede that around 2.5% of its customers (about 366) might have been affected. Here is how the attack happened. News reports show that a group of unscrupulous actors identifying themselves as Lapsus$ in their Telegram channel was behind this Okta breach. They were aided by a customer support engineer working for a third-party service provider whose laptop was accessed by these hackers to gain vital information. Lapsus$ is also known as a notorious threat actor group — DEV-0537. This group has a history of taking over individual user accounts to drain their crypto holdings at cryptocurrency exchanges. The forensics report cited by Okta's CSO did not state how the hackers managed to gain access to the support engineer’s laptop, but the fingers point towards negligence by the engineer. However, the hackers claim to have had access to Okta's systems for more than a month before the January 2022 incident. If these claims are valid, it indicates a significant security breach at Okta's network center. The Okta breach exposed the security frailties of the Okta network system and put 15,000 Okta customers’ data at risk. However, Okta stated it had contacted the affected 2.5% of customers, appraising them of the matter. Okta further noted that the customers need not take any precautionary measures as their data is safe. The CSO blog post went on to add that the damage was restricted to the access that support engineers have, such as Jira tickets and lists of users. Though customer support engineers facilitate password resetting and MFA, the hackers did not seem to have obtained this information. The CSO also confirmed that customer service engineers could not create or delete users. Notably, Okta's customers include high-profile enterprises like FedEx Corporation and Moody's Corporation. Hence, Okta's shares plunged 11% immediately after hackers claimed the breach that has put thousands of Okta customers at risk. Limiting access and permissions to the employees is the first step to take. Employees and contractors should only be provided access on a 'need-to-know' basis and must be provided on a ‘least privilege’ basis (minimum access needed to perform a task or job). For example, support engineers shouldn't be able to access internal HR, accounting, or payroll systems. At the same time, marketing personnel should not have access to network configuration or applications that they do not use. In an increasing multi-cloud and hybrid-cloud environment, it's paramount to understand the s IT ecosystem, third-party APIs (Application Programming Interfaces) and applications, and Software as a Service (SaaS) solutions deployed. Requesting SOC reports from vendors and contractors can help understand how their information systems are maintained and secured. Implementing robust processes around Identity and Access Management (IAM) and Privileged Access Management (PAM) can help strengthen the cybersecurity posture by making it almost impossible for attackers to barge into the organization’s periphery. 'People' are the most valuable asset for any organization but can also be the weakest link in the cybersecurity chain. Therefore, organizations must regularly review the processes around training and educating employees, vendor-contractors, customers, and users to follow basic cyber hygiene. Organizations must continue to monitor and audit the control environments. Leveraging automated monitoring and alerting tools can help overcome many challenges SOC teams face. Organizations should perform internal audits and review the systems and monitor the traffic and access permission more frequently. It is also advisable to engage third-party audit firms to get an external and independent view of the cybersecurity posture. In case of a security incident, it is essential to be transparent to the employees, customers, vendors, and regulators and communicate with them immediately about the incident. Organizations should also provide specific guidance on how to safeguard the information assets. The Okta breach shows that no business organization is 100% safe from malicious attacks. One simplest security issue is sufficient for malicious actors to wreak havoc. In this specific example, the hackers accessed the laptop of one of Okta's customer service engineers to gain vital insights into the company's customer data. Such incidents prove that customers can never be sure that their information is safe and leak-proof. However, it offers a valuable learning experience that business entities should not ignore the minutest of details regarding network security. It surfaces the adage that ' A chain is only as strong as its weakest link.' To create secure applications, you need a way to authenticate and authorize your users. In this tutorial, you will learn to authenticate users in your NestJS apps using LoginRadius Authentication API. Authentication and authorization are often seen as similar concepts, but they are not. Authentication is the process of verifying that a user is who they claim to be, while authorization is verifying which resources the user has access to. Authentication always comes first before authorization since you first need to identify the user before determining what level of access to give them. You can either choose to implement your own authentication strategy or leverage the benefits of a third-party identity platform. A do-it-yourself solution is prone to security errors, takes up a lot of time, and can increase the complexity of your application. With a third-party solution, you get access to multiple authentication methods, advanced security features, and you write less code. LoginRadius is a no-code identity platform offering authentication, authorization, account security, and privacy solutions. The Authentication API provided by LoginRadius allows you to authenticate a user using an email and a password. Once the user is verified, LoginRadius responds with an access token. The user will, in turn, use the access token to send requests to protected endpoints. NestJS is a Node.js framework built on Express.js with an Angular-like architectural structure. It is used to build scalable and modern server-side applications. The following sections will guide you in creating a simple NestJS application with authentication. Create a new NestJS project by running the following commands To authenticate a user using LoginRadius in NestJS, you need credentials: an API key and an API secret. Get your account credentials by creating a free LoginRadius account and head over to the dashboard. Create an app and select configuration and then get your app's credentials from the API credentials panel. Since the API key and API secret from the LoginRadius dashboard are sensitive, you will store them in the You will need the dotenv module to access the your environment variables. Run the following command to install it. Add the API key, API secret, and Secure One Time Token(SOTT) to the.env file. In this project, you will be authenticating the user using their email and password. The following are the major steps you will be following: Generate an auth module, controller, and service by running the following code. To create a user, you need to create a signup route that will accept the email and password. Since you are using TypeScript, define the DTO (Data Transfer Object) schema to validate the user data passed in the request body. In the Next, inside the A service file is used to abstract the business logic away from the controller. You will be handling the actual authentication and authorization process in this file. Generate a service for auth by running the following command. Next, populate the auth.service file by adding the signup method. Note that you are also importing the user DTO and the loginradius-sdk at the top of the file.\nTo execute the signup method in the signup route, inject it in the Before registering the user, validate if the email is already in use.\nFirst, install Next import Next, check if the email is already in use. If the email is not already in use, register the user. In the above code, you register a new user by passing in the user data to the authentication API. The To log in the user, pass in the email and password to the authentication API of LoginRadius. In Since you are expecting the same type of data from the request body, i.e., the email and password, like in the signup route, you can reuse the user DTO. Next, add the login functionality. In the above code, you are logging in the user through loginradius-sdk. If successful, send back the Inject the login method in the For protected routes, like accessing a user dashboard, the user will need to send the access token with the request. The access token will then be verified, and if valid, the application will be granted access. The user will need to store the In NestJS, guards are responsible for handling authorization. They determine whether a request will be handled by the route. In In the above code, you define the auth guard that will be used to decorate the protected routes. The token is extracted from the request authorization header and passed to the In Now, create a protected route. In Now, every route you add Use Postman or any other REST client of your choice to test the routes you have created. First, create a test user by sending a POST request to the signup endpoint. Remember to include the email and password of the user in the request body. You should receive a \"Sign up successful\" message if the request is successful. In this tutorial, you have learned how to implement NestJS authentication using the LoginRadius Authentication API. You have seen how to log in a user and use an access token to protect specific routes. You can find the source code used in this tutorial on Github. Learn more about the LoginRadius Authentication API from the documentation files. It has more identity management features than discussed in this tutorial. You can use these features to further enhance authentication as you need in your NestJS projects. Google has prepared a roadmap to restrict third-party cookies in Chrome. Since 04 January 2024, Chrome has rolled out third-party cookie restrictions for 1% of stable clients and 20% of Canary, Dev, and Beta clients. What does it mean for user authentication? On one hand, Google believes third-party cookies are widely used for cross-site tracking, greatly affecting user privacy. Hence, Google wants to phase out (or restrict) supporting third-party cookies in Chrome by early Q2 2025 (subject to regulatory processes). On the other hand, Google introduced Privacy Sandbox to support the use cases (other than cross-site tracking and advertising) previously implemented using third-party cookies. In this article, we’ll discuss: Third-party cookie restrictions affect user authentication in three ways, as follows. If your website or app uses an external Identity Provider (IdP) — like LoginRadius, the IdP sets a third-party cookie when the user authenticates on your app. If you have multiple apps across domains within your organization and authentication is handled using an IdP (internal or external) with web SSO, you already use third-party cookies to facilitate seamless access for each user using a single set of credentials. If you have implemented web SSO with one primary domain and multiple sub-domains of the primary domain, third-party cookie restrictions may not apply. For now, Google doesn’t consider the cookies set by sub-domains as third-party cookies, although this stance may change in the future. For example, you have apps at Federated SSO is similar to, albeit different from, web SSO. It can handle multiple IdPs and applications—aka., Service Providers (SPs)—spanning multiple organizations. It can also implement authentication scenarios that are usually implemented through web SSO. Usually, authentication is handled on a separate pop-up or page when the user wants to authenticate rather than on the application or website a user visits. For example, you already use federated SSO if you facilitate authentication for a set of apps through multiple social identity providers as well as traditional usernames and passwords. Note: It is also possible to store tokens locally, not within cookies. In this case, third-party cookie restrictions won’t affect token-based authentication. However, the restrictions still affect authentication where tokens are stored within third-party cookies (a common and secure method). Google has been developing alternative features and capabilities for Chrome to replace third-party cookies as part of its Privacy Sandbox for Web initiative. Specific to authentication, Google recommends the following: CHIPS are a restricted way of setting third-party cookies on a top-level site without making them accessible on other top-level sites. Thus, they limit cross-site tracking and enable specific cross-site functionalities, such as maps, chat, and payment embeds. For example, a user visits If the user visits You should specifically opt for partitioned cookies (CHIPS), which are set with partitioned and secure cookie attributes. If you’re using an external identity provider for your application, CHIPS is a good option to supplant third-party cookie restrictions. However, CHIPS may not be ideal if you have a web SSO or federated SSO implementation. It creates separate partitioned cookies for each application with a separate domain, which can increase complexity and create compatibility issues. With Storage Access API, you can access the local storage in a third-party context through iframes, similar to when users visit it as a top-level site in a first-party context. That is, it gives access to unpartitioned cookies and storage. Storage Access API requires explicit user approval to grant access, similar to locations, camera, and microphone permissions. If the user denies access, unpartitioned cookies and storage won’t be accessible in a third-party context. It is most suitable when loading cross-site resources and interactions, such as: Verifying user sessions when allowing interactions on an embedded social post or providing personalization for an embedded video.\nEmbedded documents requiring user verification status to be accessible. As it requires explicit user approval, it is advisable to use Storage Access API when you can’t implement an identity use case with the other options. With Related Website Sets, you can declare a Chrome automatically recognizes related website sets declared, accepted, and maintained in this open-source GitHub repository: Related Website Sets It provides access through Storage Access API directly without prompting for user approval, but only after the user interacts with the relevant iframe. It is important to declare a limited number of domains in related website sets that are meaningful and used for specific purposes. Google may block or suspend any exploitative use of this feature. The top-level site can also request approval for specific cross-site resources and scripts to Storage Access API using If you’re using an external identity provider for your web application, you can declare the domain of the identity provider in the related set to ensure limited third-party cookies and storage access to the identity provider, thus ensuring seamless user authentication. Related Website Sets can also work to supplement third-party cookie restrictions in web SSO and federated SSO if the number of web applications (or domains) is limited. FedCM API enables federated SSO without third-party cookies. With FedCM API, a user follows these steps for authentication: You can access a user demo of FedCM here: FedCM. For more information about implementing federated SSO with FedCM API, go through the FedCM developer guide. Firstly, we’re committed to solving our customers' user identity pain points — and preparing for the third-party cookies phase-out is no different. We’ll implement the most relevant and widely useful solutions to facilitate a smooth transition for our customers. Please subscribe to our blog for more information. We’ll update you on how we help with the third-party cookie phase-out. The proposed changes to phase out third-party cookies and suggested alternatives are evolving as Google has been actively collaborating and discussing changes with the border community. Moreover, browsers like Firefox, Safari, and Edge may approach restricting third-party cookies differently than Google does. From LoginRadius, we’ll keep you updated on what we’re doing as a leading Customer Identity and Access Management (CIAM) vendor to prepare for the third-party cookie phase-out. Top-level site: It is the primary site a user has visited. First-party cookie: A cookie set by the top-level site. Third-party cookie: A cookie set by a domain other than the top-level site. For example, let’s assume that a user has visited
\nnpm install --save @nestjs/passport passport passport-localpassport-local.
\nnpm install --save-dev @types/passport-localSet Up MongoDB Database in NestJS
\n
\nnpm install --save @nestjs/mongoose mongooseapp.module.ts, and import the mongoose module from @nestjs/mongoose. Then call the forRoot() method, a method provided by the Mongoose module, and pass in your database URL string.app.module.ts helps your application connect to the database immediately as the server starts — after running your application since it’s the first module to be loaded.app.module.ts
\nimport { Module } from "@nestjs/common"\nimport { MongooseModule } from "@nestjs/mongoose"\nimport { AppController } from "./app.controller"\nimport { AppService } from "./app.service"\n\n@Module({\n imports: [\n MongooseModule.forRoot(\n "mongodb+srv://<username>:<password>@cluster0.kngtf.mongodb.net/session-auth?retryWrites=true&w=majority"\n ),\n ],\n controllers: [AppController],\n providers: [AppService],\n})\nexport class AppModule {}Create Users Module
\n
\nnest g module usersusers folder with users.module.ts and updates app.module.tsusers.service.ts and users.controller.ts files with the following commands:
\nnest g service users\nnest g controller usersCreate User Schema
\nusers.model.ts file, where you will create UserSchemasrc folder now.
\n└───src\n│ └───users\n│ │ └───users.controller.ts\n│ │ └───users.model.ts\n│ │ └───users.module.ts\n│ │ └───users.service.ts\n│ └───app.controller.ts\n│ └───app.module.ts\n│ └───app.service.ts\n│ └───main.tsUserSchema, import everything as mongoose from the mongoose package in users.model.ts. Then call the new mongoose schema, a blueprint of the user Model, and pass in a JavaScript object where you will define the user object and data.users.model.ts
\nimport * as mongoose from "mongoose"\nexport const UserSchema = new mongoose.Schema(\n {\n username: {\n type: String,\n required: true,\n unique: true,\n },\n password: {\n type: String,\n required: true,\n },\n },\n { timestamps: true }\n)\n\nexport interface User extends mongoose.Document {\n _id: string;\n username: string;\n password: string;\n}users.module.ts and import MongooseModule in the imports array. Then call the forFeature() method provided by MongooseModule, and pass in an array of object that takes in name and schema.users.module.ts
\nimport { Module } from "@nestjs/common"\nimport { MongooseModule } from "@nestjs/mongoose"\nimport { UsersController } from "./users.controller"\nimport { UserSchema } from "./users.model"\nimport { UsersService } from "./users.service"\n@Module({\n imports: [MongooseModule.forFeature([{ name: "user", schema: UserSchema }])],\n controllers: [UsersController],\n providers: [UsersService],\n})\nexport class UsersModule {}users.module.ts, export the UsersService to enable you to access it in another module.users.module.ts
\nimport { Module } from "@nestjs/common"\nimport { MongooseModule } from "@nestjs/mongoose"\nimport { UsersController } from "./users.controller"\nimport { UserSchema } from "./users.model"\nimport { UsersService } from "./users.service"\n@Module({\n imports: [MongooseModule.forFeature([{ name: "user", schema: UserSchema }])],\n controllers: [UsersController],\n providers: [UsersService],\n exports: [UsersService],\n})\nexport class UsersModule {}users.service.ts file, import Model from mongoose, User from users.model.ts, and InjectModel from @nestjs/mongoose. Then add a method to the UsersService class that takes a username and password, and call the method insertUser().users.service.ts
\nimport { Injectable } from '@nestjs/common';\nimport { InjectModel } from '@nestjs/mongoose';\nimport { Model } from 'mongoose';\nimport { User } from './users.model';\n@Injectable()\nexport class UsersService {\n constructor(@InjectModel('user') private readonly userModel: Model<User>) {}\n async insertUser(userName: string, password: string) {\n const username = userName.toLowerCase();\n const newUser = new this.userModel({\n username,\n password,\n });\n await newUser.save();\n return newUser;\n }\n}UsersService class is ready, you need to inject it into your controller. But first, let's talk about storing the users' passwords securely.bcrypt and @types/bcrypt with the following command:
\nnpm install @types/bcrypt bcryptUsersService class and everything from bcrypt. Then add a constructor and a method that allows you to add a user; it will handle incoming post requests, call it addUser, with a function body where you'll hash the password.users.controller.ts
\nimport { Body, Controller, Post } from '@nestjs/common';\nimport { UsersService } from './users.service';\nimport * as bcrypt from 'bcrypt';\n@Controller('users')\nexport class UsersController {\n constructor(private readonly usersService: UsersService) {}\n //post / signup\n @Post('/signup')\n async addUser(\n @Body('password') userPassword: string,\n @Body('username') userName: string,\n ) {\n const saltOrRounds = 10;\n const hashedPassword = await bcrypt.hash(userPassword, saltOrRounds);\n const result = await this.usersService.insertUser(\n userName,\n hashedPassword,\n );\n return {\n msg: 'User successfully registered',\n userId: result.id,\n userName: result.username\n };\n }\n}app.module.ts file, which is achieved by adding the UsersModule to the @Module() decorator's imports' array in app.module.ts.app.module.ts
\nimport { Module } from "@nestjs/common"\nimport { MongooseModule } from "@nestjs/mongoose"\nimport { AppController } from "./app.controller"\nimport { AppService } from "./app.service"\nimport { UsersModule } from "./users/users.module"\n\n@Module({\n imports: [\n MongooseModule.forRoot(\n "mongodb+srv://<username>:<password>@cluster0.kngtf.mongodb.net/session-auth?retryWrites=true&w=majority"\n ),\n UsersModule,\n ],\n controllers: [AppController],\n providers: [AppService],\n})\nexport class AppModule {}getUser function to your UsersService with the findOne method to find a user by username.users.service.ts
\nimport { Injectable } from '@nestjs/common';\nimport { InjectModel } from '@nestjs/mongoose';\nimport { Model } from 'mongoose';\nimport { User } from './users.model';\n@Injectable()\nexport class UsersService {\n constructor(@InjectModel('user') private readonly userModel: Model<User>) {}\n async insertUser(userName: string, password: string) {\n const username = userName.toLowerCase();\n const newUser = new this.userModel({\n username,\n password,\n });\n await newUser.save();\n return newUser;\n }\n async getUser(userName: string) {\n const username = userName.toLowerCase();\n const user = await this.userModel.findOne({ username });\n return user;\n }\n}Create Authentication Module
\n
\nnest g module auth\nnest g service authauth.module.ts, and auth.service.ts, and update the auth.module.ts and app.module.ts files.src folder should look as follows.
\n└───src\n│ └───auth\n│ │ └───auth.module.ts\n│ │ └───auth.service.ts\n│ └───users\n│ │ └───users.controller.ts\n│ │ └───users.model.ts\n│ │ └───users.module.ts\n│ │ └───users.service.ts\n│ └───app.controller.ts\n│ └───app.module.ts\n│ └───app.service.ts\n│ └───main.tsapp.module.ts, and it will look like the code snippet below:app.module.ts
\nimport { Module } from "@nestjs/common"\nimport { MongooseModule } from "@nestjs/mongoose"\nimport { AppController } from "./app.controller"\nimport { AppService } from "./app.service"\nimport { UsersModule } from "./users/users.module"\nimport { AuthModule } from './auth/auth.module';\n\n\n@Module({\n imports: [UsersModule, AuthModule, MongooseModule.forRoot(\n //database url string\n 'mongodb://localhost:27017/myapp'\n )],\n controllers: [AppController],\n providers: [AppService],\n})\nexport class AppModule {}Authenticate Users
\nauth.module.ts file and add UsersModule in the imports array to enable access to the UsersService exported from the users.module.ts file.auth.module.ts
\nimport { Module } from "@nestjs/common"\nimport { UsersModule } from "src/users/users.module"\nimport { AuthService } from "./auth.service"\n\n@Module({\n imports: [UsersModule],\n providers: [AuthService],\n})\nexport class AuthModule {}auth.service.ts file, call the constructor so you can inject the UsersService, and add a method for validation that will take a username and password.request.user object — else, return null.auth.service.ts
\n import { Injectable, NotAcceptableException } from '@nestjs/common';\n import { UsersService } from 'src/users/users.service';\n import * as bcrypt from 'bcrypt';\n\n @Injectable()\n export class AuthService {\n constructor(private readonly usersService: UsersService) {}\n async validateUser(username: string, password: string): Promise<any> {\n const user = await this.usersService.getUser(username);\n const passwordValid = await bcrypt.compare(password, user.password)\n if (!user) {\n throw new NotAcceptableException('could not find the user');\n }\n if (user && passwordValid) {\n return {\n userId: user.id,\n userName: user.username\n };\n }\n return null;\n }\n }local.strategy.ts. This file will represent the strategy from Passport.js, which you installed earlier, that is the local strategy. And within it, pass in the strategy, which is the Strategy from passport-local.AuthService, call the super() method; ensure to call the super() method.local.strategy.ts
\n import { Injectable, UnauthorizedException } from '@nestjs/common';\n import { PassportStrategy } from '@nestjs/passport';\n import { Strategy } from 'passport-local';\n import { AuthService } from './auth.service';\n @Injectable()\n export class LocalStrategy extends PassportStrategy(Strategy) {\n constructor(private readonly authService: AuthService) {\n super();\n }\n async validate(username: string, password: string): Promise<any> {\n const userName = username.toLowerCase();\n const user = await this.authService.validateUser(userName, password);\n if (!user) {\n throw new UnauthorizedException();\n }\n return user;\n }\n }auth.module.ts file. Then add PassportModule to imports and LocalStrategy to providers.auth.module.ts
\nimport { Module } from "@nestjs/common"\nimport { PassportModule } from "@nestjs/passport"\nimport { UsersModule } from "src/users/users.module"\nimport { AuthService } from "./auth.service"\nimport { LocalStrategy } from "./local.strategy"\n\n@Module({\n imports: [UsersModule, PassportModule],\n providers: [AuthService, LocalStrategy],\n})\nexport class AuthModule {}users.controller.ts:users.controller.ts
\n import {\n Body,\n Controller,\n Post,\n Request,\n } from '@nestjs/common';\n import * as bcrypt from 'bcrypt';\n import { UsersService } from './users.service';\n @Controller('users')\n export class UsersController {\n constructor(private readonly usersService: UsersService) {}\n //post / signup\n @Post('/signup')\n async addUser(\n @Body('password') userPassword: string,\n @Body('username') userName: string,\n ) {\n const saltOrRounds = 10;\n const hashedPassword = await bcrypt.hash(userPassword, saltOrRounds);\n const result = await this.usersService.insertUser(\n userName,\n hashedPassword,\n );\n return {\n msg: 'User successfully registered',\n userId: result.id,\n userName: result.username\n };\n }\n //Post / Login\n @Post('/login')\n login(@Request() req): any {\n return {User: req.user,\n msg: 'User logged in'};\n }\n }local.auth.guard.ts, then a class LocalAuthGuard that extends AuthGuard from NestJS/passport, where you will provide the name of the strategy and pass in the name of your strategy, local.local.auth.guard.ts.
\nimport { Injectable } from "@nestjs/common"\nimport { AuthGuard } from "@nestjs/passport"\n@Injectable()\nexport class LocalAuthGuard extends AuthGuard("local") {}UseGuard decorator to your login route in the users.controller.ts file, and pass in the LocalAuthGuard.users.controller.ts
\n import {\n Body,\n Controller,\n Post,\n UseGuards,\n Request,\n } from '@nestjs/common';\n import * as bcrypt from 'bcrypt';\n import { LocalAuthGuard } from 'src/auth/local.auth.guard';\n import { UsersService } from './users.service';\n @Controller('users')\n export class UsersController {\n constructor(private readonly usersService: UsersService) {}\n //post / signup\n @Post('/signup')\n async addUser(\n @Body('password') userPassword: string,\n @Body('username') userName: string,\n ) {\n const saltOrRounds = 10;\n const hashedPassword = await bcrypt.hash(userPassword, saltOrRounds);\n const result = await this.usersService.insertUser(\n userName,\n hashedPassword,\n );\n return {\n msg: 'User successfully registered',\n userId: result.id,\n userName: result.username\n };\n }\n //Post / Login\n @UseGuards(LocalAuthGuard)\n @Post('/login')\n login(@Request() req): any {\n return {User: req.user,\n msg: 'User logged in'};\n }\n }Protect Authentication Routes
\nusers.controller.ts file, and add another route — name it ‘protected’ and make it return the req.user object.users.controller.ts
\n import {\n Body,\n Controller,\n Get,\n Post,\n UseGuards,\n Request,\n } from '@nestjs/common';\n import * as bcrypt from 'bcrypt';\n import { LocalAuthGuard } from 'src/auth/local.auth.guard';\n import { UsersService } from './users.service';\n @Controller('users')\n export class UsersController {\n constructor(private readonly usersService: UsersService) {}\n //signup\n @Post('/signup')\n async addUser(\n @Body('password') userPassword: string,\n @Body('username') userName: string,\n ) {\n const saltOrRounds = 10;\n const hashedPassword = await bcrypt.hash(userPassword, saltOrRounds);\n const result = await this.usersService.insertUser(\n userName,\n hashedPassword,\n );\n return {\n msg: 'User successfully registered',\n userId: result.id,\n userName: result.username\n };\n }\n //Post / Login\n @UseGuards(LocalAuthGuard)\n @Post('/login')\n login(@Request() req): any {\n return {User: req.user,\n msg: 'User logged in'};\n }\n // Get / protected\n @Get('/protected')\n getHello(@Request() req): string {\n return req.user;\n }\n }
\nnpm install express-session @types/express-sessionmain.ts file, the root of your application, and do the configurations there.passport and express-session, then add passport initialize and passport session.main.ts
\nimport { NestFactory } from "@nestjs/core"\nimport { AppModule } from "./app.module"\nimport * as session from "express-session"\nimport * as passport from "passport"\nasync function bootstrap() {\n const app = await NestFactory.create(AppModule)\n app.use(\n session({\n secret: "keyboard",\n resave: false,\n saveUninitialized: false,\n })\n )\n app.use(passport.initialize())\n app.use(passport.session())\n\n await app.listen(3000)\n}\nbootstrap()authenticated.guard.ts, in your auth folder. And create a new Guard that checks if there is a session for the user making the request — name it authenticatedGuard.authenticated.guard.ts
\nimport { CanActivate, ExecutionContext, Injectable } from "@nestjs/common"\n\n@Injectable()\nexport class AuthenticatedGuard implements CanActivate {\n async canActivate(context: ExecutionContext) {\n const request = context.switchToHttp().getRequest()\n return request.isAuthenticated()\n }\n}isAuthenticated() comes from passport.js automatically; it says. \"hey! does a session exist for this user? If so, keep going.\"users.controller.ts file:\n
\nauthenticated from authenticated.guard.ts;useGuard decorator to the protected route; and,AuthenticatedGuard.users.controller.ts
\n import {\n Body,\n Controller,\n Get,\n Post,\n UseGuards,\n Request,\n } from '@nestjs/common';\n import * as bcrypt from 'bcrypt';\n import { AuthenticatedGuard } from 'src/auth/authenticated.guard';\n import { LocalAuthGuard } from 'src/auth/local.auth.guard';\n import { UsersService } from './users.service';\n @Controller('users')\n export class UsersController {\n constructor(private readonly usersService: UsersService) {}\n //signup\n @Post('/signup')\n async addUser(\n @Body('password') userPassword: string,\n @Body('username') userName: string,\n ) {\n const saltOrRounds = 10;\n const hashedPassword = await bcrypt.hash(userPassword, saltOrRounds);\n const result = await this.usersService.insertUser(\n userName,\n hashedPassword,\n );\n return {\n msg: 'User successfully registered',\n userId: result.id,\n userName: result.username\n };\n }\n //Post / Login\n @UseGuards(LocalAuthGuard)\n @Post('/login')\n login(@Request() req): any {\n return {User: req.user,\n msg: 'User logged in'};\n }\n //Get / protected\n @UseGuards(AuthenticatedGuard)\n @Get('/protected')\n getHello(@Request() req): string {\n return req.user;\n }\n }express-session but didn't implement it.express-session library stores the session in the web server's memory.session.serializer.ts.src folder should look like this.
\n └───src\n │ └───auth\n │ │ └───auth.module.ts\n │ │ └───auth.service.ts\n │ │ └───authenticated.guard.ts\n │ │ └───local.auth.guard.ts\n │ │ └───local.strategy.ts\n │ │ └───session.serializer.ts\n │ └───users\n │ │ └───users.controller.ts\n │ │ └───users.model.ts\n │ │ └───users.module.ts\n │ │ └───users.service.ts\n │ └───app.controller.ts\n │ └───app.module.ts\n │ └───app.service.ts\n │ └───main.tssession.serializer.ts
\nimport { Injectable } from "@nestjs/common"\nimport { PassportSerializer } from "@nestjs/passport"\n\n@Injectable()\nexport class SessionSerializer extends PassportSerializer {\n serializeUser(user: any, done: (err: Error, user: any) => void): any {\n done(null, user)\n }\n deserializeUser(\n payload: any,\n done: (err: Error, payload: string) => void\n ): any {\n done(null, payload)\n }\n}auth.module.ts file, provide the SessionSerializer, and add the register method to the PassportModule.auth.module.ts
\nimport { Module } from "@nestjs/common"\nimport { PassportModule } from "@nestjs/passport"\nimport { UsersModule } from "src/users/users.module"\nimport { AuthService } from "./auth.service"\nimport { LocalStrategy } from "./local.strategy"\nimport { SessionSerializer } from "./session.serializer"\n\n@Module({\n imports: [UsersModule, PassportModule.register({ session: true })],\n providers: [AuthService, LocalStrategy, SessionSerializer],\n})\nexport class AuthModule {}LocalAuthGuard in the local.auth.guard.ts file.login method in super and pass in the request to trigger the actual login by creating a session. If you want to use sessions, you must remember to trigger the super.login().local.auth.guard.ts
\n import { ExecutionContext, Injectable } from '@nestjs/common';\n import { AuthGuard } from '@nestjs/passport';\n @Injectable()\n export class LocalAuthGuard extends AuthGuard('local') {\n async canActivate(context: ExecutionContext) {\n const result = (await super.canActivate(context)) as boolean;\n const request = context.switchToHttp().getRequest();\n await super.logIn(request);\n return result;\n }\n }Logout Users
\nusers.controller.ts file, add a logout route, and call the req.session.session() method. You can return a message notifying that the user’s session has ended.
\n import {\n Body,\n Controller,\n Get,\n Post,\n UseGuards,\n Request,\n } from '@nestjs/common';\n import * as bcrypt from 'bcrypt';\n import { AuthenticatedGuard } from 'src/auth/authenticated.guard';\n import { LocalAuthGuard } from 'src/auth/local.auth.guard';\n import { UsersService } from './users.service';\n @Controller('users')\n export class UsersController {\n constructor(private readonly usersService: UsersService) {}\n //signup\n @Post('/signup')\n async addUser(\n @Body('password') userPassword: string,\n @Body('username') userName: string,\n ) {\n const saltOrRounds = 10;\n const hashedPassword = await bcrypt.hash(userPassword, saltOrRounds);\n const result = await this.usersService.insertUser(\n userName,\n hashedPassword,\n );\n return {\n msg: 'User successfully registered',\n userId: result.id,\n userName: result.username\n };\n }\n //Post / Login\n @UseGuards(LocalAuthGuard)\n @Post('/login')\n login(@Request() req): any {\n return {User: req.user,\n msg: 'User logged in'};\n }\n //Get / protected\n @UseGuards(AuthenticatedGuard)\n @Get('/protected')\n getHello(@Request() req): string {\n return req.user;\n }\n //Get / logout\n @Get('/logout')\n logout(@Request() req): any {\n req.session.destroy();\n return { msg: 'The user session has ended' }\n }\n }Test Your Application
\n
\nnpm run start:devSign Up As a User
\nLog In As a User
\nLogged-in User’s Cookie ID
\nUser Logout
\nAlternatively, Implement User Authentication with LoginRadius
\nConclusion
\n\n
\n","frontmatter":{"date":"April 26, 2022","updated_date":null,"description":"Want to implement user authentication for your NestJS apps? Follow this tutorial to learn how you can implement session-based authentication for your NestJS apps along with MongoDB.","title":"NestJS: How to Implement Session-Based User Authentication","tags":["Authentication","NestJS","MongoDB","Node.js"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/d28db627e3ed8b9cfc8febf39b1cefad/ee604/session-based-authentication-in-nestjs.png","srcSet":"/static/d28db627e3ed8b9cfc8febf39b1cefad/69585/session-based-authentication-in-nestjs.png 200w,\n/static/d28db627e3ed8b9cfc8febf39b1cefad/497c6/session-based-authentication-in-nestjs.png 400w,\n/static/d28db627e3ed8b9cfc8febf39b1cefad/ee604/session-based-authentication-in-nestjs.png 800w,\n/static/d28db627e3ed8b9cfc8febf39b1cefad/f3583/session-based-authentication-in-nestjs.png 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Ekekenta Odionyenfe Clinton","github":"icode247","avatar":null}}}},{"node":{"excerpt":"Finding it challenging to integrate invisible reCAPTCHA only on specific web pages? This short tutorial helps you implement invisible…","fields":{"slug":"/engineering/integrate-invisible-captcha-for-bot-protection/"},"html":"\n\n
\nWhat is reCAPTCHA?
\n\n
\nThe Scenario
\nSolution Steps
\n\n
\n\n
\nraasoption.invisibleRecaptcha = false;beforeFormRender hook is used.
\nLRObject.$hooks.register('beforeFormRender', function(name, schema){\nLRObject.options.invisibleRecaptcha = false;\nif (name == 'login' ) {\n LRObject.options.invisibleRecaptcha = true;\n LRObject.util.addRecaptchaJS();\n LRObject.util.captchaSchema("loginradius-recaptcha_widget_login", schema);\n}\n});addRecaptchaJS that adds the required JS for invisible reCAPTCHA. It also used the captchaSchema method to add reCAPTCHA within the Login Schema.\n
\n
\nLRObject.$hooks.register('eventCalls', function(name){\nLRObject.options.invisibleRecaptcha = false;\nLRObject.options.optionalRecaptchaConfiguration.IsEnabled = true;\nif (name == 'login' ) {\n LRObject.options.invisibleRecaptcha = true;\n LRObject.options.optionalRecaptchaConfiguration.IsEnabled = false;\n}\n});Conclusion
\nWhat Is Okta?
\nWhy Is Okta In the News?
\nHow Was the Attack Executed?
\n\n
\nWho Is Behind Okta’s Breach?
\nThe Key Reasons That Caused The Security Breach
\nOkta Breach: What Was the Impact?
\nWhat to Learn From Okta's Cyber Hack?
\n1) Limit Access on a ‘Need-to-Know’ Basis
\n2) Validate Third-party Apps and SaaS Solutions
\n3) Implement Robust IAM-PAM Solutions
\n4) Train Employees and Customers
\n5) Be Vigilant
\n6) Audit and Review Regularly
\n7) Communicate Transparently
\nTo Conclude
\nAuthentication vs. Authorization
\nUser Authentication with LoginRadius
\nUser Authentication in NestJS
\nSet Up the Project
\n
\n// Install NestJS CLI\nnpm i -g @nestjs/cli\n\n// Create a new project\nnest new nest-loginradius-auth\n\ncd nest-loginradius-authSet Up LoginRadius
\nSet Up .env file
\n.env file.
\nnpm install dotenv
\nAPP_NAME=<your app name>\nAPI_KEY=<your api key>\nAPI_SECRET=<your api secret>\nSOTT= <your sott>Authentication Flow
\n\n
\nCreate an Authentication Module
\n
\nnest generate module auth\nnest generate controller authCreate a User
\nauth folder, add the dto folder and create a UserDTO class in the user.dto.ts file.
\nexport class UserDto {\n email: string;\n password: string;\n}AuthController, import the DTO to be used to validate the request body.
\nimport { Injectable } from '@nestjs/common';\nimport { UserDto } from './dto/user.dto';\n\n@Injectable()\n@Controller('auth')\nexport class AuthController {\n @Post('signup')\n async signup(@Body() registerUserDto: UserDto) {\n // Register user\n }\n}Generate Auth Service File
\n
\nnest g service auth
\nimport { Injectable } from '@nestjs/common';\nimport { UserDto } from './dto/user.dto';\nimport * as LRAuthPrrovider from 'loginradius-sdk'\n\n@Injectable()\nexport class AuthService {\n async signup(registerUserDto: UserDto) {\n console.log('sign up')\n }\n}auth.controller.ts file.
\nimport { Injectable } from '@nestjs/common';\nimport { UserDto } from './dto/user.dto';\nimport { AuthService } from './auth.service';\n\n@Injectable()\n@Controller('auth')\nexport class AuthController {\n constructor(private readonly authService: AuthService) { }\n\n @Post('signup')\n async signup(@Body() registerUserDto: UserDto) {\n let response = await this.authService.signup(registerUserDto)\n return response\n }\n}loginradius-sdk using the following command.
\nnpm i loginradius-sdkloginradius-sdk and configure it and since you will be using variables from the .env file, remember to also configure dotenv.
\nimport * as dotenv from 'dotenv';\ndotenv.config()\nimport * as LRAuthPrrovider from 'loginradius-sdk'\n\nlet config = {\n apiDomain: "api.loginradius.com",\n apiKey: process.env.API_KEY,\n apiSecret: process.env.API_SECRET,\n siteName: process.env.APP_NAME,\n apiRequestSigning: false,\n proxy: {\n host: "",\n port: "",\n user: "",\n password: "",\n },\n };\nlet lrv2 = LRAuthPrrovider(config);\n\nlet sott = process.env.SOTT
\n@Injectable()\nexport class AuthService {\n async signup(registerUserDto: UserDto) {\n try {\n const response = await lrv2.authenticationApi\n .checkEmailAvailability(registerUserDto.email)\n if (response.isExist) {\n return "Email already in use"\n }\n catch(error) {\n return error\n }\n }\n}
\n@Injectable()\nexport class AuthService {\n async signup(registerUserDto: UserDto) {\n try {\n // check if email is already in use\n const response = await lrv2.authenticationApi\n .checkEmailAvailability(registerUserDto.email)\n if (response.isExist) {\n return "Email already in use"\n }\n // create registration model\n let authUserRegistrationModel = {\n email: [\n {\n type: "primary",\n value: registerUserDto.email,\n },\n ],\n password: registerUserDto.password,\n };\n // register user\n let user = await lrv2.authenticationApi\n .userRegistrationByEmail(authUserRegistrationModel, sott)\n if(user) {\n return "Sign up successful"\n }\n } catch (error) {\n return error\n }\n }\n}authUserRegistrationModel object defines how the email and password will be stored in the database.Log In the User
\nauth.service.ts, add the login function.
\n@Injectable()\nexport class AuthService {\n async signup(registerUserDto: UserDto) {\n // register user\n }\n async login(loginUserDTO: UserDto) {\n // login user\n }\n}
\n@Injectable()\nexport class AuthService {\n async signup(registerUserDto: UserDto) {\n // register user\n }\n async login(loginUserDTO: UserDto) {\n try {\n let emailAuthenticationModel = {\n email: loginUserDTO.email,\n password: loginUserDTO.password,\n };\n let user = await lrv2.authenticationApi\n .loginByEmail(emailAuthenticationModel)\n return {\n accessToken: user.access_token,\n }\n } catch (error) {\n return error\n }\n }\n}accessToken in the response body. The user will use the access token to access protected routes.auth.controller.ts file to use it in the login route.
\nimport { Injectable } from '@nestjs/common';\nimport { UserDto } from './dto/user.dto';\nimport { AuthService } from './auth.service';\n\n@Injectable()\n@Controller('auth')\nexport class AuthController {\n constructor(private readonly authService: AuthService) { }\n\n @Post('signup')\n async signup(@Body() registerUserDto: UserDto) {\n // register user\n }\n async login(@Body() loginUserDto: UserDto) {\n // login user\n }\n}Access Protected Routes
\naccessToken. In this tutorial, you will be storing the token in the authorization header as a bearer token. Another alternative would be to use HTTP-only cookies.auth.guard.ts, add the following code.
\nimport {AuthService } from './auth.service';\nimport { Request } from 'express';\n\n@Injectable()\nexport class AuthGuard implements CanActivate {\n\n constructor(\n private readonly authService: AuthService,\n ) {}\n\n async canActivate(context: ExecutionContext): Promise<boolean> {\n const request: Request = context.switchToHttp().getRequest();\n\n // Extract the access token from the authorization header\n const authheader = request.header('Authorization');\n const token = authheader && authheader.split(" ")[1];\n try {\n let authorizedMsg = await this.authService.authenticate(token);\n // Attach the authorized message to the request. You could also attach the user information.\n request['isAuthorized'] = "Authorized"\n return true;\n } catch (error) {\n throw new UnauthorizedException();\n }\n }\n}authenticate method defined in AuthService. This method will be responsible for verifying the token.auth.service.ts, create the authenticate method. This method will send the access token to LoginRadius for verification.
\nimport { Injectable, UnauthorizedException } from '@nestjs/common';\nimport { UserDto } from './dto/user.dto';\nimport * as LRAuthPrrovider from 'loginradius-sdk'\n\n@Injectable()\nexport class AuthService {\n async signup(registerUserDto: UserDto) {\n // signup user\n }\n async login(loginUserDTO: UserDto) {\n // login user\n }\n async authenticate(accessToken: string) {\n try {\n const response = await lrv2.authenticationApi\n .authValidateAccessToken(accessToken)\n return response\n } catch (error) {\n throw new UnauthorizedException();\n }\n }\n}auth.controller.ts, add the following.
\nimport { Controller, Get, Body, Post, UseGuards } from '@nestjs/common';\nimport { UserDto } from './dto/user.dto';\nimport { AuthService } from './auth.service';\nimport { AuthGuard } from './auth.guard';\n\n@Controller('auth')\nexport class AuthController {\n constructor(private readonly authService: AuthService) { }\n\n @Post('signup')\n async signup(@Body() registerUserDto: UserDto) {\n // signup user\n }\n @Post('login')\n async login(@Body() loginUserDto: UserDto) {\n // login user\n }\n @UseGuards(AuthGuard)\n @Get('protected')\n async protected() {\n return "Access granted"\n }\n}UseGuards to will require a valid access token.Test with Postman
\n
\nPOST http://localhost:3000/auth/signupConclusion
\n\n
\nHow is User Authentication Affected?
\nExternal Identity Providers
\nWeb SSO
\nexample.com, travel.example.com, stay.example.com, and web SSO is handled by auth.example.com. In this case, third-party cookie restrictions don’t apply.Federated SSO
\n\n
\nChrome’s Alternatives for Third-Party Cookies
\n\n
\nCookies Having Independent Partitioned State (CHIPS)
\na.com with a map embed from map-example.com, which can set a partitioned cookie that is only accessible on a.com. b.com with a map embed from map-example.com, it cannot access the partitioned cookie set on a.com. It has to create a separate partitioned cookie specific to b.com, thus blocking cross-site tracking yet allowing limited cross-site functionality.Storage Access API
\nRelated Website Sets
\nprimary website and associatedSites for limited purposes to grant third-party cookie access and local storage for a limited number of sites.resuestStorageAccessFor() API.Federated Credential Management (FedCM) API
\n\n
\nHow is LoginRadius Preparing for the Third-party Cookie Phase-out?
\nIn Conclusion
\nGlossary
\na.com, which might use an embed from loginradius.com to facilitate authentication. If loginradius.com sets a cookie when the user visits a.com, it is called a third-party cookie as the user hasn’t directly visited loginradius.com.References
\n\n","frontmatter":{"date":"July 08, 2024","updated_date":null,"description":"Google Chrome has planned to phase out third-party cookies, which will affect different website functionalities depending on third-party cookies. This blog focuses on how this phase-out affects identity and user authentication and discusses alternatives for overcoming challenges.","title":"How Chrome’s Third-Party Cookie Restrictions Affect User Authentication?","tags":["Identity","Cookies","Chrome"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/eb7396060c0adc430dbed2d04b63d431/ee604/third-party-cookies-phaseout-chrome.png","srcSet":"/static/eb7396060c0adc430dbed2d04b63d431/69585/third-party-cookies-phaseout-chrome.png 200w,\n/static/eb7396060c0adc430dbed2d04b63d431/497c6/third-party-cookies-phaseout-chrome.png 400w,\n/static/eb7396060c0adc430dbed2d04b63d431/ee604/third-party-cookies-phaseout-chrome.png 800w,\n/static/eb7396060c0adc430dbed2d04b63d431/f3583/third-party-cookies-phaseout-chrome.png 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Raghunath Reddy","github":"raghunath-r-a","avatar":null}}}},"pageContext":{"limit":6,"skip":12,"currentPage":3,"type":"//engineering//","numPages":52,"pinned":"17fa0d7b-34c8-51c4-b047-df5e2bbaeedb"}},"staticQueryHashes":["1171199041","1384082988","2100481360","23180105","528864852"]}