Tokens in Local Storage

[kennylavender]

https://www.rdegges.com/2018/please-stop-using-local-storage/

[wzalazar]

we have to take it with care because another proposal is cookies session if I'm not wrong and it brings other risky securities. I list some disadvantages about cookie session here:

Sessions: Every time a user is authenticated, the server will need to create a record somewhere on our server. This is usually done in memory and when there are many users authenticating, the overhead on your server increases.

Scalability: Since sessions are stored in memory, this provides problems with scalability. As our cloud providers start replicating servers to handle application load, having vital information in session memory will limit our ability to scale.

CORS: As we want to expand our application to let our data be used across multiple mobile devices, we have to worry about cross-origin resource sharing (CORS). When using AJAX calls to grab resources from another domain (mobile to our API server), we could run into problems with forbidden requests.

CSRF: We will also have protection against cross-site request forgery (CSRF). Users are susceptible to CSRF attacks since they can already be authenticated with say a banking site and this could be taken advantage of when visiting other sites.

The two methods have problems:

Cookie -> CSRF JWT -> XSS

[kennylavender]

Thank you @wzalazar! Good points.

I believe storing the session information in our/a database instead of our application server solves your points on 'Sessions' and 'Scalability'.

We can use something like koa-session-mongo for this.

This is what @ericelliott taught us to do instead of storing sessions on the application server. It allows scalability horizontally without the need for ugly things like sticky sessions.

Edit: I realized your 'Session' and 'Scalability' concerns were about normal sessions. I did not mean to imply switching to normal sessions. If we use JWT and cookies, it's stateless, so no need to keep sessions in memory or a db. Also, the article mentions IndexedDB, it may be another solution other than cookies

[kennylavender]

As for CORS and CSRF, XSS, I don't have much understanding of those. Maybe I will make it one of my future Fridays to understand those better.

[kennylavender]

Edited above. I did not mean to imply that we should use normal stateful sessions.

[ericelliott]

What kind of token is that? If it's a session token that expires, it's probably fine. If it's a long-lived access token that basically grants the holder free reign to mess with your account at any time in the future, it's probably an issue. =)

[kennylavender]

It's the user apiTokens and the session token.

The session token is 24 hours.

I continued reading on this today, seems LocalStorage was chosen for simplicity and the less likely hood of XSS attacks since I don't think we have any external JS dependencies, so makes sense at this time for short lived sessions.

Not sure if we want those apiTokens stored in LocalStorage though?

[geoffturk]

@wzalazar Can we wipe the API tokens from Local Storage when the user logs out? These are the bigger security risk vs. session tokens, and I can't think of any reason they should remain there after the user has closed his session.

[wzalazar]

@geoffturk you mean with the session, when the user does log out or when the user closes the browser? Because when the user does the log out, we are cleaning all the data. Maybe we can change the localStorage to sessionStorage

[geoffturk]

Maybe we can change the localStorage to sessionStorage

Yes, that would be great.

Question: will sessionStorage be wiped even if the user just closes the browser, without first logging out? I assume yes, but I don't know for certain.

[wzalazar]

@geoffturk with sessionStorage when the user closes the browser or tab the storage will clean. For example, If are log in a tab(session) and after that, you open another tab you must log in again.

[kennylavender]

The API key state doesn't need to be saved between refreshes and new page loads, does it? We can store the apiKeys in a separate reducer that does not get saved to local or session storage.