Open 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\")
In this post, I’ll talk about how cookies compare to browser storage. You’ll understand why cookies came out, the problem they solve, and their limitations.
\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
Under the storage section, you'll find a section named \"Session Storage\".
\n
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,"description":"This article helps you understand the differences between browser storage and cookies. By the end, you'll understand when to use cookies and browser storage (both local storage and session storage).","title":"Local Storage vs. Session Storage vs. Cookies","tags":["Cookie","Browser Storage","Authentication","JWT"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/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":{"excerpt":"All React developers love to leverage the benefits React caters to in developing web applications. But developers need to keep in mind the…","fields":{"slug":"/engineering/react-security-vulnerabilities/"},"html":"All React developers love to leverage the benefits React caters to in developing web applications. But developers need to keep in mind the security postures while creating React web apps. React applications face a vast attack surface and are prone to different vulnerabilities. This article is a checklist of React security best practices that every developer should know before diving into PWA (progressive web application) development.\nIf you are new to progressive web applications and React, let's get familiar with these terminologies first.
\nProgressive Web Apps (PWA) are apps built using web technologies like HTML, CSS, and JavaScript (JS). But these apps deliver the experience, feel, and functionality of a native app. PWA combines new technologies and integrations to build a reliable, engaging, accessible, and secure application. Developers mostly use React on top of HTML and JavaScript to build a progressive web app.
\nReact is popular among progressive web app developers. This open-source, robust JavaScript library helps in building user interfaces based on UI components. React gains popularity in the software development industry because it allows developers to create lightweight apps with additional facilities: security, push notification, app-like look and feel, etc. Some popular companies that have become the early adopters of React are Instagram, Netflix, Airbnb, Uber Eats, Discord, the New York Times, etc.
\nReact helps developers build a reliable, robust, and secure progressive web app, but these apps face certain security pitfalls also. Developers need to give prior attention to security vulnerabilities, which are often ignored due to faster app development cycles or more focus on product features.\nWith the arrival of each new update in React having more features, the security flaws are getting unnoticed. Such unnoticed actions are increasing security concerns. Here is a list of top React security vulnerabilities that every React developer must address before delivering or deploying their apps.
\nSQL Injection (SQLi) is a widely known web application attack. The cybercriminal intends to perform database manipulation logically to access sensitive information that is not supposed to be displayed. Attackers try to sneak into that sensitive information to collect phone numbers, payment details, addresses, passwords, and other credentials.\nThis technique allows the attackers to manage access to the server, pull the data, and manipulate the values in the database. Apart from data modification, hackers can also delete the data.\nLet us take an example. Let us take an example where the code will search for the current user-ID and the login matching the employee name, where the owner is the current user-ID.
\nstring query = "SELECT * FROM logondata WHERE owner = "'"\n+ empID + "' AND empName = '"\n+ EmpName.Text + "'";Combining both the employee ID and employee name, the following query gets generated.
\nSELECT * FROM logondata\nWHERE owner =\nAND empName = ;The problem that pops here is that the main code leverages the concept of concatenation that helps in combining those data. The attacker can use a string like 'empName' OR 'x'='x' as the employee name. 'x' = 'x' is such a condition, which will always evaluates to True. Therefore, the statement returns True for all values within the table. So, the following query becomes:
SELECT * FROM logondata\nWHERE owner = 'karlos'\nAND empName = 'name' OR 'x' = 'x';There are three major categories of SQL injection based on how attackers gain access to the backend data.
\nIn-band SQL Injection: Here the persuader will instigate the attack and gather sensitive credentials via one single channel. Such SQL attacks are simple, and hence, it is one of the most commonly performed SQLi attacks on React apps. It comes with two sub-categories –
\nInferential/Blind SQL Injection: The attacker pushes payloads targeting the server. Then they observe the behavior and keep track of the server response to know more about the database structure. Here, the attacker cannot witness the data reverting through the attack in-band, hence the name \"Blind.\" There are two sub-categories of blind SQLi.
\nThe comprehensive rendering feature of React makes it a preferable choice over other JavaScript libraries and frameworks. But this rendering feature also drags React-based apps to the most widely exploited vulnerability, cross-site scripting (XSS). Cross-site scripting leverages malicious client-side scripts by injecting them into web applications. When the users trigger those scripts, the attackers gain control over the app and steal sensitive information from the web application.
\nInjecting malicious scripts into the react app will make the app release some internal app data. Therefore, React developers should prevent the application from running the script. Here is a typical example of cross-site scripting where the attacker can place and execute a malicious script within the application like this:
\n<input type="search" value="PWA"/>Now, executing malicious script will make the search look like:
\n<input type="search" value="Attacker "/> <script> StealCredentials() </script>"> ;Here, StealCredentials() is a function that contains malicious scripts to steal user information.\nLet us now take a look at the types of XSS.
\nThis attack gains popularity, not simply because of its potential to harm the target users through the application but because such attacks need more creative and intellectual hackers. But, to prevent such attacks, developers need to become even more creative.
\nYou can also use content security policies as the last line of defense against XSS. If all other XSS prevention fails, CSP allows developers to control various things, such as loading external scripts and executing inline scripts. To deploy CSP, developers need to include an HTTP response header called Content-Security-Policy with a value carrying the policy.\nAn example for including CSP is as follows:
\ndefault-src 'self'; script-src 'self'; object-src 'none'; frame-src 'none'; base-uri 'none';Broken authentication is a weakness through which attackers can capture one or multiple accounts when authentication or session management is poorly implemented in progressive web apps. This vulnerability helps the attacker take over multiple user accounts, letting the attacker possess the same privileges and access control as the target user.
\nAttackers usually exploit such a React security vulnerability by detecting the authentication solution or bypassing them. The security team labels the authentication as broken when the cybercriminal can compromise users' passwords, session tokens, digital identities, or account information from the React app. Examples of some common reasons for this attack are:
\nLet us take a situation where the attacker could detect the hashes for the following names.
\nSue 4420d1918bbcf7686defdf9560bb5087d20076de5f77b7cb4c3b40bf46ec428s\nKarlos 4420d1918bbcf7686defdf9560bb5087d20076de5f77b7cb4c3b40bf46ec624g\nDee 77b177de23f81d37b5b4495046b227befa4546db63cfe6fe541fc4c3cd216egkThe hash function will store the password in a hashed form rather than plain text. But then, humans can easily read the hash. Now, if two different users enter the same password, then these passwords will generate the same hash. Hackers can perform a dictionary attack, and if they crack one password, they can use the same password to gain access to other accounts that use the same hash.
\nAttackers can perform XML External Entities attacks on React web applications that parse XML input. Here the outdated XML parsers of your React app become vulnerable. Such vulnerability can lead an attacker to perform denial of service, port scanning, server-side request forgery, etc. Such attacks occur when an XML input gets referred to an external entity but has a weakly configured XML parser. Here are some examples where attackers are attempting XEE on React web applications that parse XML input.
\nThe attacker might attempt to extract data from the server.
\n<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE sample [\n<!ELEMENT sample POO >\n<!ENTITY xmlxxe SYSTEM "file:///etc/passwd" >]> <sample> &xmlxxe; </sample>Another code snippet where the attacker explores the private network of the server by tweaking the code:
\n<!ENTITY xmlxxe SYSTEM "https://186.141.2.1/privnw" >]>It is another code snippet where the attacker tries for a Denial of Service (DoS) attack by comprising a potentially perpetual file:
\n<!ENTITY xmlxxe SYSTEM "file:///gkr/rand" >]>It is another popular React app vulnerability where the malicious actor exploits the app by submitting zip files having malicious or arbitrary code within them. React developers enable adding zip files to decrease the file size while they get uploaded. When the app unzips the archive, its malicious file(s) can overwrite other files or perform arbitrary code execution. Attackers can either harm the files existing in the target system or gain remote access to the system.
\nHere is a Zip slip code example demonstrating a ZipEntry path merges to a destination directory without validating that path. Researchers and security professionals have found similar codes in different repositories across many apps.
\nEnumeration<ZipEntry> entry = zip.getEntries();\n while (entry.hasMoreElements()) {\nZipEntry ez = entry.nextElement();\nFile fil = new File(destinationDir, ez.getName());\nInputStream input = zip.getInputStream(ez);\nIOUtils.copy(input, write(fil));\n }Here is a link to the repository containing libraries and APIs infected by zip slip.
\nCSRF is another React web application vulnerability allowing attackers to persuade users to perform unintentional actions without their direct consent. It does not steal the identity of the legitimate user but acts against their will. For rendering such attacks, the attacker sends an email or a web link convincing the victim to achieve a state-changing request in the application.
\nBefore going through the checklist on fixing CSRF vulnerabilities, here is a quick example of how the CSRF GET request will be once the attacker tweaks it.\nA standard GET request for a $250 transfer from person1 to person2 might look like this:
\nWhen the attacker induces the user to perform some unintended action or runs a malicious script, the $250 gets transferred to the attacker's account. This malicious request might look something like this:
\nSome attackers can also put innocent-looking hyperlinks embedding the request.
\nIt might happen that you have pushed a React app's code to GitHub. Now an email/notification is popping up saying, \"One of your dependencies has a security vulnerability.\" That is another method where attackers seek the help of malicious packages to gain access to your React applications. Such malicious packages collect valuable app details and user information and send it to a third party.
\nThese packages can also execute malicious code during the package installation phase. These attackers use the concept of typosquatting to make their attacks seamless. Typosquatting is a method of naming the packages based on their original counterparts. It outwits the developers into downloading these malicious packages that can wreak havoc on the React app.
\nHope this comprehension has given a crisp idea of the top React vulnerabilities and the different checklists developers can use to fix those security flaws. Developers should know how crucial application security is for both the business and its users. As the React features are increasing, there is an equal delay in the number of days taken by the React community to fix any React security issues.
\nIn this article, we discussed the most well-known vulnerabilities like SQLi, XSS, Broken Authentication, XXE, Zip Slip, CSRF, and Package & dependency vulnerabilities, plus how to prevent React apps from such attacks. So, developers and product managers should cautiously handle all security-related aspects of a React project by following the checklist given in this article.
\n","frontmatter":{"date":"December 24, 2021","updated_date":null,"description":"React security vulnerabilities are hard to detect. However, this article talks about the top 7 vulnerabilities and how to fix them to enjoy all the benefits React caters to in developing Progressive Web Applications.","title":"React Security Vulnerabilities and How to Fix/Prevent Them","tags":["React","Vulnerability"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.2820512820512822,"src":"/static/9bd496853e1dfc053e95fe44dbb19cc7/58556/react-security.webp","srcSet":"/static/9bd496853e1dfc053e95fe44dbb19cc7/61e93/react-security.webp 200w,\n/static/9bd496853e1dfc053e95fe44dbb19cc7/1f5c5/react-security.webp 400w,\n/static/9bd496853e1dfc053e95fe44dbb19cc7/58556/react-security.webp 800w,\n/static/9bd496853e1dfc053e95fe44dbb19cc7/99238/react-security.webp 1200w,\n/static/9bd496853e1dfc053e95fe44dbb19cc7/7c22d/react-security.webp 1600w,\n/static/9bd496853e1dfc053e95fe44dbb19cc7/24dd2/react-security.webp 1926w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Gaurav Kumar Roy","github":"GauravRoy6","avatar":null}}}},{"node":{"excerpt":"Security has become a fundamental aspect to consider while developing an application. As people become more aware and hackers more notorious…","fields":{"slug":"/engineering/guest-post/securing-php-api-with-jwt/"},"html":"Security has become a fundamental aspect to consider while developing an application. As people become more aware and hackers more notorious, you need to employ systems that strengthen your application's data security.
\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,"description":"This tutorial helps you understand why you should secure your PHP API. Then, it helps you learn how to use JWT with Apache to secure your PHP API.","title":"How to Secure a PHP API Using JWT","tags":["PHP","JWT","Authentication"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/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":{"excerpt":"Securing communications between a client and a server often requires credentials to identify both parties. That is where the different…","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,"description":"Understand how cookie-based and cookieless authentication methods work. And learn their major differences, advantages, and disadvantages.","title":"Cookie-based vs. Cookieless Authentication: What’s the Future?","tags":["Authentication","JWT","Cookie"],"pinned":null,"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":{"excerpt":"Authentication is an essential part of any web application. But unfortunately, it is not always easy to implement. What is Authentication…","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,"description":"This tutorial helps you build a simple Flask API and demonstrates how to secure it using JWT. In the end, you can test your API authentication using a sample schema.","title":"Using JWT Flask JWT Authentication- A Quick Guide","tags":["Flask","JWT","API"],"pinned":null,"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":{"excerpt":"Single-tenant and multi-tenant cloud architectures represent two core approaches to managing SaaS environments, each with unique benefits…","fields":{"slug":"/engineering/saas-single-tenancy-vs-multi-tenancy/"},"html":"Single-tenant and multi-tenant cloud architectures represent two core approaches to managing SaaS environments, each with unique benefits depending on how resources and infrastructure are utilized. In a single-tenant cloud, each customer has their own dedicated environment, offering greater control, data security, and customization. Meanwhile, multi-tenant cloud architecture allows multiple customers to share the same infrastructure, driving down costs and enabling faster, more frequent updates.\nHence, choosing the right cloud architecture is crucial for your business.
\nThis article comprehensively compares SaaS-based multi-tenant and single-tenant cloud architectures along with their benefits and drawbacks. The comprehension also points out which one to choose based on the organization’s requirements and scenario.
\nA single-tenant architecture dedicates a single instance of the software, infrastructure, or database to a single customer. The single-tenant system encapsulates all customer data and interactions distinctly from other customers. Moreover, customer information is not shared in any way.
\nIn a single-tenant architecture, the provider helps manage the software instance and dedicated infrastructure while giving a single-tenant nearly complete flexibility over software and infrastructure modification. Single-tenancy models provide control, reliability, security, and backup capability. In addition, each tenant has its independent database and software instance, keeping them separate from one another. Each tenant's data also has a remote backup, allowing tenants to restore their data in case of data loss quickly. In most cases, tenants can choose when they want to install any available updates themselves rather than waiting for the service provider to do so.
\nUltimately, potential customers who desire more control and flexibility to meet specific needs in their environment would likely prefer a single-tenant infrastructure over other solutions.
\nAlthough single-tenancy architecture is uncommon, it caters to easy auditing and maintenance. Here is the list of some other benefits a single-tenant cloud provides:
\nDespite all of the potential benefits of single-tenancy, it is still the least popular architecture among competing options, which you could attribute to some of its drawbacks. The following are some of the disadvantages of single-tenancy:
\nSingle-Tenant or Multi-Tenant SaaS: Which is Better for Your Business
\nMulti-tenancy is another cloud architecture wherein a single instance of a software program serves numerous customers. People usually refer to the real estate analogy to explain Single-tenant vs. Multi-tenant cloud architecture.
\nEvery user in a single-tenant cloud lives alone in a single building with its security system and amenities, entirely secluded from neighboring buildings. Tenants in multi-tenant cloud architecture, on the other hand, live in various apartments within a single apartment complex. They are both protected by the same security system and have access to the same communal facilities. However, each resident has a key to their apartment, ensuring that their privacy is protected. The actions of other tenants, however, are more likely to affect their comfort in the property.
\nMost startups choose a multi-tenant architecture having a single massive database containing all customer information. Customer data is kept confidential with the necessary security systems in place. While customers cannot view each other's data, they are all stored in the same database, and all of the data gets processed by the same computer.
\nIn contrast, the single-tenancy customer does not benefit from such scenarios.
\nWhile multi-tenant cloud architecture is usually the best option for most SaaS customers, it can have some drawbacks, including:
\nGreater Security Risk: As different customers share resources, the risk factor in a multi-tenant setup increases. In contrast to a single-tenant cloud, where security events remain isolated to a single customer, it is more likely to harm other customers if one customer's data is compromised.
\nIn multi-tenancy, an organization's data is not visible to other tenants. However, multiple users without the organization's affiliation get access to the same database. This increases the security risks.
\nA single-tenant setup of SaaS may be appropriate for certain companies or sectors where customer data privacy and security are paramount. The healthcare and finance industries are excellent examples, leveraging single-tenant cloud systems.
\nFor example, when working with patient information, applications in the healthcare industry must comply with HIPAA regulations. To maintain compliance, each hospital may need to establish its own data center on-site. The same is true for certain forms of financial information.
\nMost consumer-facing applications and start-ups that require comparatively less customizability tend to use a multi-tenant setup of SaaS. Also, multi-tenancy is preferred by organizations that want to opt for a cost-effective solution.
\nTo learn more about Single-Tenant vs Multi-Tenant Cloud, check out the infographic by LoginRadius.
\nThere are a lot of other factors an organization must keep in mind while deciding which SaaS architecture to choose. Some business factors are the purpose of cloud adoption, type of application, budget, scalability, customization, migration, visibility, backup, and recovery. Finally, organizations must brainstorm what they want to achieve and how their company operates to arrive at the best, ideal solution.
\n1. What is the difference between single tenant vs multi tenant?
\nIn single tenant architecture, a dedicated cloud infrastructure serves one client, while in a multi tenant cloud, multiple businesses share the same infrastructure, which optimizes resources.
\n2. Is AWS a single tenant?
\nAWS offers primarily multi tenant cloud environments, but single tenant architecture can be achieved through dedicated hosting options like Amazon EC2 Dedicated Instances.
\n3. What is a multi tenant cloud system?
\nA multi tenant cloud system allows multiple businesses to share the same infrastructure, with resources and applications managed centrally for efficiency.
\n4. What are some examples of single tenant and multi tenant systems?
\nPrivate clouds or custom SaaS deployments are examples of single tenant architecture, while platforms like Salesforce represent multi tenant cloud systems.
\n5. Which SaaS architecture is more secure: single tenant or multi tenant?
\nSingle tenant architectures generally offer more security due to isolated data environments, while multi-tenant systems have more shared risks but are often well-protected by cloud providers.
\n6. What is tenancy in cloud computing?
\nTenancy in cloud computing refers to how computing resources are shared—whether through single tenant or multi tenant systems that isolate or combine client resources.
\n7. What is a tenant in cloud computing?
\nA tenant in cloud computing is an entity, such as a business, that uses a specific cloud infrastructure, either in a single tenant or multi tenant setup.
\nLoginRadius provides both single-tenant and multi-tenant SaaS architecture for our CIAM solution.
\n","frontmatter":{"date":"December 01, 2021","updated_date":null,"description":"When choosing a SaaS architecture for your business, the decision between single-tenant and multi-tenant models can significantly impact performance, security, and cost. This blog explores the key differences, advantages, and potential drawbacks of each approach, helping you determine which solution best aligns with your business needs.","title":"Single-Tenant vs. Multi-Tenant: Which SaaS Architecture is better for Your Business? ","tags":["saas","Architecture"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/56b63a15905e7c7aae59c6304095ee86/58556/coverImage.webp","srcSet":"/static/56b63a15905e7c7aae59c6304095ee86/61e93/coverImage.webp 200w,\n/static/56b63a15905e7c7aae59c6304095ee86/1f5c5/coverImage.webp 400w,\n/static/56b63a15905e7c7aae59c6304095ee86/58556/coverImage.webp 800w,\n/static/56b63a15905e7c7aae59c6304095ee86/99238/coverImage.webp 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Rakesh Soni","github":"oyesoni","avatar":"rakesh-soni.webp"}}}}]},"markdownRemark":{"excerpt":"Introduction Ever wondered how apps like Spotify, Netflix, or Slack manage seamless login experiences across devices? Many of them use JWT…","fields":{"slug":"/engineering/how-to-integrate-jwt/"},"html":"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![\"Flowchart](\"/f29edbf2978577390c7ffa02e9bc4dda/lr-JWT-authentication.webp\")
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,"description":"Discover JWT (JSON Web Token) authentication, its advantages, and how to integrate it seamlessly using LoginRadius' hosted IDX and Direct API methods for secure, scalable identity management.","title":"JWT Authentication with LoginRadius: Quick Integration Guide","tags":["JWT","JSON Web Token","Authentication","Authorization"],"pinned":null,"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}}}},"pageContext":{"limit":6,"skip":30,"currentPage":6,"type":"//engineering//","numPages":53,"pinned":"5c425581-f474-5ae9-abe7-cf5342db2aaa"}},"staticQueryHashes":["1171199041","1384082988","2100481360","23180105","528864852"]}