{"componentChunkName":"component---src-templates-tag-js","path":"/tags/cookie/","result":{"data":{"site":{"siteMetadata":{"title":"LoginRadius Blog"}},"allMarkdownRemark":{"totalCount":2,"edges":[{"node":{"fields":{"slug":"/engineering/guest-post/local-storage-vs-session-storage-vs-cookies/"},"html":"

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

\n

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

\n

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

\n

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

\n
\n

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

\n
\n

This website is using cookies to store your information.

\n
\n

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

\n

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

\n

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

\n

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

\n

A Brief History of Cookies

\n

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

\n

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

\n

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

\n

Enter Cookies

\n

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

\n

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

\n

The Rise of Browser Storage

\n

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

\n

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

\n

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

\n

Browser’s Session Storage

\n

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

\n
    \n
  1. \n

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

    \n

    \"Application

    \n
    2. \n
  2. \n

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

    \n

    \"Session

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

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

\n

Storage Capacity

\n

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

\n

Data Persistence

\n

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

\n

Using Session Storage

\n

You can access the session storage in the window object:

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

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

\n

Adding Data

\n

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

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

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

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

You now get your recently added data back!

\n

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

\n

\"Session

\n

Inserting Complex JSON Data

\n

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

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

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

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

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

\n

\"Complex

\n

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

\n

Retrieving Data

\n

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

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

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

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

Usecase

\n

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

\n

Booking Applications

\n

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

\n

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

\n

Prompting Login/Signups to a User

\n

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

\n

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

\n

Browser’s Local Storage

\n

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

\n

\"Local

\n

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

\n

Data Persistence

\n

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

\n

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

\n

Using Local Storage

\n

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

\n

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

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

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

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

Usecase

\n

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

\n

Generic

\n

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

\n

Application Specific

\n

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

\n

Cookies vs. Browser Storage

\n

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

\n

Similarities

\n

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

\n

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

\n

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

\n

Differences

\n

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

\n

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

\n

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

\n

\"Comparison

\n

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

\n

Storing Your JWT/Auth Token

\n

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

\n

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

\n

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

\n

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

\n

Wrapping it Up

\n

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

\n

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

\n

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

\n","frontmatter":{"date":"January 12, 2022","updated_date":null,"title":"Local Storage vs. Session Storage vs. Cookies","tags":["Cookie","Browser Storage","Authentication","JWT"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/e9788df6bdd55f91b1eccb4382f05573/58556/blog-banner.webp","srcSet":"/static/e9788df6bdd55f91b1eccb4382f05573/61e93/blog-banner.webp 200w,\n/static/e9788df6bdd55f91b1eccb4382f05573/1f5c5/blog-banner.webp 400w,\n/static/e9788df6bdd55f91b1eccb4382f05573/58556/blog-banner.webp 800w,\n/static/e9788df6bdd55f91b1eccb4382f05573/99238/blog-banner.webp 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Siddhant Varma","github":"FuzzySid","avatar":null}}}},{"node":{"fields":{"slug":"/engineering/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.

\n\n

Cookies 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.

\n

The entire cookie-based authentication works in the following manner:

\n
    \n
  1. The user gives a username and password at the time of login. Once the user fills in the login form, the browser (client) sends a login request to the server.
    2. \n
  2. \n

    The server verifies the user by querying the user data. If the authentication request is valid, the server generates the following:

    \n\n

    The server then passes the session ID to the browser that keeps it. The server also keeps track of the active sessions.

    \n
    3. \n
  3. The browser has to submit this generated session ID while sending a subsequent request. Every time the server validates the session ID. The session ID helps the authentication process identify the user and provides access accordingly.
    4. \n
  4. When the user logs out of the application, the session gets destroyed from both client (browser) and the server. It discontinues the authentication process from happening again through the respective session ID.
    5. \n
\n\n\n\n\n

What is Cookieless Authentication?

\n

Cookieless 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:

\n
    \n
  1. The user logs into the service by providing their login credentials. It issues an access request from the client-side by sending the credential and API key (public key) to the application server.
    2. \n
  2. The server verifies the login credentials that checks the password entered against the username. Once approved, the server will generate a unique session token that will help authorize subsequent actions.
    3. \n
  3. This access token is sent back to the client via URL query strings, post request body, or other means. The server-generated signed authentication token gets assigned with an expiration time.
    4. \n
  4. The token gets transmitted back to the user's browser. On every subsequent request to the application server or future website visits, the access token gets added to the authorization header along with the public key. If there is a match from the application server against the private key, the user can proceed. If a given token expires, a new token gets generated as an authentication request.
    5. \n
\n

Benefits of Cookieless Authentication

\n\n

Challenges with Cookieless Authentication

\n\n

How does LoginRadius have Native Support for Cookieless Authentication?

\n

LoginRadius 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.

\n

LoginRadius APIs

\n

The 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.

\n

These 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.

\n

JSON Web Tokens

\n

In 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.

\n

JWTs 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.

\n

Additional Options

\n

In 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.

\n

These 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.

\n

Conclusion

\n

Cookieless authentication can facilitate more secure and scalable authentication. You should decide how to authenticate consumers considering your requirements and the benefits and challenges of cookie-based and cookieless authentication.

\n","frontmatter":{"date":"December 14, 2021","updated_date":null,"title":"Cookie-based vs. Cookieless Authentication: What’s the Future?","tags":["Authentication","JWT","Cookie"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/0be9d40cc7bb77e9feb433ff59d7514a/58556/coverImage.webp","srcSet":"/static/0be9d40cc7bb77e9feb433ff59d7514a/61e93/coverImage.webp 200w,\n/static/0be9d40cc7bb77e9feb433ff59d7514a/1f5c5/coverImage.webp 400w,\n/static/0be9d40cc7bb77e9feb433ff59d7514a/58556/coverImage.webp 800w,\n/static/0be9d40cc7bb77e9feb433ff59d7514a/99238/coverImage.webp 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Kundan Singh","github":null,"avatar":null}}}}]}},"pageContext":{"tag":"Cookie"}},"staticQueryHashes":["1171199041","1384082988","2100481360","23180105","528864852"]}