API Authentication best practices for custom REST service

Question

I'll try to keep this as framework-independent as possible, but I will refer to the frameworks I'm personally using to give some context. Also, I'm sorry, but this is a long question.

Context: I'm working on an online platform. It is made of two different servers, a "backend" which serves a public REST(ish) API (at, let say api.example.com), and a "frontend" using Sapper (Svelte) with ssr (example.com). The latter basically serves an API client.

Obviously, some endpoints are related to a specific account and therefore need authentication. As far as I know, there are two different approaches to this, which have different vulnerabilities:

• session authentication (cookie), which is vulnerable to CSRF attacks
• token authentication (header), which is vulnerable to XSS attacks (usually the token is saved in localStorage)

Using session authentication directly with the backend server is quite difficult because the page is served by another server, and generating/verifying tokens is not that easy, if not impossible.

Common solution: People seem to have real angst with using localStorage, and I get it because an attacker can use XSS to steal the token and impersonate a user. Therefore the preferred solution seems to be the following:

• store the token in an httpOnly cookie
• every request goes to example.com/api/[...]
• these endpoints act as a "proxy", take the token from the cookie and put it into an Authorization header to forward the request to the actual API at api.example.com

The thing is, since authentication is now made with cookies, (at least at the "frontend" level), CSRF attacks are a problem again. Of course, now it's easier to deal with it because it's all a responsibility of the frontend server, and there are already existing CSRF middlewares for express and polka.

However, my point is that CSRF tokens and CSRF protection, in general, are useless in the presence of XSS vulnerabilities, and therefore, even if the token is not directly accessible by JS, the platform is still vulnerable. XSS protection is still critical, and we gained nothing by doing this. On the other hand, now the frontend server is "busy" for every backend request, and it destroys one of the advantages of having different servers.

What I was thinking of doing is basically sticking to the localStorage approach, but without actually using localStorage, in order to take advantage of ssr. The idea is that I can use the Sapper middleware to read the cookie and store the token in the Sapper session:

sapper.middleware({
    session: (req, res) => ({
        authorization: getCookie(req, 'supersecret') // get supersecret cookie from request
    })
})

For those of you who don't know Sapper, session in this context is basically a piece of memory that is initialized by the server and shared with the client. Making the cookie httpOnly doesn't really serve a purpose, because the value is still accessible by JS using the session store. But since the server has now access to the token during page reload, we can now take advantage of ssr (how useful is to render on the server private info got from an API is debatable, but why not?).

The question is: this is obviously not a standard approach, and therefore I don't understand the problems it may cause (or already has), as I can't seem to find any downside to this. What am I thinking/doing wrong? Is this actually ok to do?

P.S.: the "frontend proxy" is mandatory if I want to use API keys and limit the API usage, but I don't think I really need it (correct me if I'm wrong)

Answer 1

So what you really want to do is the following:

1. doing stateless authentication and authorization to increase scalability

   You need to store the session data on the client. You need to send the relevant part of the session data with each request. You need to add a hard to guess secret to the session data that can be used to verify user identity. You need to check this secret on the server for each request.

2. avoid session theft via XSS

   You need to move at least your secret to a HTTP-only cookie, so nobody can steal it with javascript code running on the client.

3. avoid session usage via CSRF

   You need another hard to guess secret which can be used to verify user identity or which is unique for the actual session. This secret can be known by the javascript code running on the client and it must be sent with each request in a non-cookie way. You need to check this secret on the server for each request, but it is not necessary to generate it on the server if running client side javascript code is a requirement to use your application.

A possible way to implement these is moving the entire session to an encrypted signed JWT created and modified by the server and stored on the client in a HTTP-only cookie. You can add the user id, the session id and the expiration date to this session. You verify its signature for each request and you check if the session id is not on a blacklist or if the session is not expired. You renew the keys you use to encrypt and sign the JWT periodically e.g. each month. You send the encrypted session id in a HTTP header too and compare it to the one you get in the JWT for each request.

A less secure and from server perspective a less demanding implementation is storing only the user id, expiration date and session id in the token only signed but not encrypted. The rest of the sesssion can be stored in the localstorage or sessionstorage and it can be read and modified by the client not just by the server.

An even less secure way is sending only email and password with each request instead of signing stuff.

Be aware that this is just my opinion, not some industry standard and I recommend using an existing well tested product instead of doing your custom security solution.

Answer 2

A LocalStorage (or MemoryStorage if you wish) is never a good solution for prod purposes. If you're just doing a demo or showcasing a change only then should you stick to a LocalStorage memory caching. Use Redis for a dedicated caching service.

It is upto you whether you wish to utilise a token based system or a session based system to ensure congruency between server-client. You could take in specific parameters in the request to ensure better identity (I.P. location, shorter expiry time, etc.)

Set up an https certificate to make XSS attacks to have lesser efficacy. Utilise server generated tokens for ensuring session based CSRF attacks are harder to perform ( generated token can be asymmetric or symmetric type).

Answer 3

When in doubt look at how experts handle the issue (unless your approach is novel). Banks for example have tight security with short session lifespan therefor the user will have to login again every x seconds, so even if an attacker stole the first session key he will not have the new session after you re-authenticate (assuming that he doesn't have a contentious method of stealing the new session key) it adds a hurdle but is not the ultimate defence since that doesn't exist. Maybe you can also look at asymmetric encryption using private and public key pairs, or unique code generators that the front end must always generate a new pass-phrase based on an encryption key that both the frontend and the backend have and you have to send that every evolving cipher with every request, the attacker will not be able to get through this security measure unless he has access to the front end code, again not an ultimate defence but an extra hurdle for the attacker. A fancier approach is to use machine learning to identify typical user behaviour patterns and flag out of the ordinary activity, and send an alert/re-authenticate if confidence level is low in the current activity session.