Update: JSON_Web_Token_for_Java_Cheat_Sheet

[Tib3rius]

What is missing or needs to be updated?

The Token Storage on Client Side page recommends using Session Storage over Local Storage, seemingly because Local Storage persists between browser restarts (accurate), however it makes no mention of the fact that Session Storage is implemented per-tab and not per-site. That is, if example.com adds some item to Session Storage, and a user then opens a new tab through any method other than "duplicate tab" (e.g. right-click -> open link in new tab), the new tab will have a completely new (and empty) Session Storage instance, even if the user goes to example.com.

Since opening things in multiple tabs is pretty common user behavior, it is not realistic (IMO) for the recommended method to be implemented by developers.

How should this be resolved?

Honestly, I think the recommendation should be to use Local Storage but with tokens that have short expiration times. There's no perfect solution, but Session Storage doesn't work at all so it's surprising to see it being recommended.

[jmanico]

ASVS also recommends session storage over local storage and I'd like to be consistent with that.

If you want to suggest localStorage please please make sure you state this is only a suggestion if the token exp time is low. Overall I do not suggest localStorage for most services.

[Tib3rius]

@jmanico right but surely that just means ASVS needs changing? We shouldn't be recommending developers use a storage medium for session tokens that deletes them when their users do the simple act of opening a page in a new tab, IMO.

Do you know of any modern app that actually stores them in Session Storage, and how that app maintains sessions with new tabs? If you want to stick with Session Storage, then the advice at least needs to be updated to mention the downsides and how to get around them...

[jmanico]

I suggest that the USERNAME can be stored long term, but features that maintain a long term active session is discouraged for secure software. In general we suggest 15-30 minute idle timeout and a absolutely timeout of like 8 hours.

So storing a active session is localstorage that keeps a user logged in long term is discouraged for any secure software.

[Tib3rius]

@jmanico I appreciate the response but you aren't really answering any of my questions here, and I never once mentioned long term active sessions. My point from the start has been that the OWASP recommendations simply don't work practically for modern websites / browsers.

How does a secure application maintain a session, stored in Session Storage, when a user opens a link in a new tab?

It is this fact that I am most concerned about, because if developers were to implement OWASP recommendations as they currently stand, most if not all applications would break. That to me, seems like something that at the very least we should address by mentioning the limitations of Session Storage on this page, and by suggesting a perhaps less secure method for developers who need users to remain logged in if they open separate tabs.

[jmanico]

I am convinced you are correct. But I would only advise the use of localStorage if the token has both idle and absolute timeout. Let me leave this open for now and I'll make a comment in ASVS and cross-reference this issue. I am with you now.

[Tib3rius]

Thanks @jmanico! Appreciate the willingness to have the discussion, I agree localStorage with severe timeout restrictions seems like a good compromise. This is a problem with seemingly no "nice" solution.

[jmanico]

One more note, this is how some folks deal with the sessionStorage issue:

In one application I use, the session token is indeed not shared across tabs. When you open a new tab with the application, you are redirected to the SSO provider and automatically logged in into the application. So while the application's token is stored in sessionStorage, it still works with multi-tab browsing because of the interaction with the SSO provider.

[ryarmst]

Do you know of any modern app that actually stores them in Session Storage, and how that app maintains sessions with new tabs?

@Tib3rius I have encountered several apps that use Session Storage, but they do not maintain sessions in new tabs natively. Two of them are from personal use rather than testing, so I can share details. The first is the TD Bank's (Canadian bank) EasyWeb (online banking). This was actually the first app I encountered doing this and it was before I started working in security, so they've had it configured that way for some time now. It was definitely annoying from a usability perspective (before I was aware I could simply "duplicate tab") and customers regularly complain about this online. It seems that people have largely adapted to just using a single tab, which I assume was intended by the bank.

More recently, I've been using PlexTrac, which also uses Session Storage in this way. I thought I had actually seen user guidance to make use of "Duplicate Tab" in normal use, but I cannot find it now.

I am not saying this approach is preferred, just offering a couple examples of modern apps doing this ("modern" might be generous in the case of the bank...). Regarding built-in support for multi-tab, it looks like the Broadcast Channel API may be a way to share Session Storage data between tabs as necessary, but I am not sure if there are other implications.