Sharing sessionStorage between tabs for secure multi-tab authentication

Do you have code samples for you demos?

memoryStorage object is not available i window, could you please explain

Excellent explanation and demo! Would you mind sharing what adding IE support would look like?

How is this secure? If another tab can ask for the token and it will freely be given to it, what is to stop a malicious site from asking for and then using the token?

Nice idea. Another possible alternative to using localStorage events for cross-tab communication might be to use the new Broadcast Channel API (as of Chrome 54; excludes Safari & IE).

e.g. (this example still uses sessionStorage to store the session token)

// Connect to the broadcast channel
// (the first tab to connect automatically creates the channel)
const authChannel = new BroadcastChannel("auth");

// Notify other tabs
authChannel.postMessage({message: "NEW_TAB"});

// Listen for channel messages
authChannel.onMessage = event => {
  // Lookup existing auth key for the current tab (if any)
  const key = window.sessionStorage.get("authKey");

  switch (event.data.message) {
    // A new tab has opened
    case "NEW_TAB":
      // If the current tab has an auth key, broadcast it
      if (key) {
        authChannel.postMessage({message: "AUTH_KEY", key});
      }
      break;

    // An auth key has been broadcast
    case "AUTH_KEY":
      // If the current tab doesn't yet have an auth key, store it
      if (!key) {
        window.sessionStorage.set("authKey", event.data.key);
      }
      break;
  }
};

This seems a little cleaner than setting then immediately deleting a localStorage key just for the purposes of triggering an event.

I take your example and changed the token for the current time.
I changed this:
sessionStorage.setItem('token', '123456789');
By this:
var d = new Date();
var n = d.getTime();
sessionStorage.setItem('token', n);

But when I open multiples tabs and click on 'Set session storage' this value not updated the other tabs. Why? This is not the expected behavior?

I read this article https://blog.guya.net/2015/... and I think that 'the-never-ending-browser-sessions' throws all away on 'sharing-sessionstorage-between-tabs-for-secure-multi-tab-authentication' I'm right?

"Opening a page in a new tab or window will cause a new session to be initiated"
By https://developer.mozilla.o...
that opinion deserve this?

Hi, The second one is really nice. But there is a weakness in comparison of the first one. In the second one there is a bad scenario: Open the demo, Set the key, Open it in new tab (key is there), Close the second tab, Refresh the first tab, Token is gone!!! Any idea? (this does not happen in the first one)

I think it's definitely a feature that sessionStorage is restored upon reopening closed tabs (CTRL+SHIFT+T). This is really 'undo' for accidentally closing a tab, so there's no reason why state should not be restored also.

The standard has a relevant note supporting this at https://html.spec.whatwg.or... :
"The lifetime of a browsing context can be unrelated to the lifetime of the actual user agent process itself, as the user agent may support resuming sessions after a restart."

> the only way to be completely sure that the sessionStorage is really gone is to reopen the same website directly and without the “reopen closed tab” feature

Even after doing that, if the user now does CTRL+SHIFT+TAB, the prior tab will be opened with prior session state restored (which is still fine by me).

To achieve what you want (expunging your secure token), I think you need to catch the onunload event and expunge it there. (Please don't lobby browser makers to break the very useful 'undo' feature of restoring full session state!)

An additional factor that you might want to mention is that localStorage is not shared between http & https versions of your site; probably this is a feature for your usecase (but is a real annoyance for what I'm using localStorage/sessionStorage for).

hi, can i have the source code for the second implementation for IE too. im not that nerdy that able to write my own code. please?

Good. We save the token in the sessionStorage, send it as an header with every request to the server in order to authenticate the user. When the user closes the tab – it’s gone.

How can I send the token as a header with every request to the server. The cookie is automatically sent in the header but I have no idea how I would send the token saved in sessionStorage automatically in the header like a cookie would.

Hi,
Neither the localstorage nor the memory storage code worked for my angular application. Completely stuck on this from last few days. I think I need to change it to cookie.

Hey There,

wonderful Article!
We had the same Problem to have Session Storage to be shared between Tabs.

With your solution - Restoring the Session Storage at page load - i had a problem: you could never be sure if there is a session coming or not.

While bootstrapping our Angular Application, the Browser was under such a heavy load, that the response from the other tab could take up to 2 seconds.

Our application would then do an automatic certificate login due to the session storage arriving too late.

So i came up with an alternative:
Counting the open tabs and on window.onUnload i would clear localStorage if the tab count is zero!

So i would use localStorage to behave like sessionStorage except there is Multi Tab Sharing.

Even restoring of the session is not possible!

How do I count the tabs?
There is no native support to achieve this and i was Inspired by your solution of using LocalStorage for multi Tab Communication.

On Page Load:
let tabs=localStorage.getItem('tabs')
const tabId = Math.round((new Date()).getTime());
tabs.push(this.tabId);
localStorage.setItem('tabs', JSON.stringify(tabs));

OnPageUnload:
let tabs=localStorage.getItem('tabs')
tabs = tabs.filter(item => item !== this.tabId); //Deleting current tab
if (tabs.length === 0) {
localStorage.clear();
console.log('Cleared Local Storage');
} else {
localStorage.setItem('tabs', JSON.stringify(tabs));
console.log('Deleted' + this.tabId, tabs);
}

This technique as the advantage that application startup has no delay.
Maybe there is a security concern when the browser cant execute window.onUnload

Do you see any other problems?

Thanks for this solution. However I think your claim that the data will never be in LocalStorage is incorrect. Yes, due to Javascript's run-to-completion event-loop no other function in that same tab will be able to access the LocalStorage item, because it is deleted in the same function call. But another tab can access the LocalStorage item (though the timing is very improbable) between the setItem and removeItem. Try setting a breakpoint on the removeItem. It's not really a risk though, same application and all. But on a slow browser, something might be in LocalStorage for 1 ms after all.

Neither of the two solutions work for the following situation:
- Open demo in 3 tabs
- Clear session in one of them - it never actually clears session storage, unless it's the only tab that's open.

Which is actually very insecure - the user will have completed the action to log out, but because of the other 2 open tabs - they will still be logged in.

If the goal of this solution is to be used for an authentication token, or in other words, knowing if the user is currently authenticated, a typical web site will have the following flow:

1. User navigates to web site.
2. Web site detects whether user is currently logged in.
3. If user isn't logged in, redirect to login page.

So, for step 1, the user opens a brand new web browser with one tab and navigates to the site.

Step 2, the page loads and executes your code. But there is nothing in your code that can definitively determine that no prior session data exists. You make a call to 'localStorage.setItem()' and then wire up an event, expecting to "hear" a response back. The response to the event is an asynchronous operation. You don't know how long it's going to take, or if it's ever going to even happen.

Because the event is asynchronous, and you may not get a callback, you'd have to implement some kind of timeout. But how long should you wait? A lot of times, the initial page load, or some of the data displayed on the page will be dependent upon whether the user is currently logged in. Therefore, you have to hold up the rest of the page load while you're trying to determine/wait for a response to your storage event.

I don't see this as being a very robust solution to this particular problem of storing and sharing a session identifier.

Also note that from OWASP themselves, they recommend NOT to store session identifying information in local or session storage. Instead they recommend using a cookie marked with HttpOnly.

See https://pupuweb.com/owasp-html5-security-cheat-sheet-guide/

Do not store session identifiers in local storage as the data is always accesible by JavaScript. Cookies can mitigate this risk using the httpOnly flag.