Should I authenticate user on every request?

Question

I'm working on a social network using Vue.js on frontend, and Node/Express on backend. To store user sessions I'm using Redis. I'm wondering if I should hit Redis everytime user requests content, or maybe there is a way to reduce the load?

Answer 1

You should be using session management to handle information transfer between clients and servers.

Session management essentially involves authenticating a user to initially perform a privileged action, with all subsequent activities being authenticated via 'shared' information eg: cookies.

Asking users to authenticate for each and every action might be considered more secure but will heavily reduce platform usability and overall user satisfaction as a result.

With regards to database load, without seeing the specific application I can't be 100% however I would advise as long as you are logging the last time the session was used, you don't need to write much other information to the database.

Answer 2

Claim-based identity is a good way to reduce the load of authenticating a user.

The simplest way to implement that is to have a first authentication portal that generate signed tokens containing the necessary claims for the user and then have the subsequent call require that token, verify the signature and, trust the claims.

See JWT for a practical implementation.

Answer 3

This is really somewhat off-topic here. We don't know what your application is/does/looks like - so we can't answer the question you asked beyond saying that the functional relevance usually overrides the performance consideration. However since others have already started answering....

Traditionally, http sessions use a random identifier sent to the client which is a key to data on the server. Each time a request requires session data, this is read from the storage. And in most implementations it is subsequently written back to the storage on or before completion of the request. The latter is important to update the timestamp on the session so it can be garbage collected later. Now you definitely want to write the data back to storage when it has changed, but writes are at least 3 times as expensive as reads. So even though you can implement this without impacting delivery of content to the client, not writing unchanged session data back to the storage with every request can have a big impact on capacity.

Using a faster storage substrate can help too.

Then there's the possibility of caching content. Some content needs to be generated afresh each time its accessed. Some content will be near static for a given user, and some content will be the same for all users. HTTP provides mechanisms for advertising this fact to the client and to a reverse proxy. For example, for content cacheable by a specific user, you could incorporate the user id in the Etag - but remember to add a cache-control:private header at the point where it leaves the reverse proxy.

Although you generally can't trust content sent from the client, you could encrypt the data in cookies and use the client for storage - and check for tampering when you decrypt it. Again, this is about capacity rather than performance. And some thought needs to be applied to persistence of the data on the client, even if it is encrypted.

But, except in a very few cases, the performance overhead of sessions, relative to everything else going on in a web page is very, VERY small.

Answer 4

It looks like you are rolling your own authentication or at least a part of it.

I'm wondering if I should hit Redis everytime user requests content,

Yes you have to check the user session against your backend storage on each http request, this a how web servers and web frameworks deal with user sessions, some of them use filesystem to store sessions like Apache and others use relational DB like Django Framework does by default.

In-memory storage like Redis and Memcached is de facto the right choice for such case.

However you can still increase the performance by reducing the number of roundtrips between the client and your server this can be achieved by aggregating data to smaller numbers of request which will decrease in hit frequency on Redis.

Answer 5

No, you don't need to hit Redis on every request is the answer, as you can manage sessions from your backend by issuing a secure cookie. Imagine what would happen if facebook or twitter would hit their db on every request user makes? Additionally to this it would slow down users request.