21

The Setup

We’re building a PWA (progressive web app). The main components are the app shell (SPA) and the API. The REST API will supply the data needed for the app, while the SPA will handle the rest (as per Google recommendation).

The Problem

Authentication of the end-user seems problematic because the web browser needs to be accounted for. We want the user login to persist through closing down the browser. We’ve done the research about the possible ways of going about it, however we’d like to ensure that we’re not going in the wrong direction.

Solutions we’ve considered

Session based authentication - the user sends username and password to /accounts/auth and receives a HTTP only cookie with the session ID. The session needs to be stored in a database or Redis. The issue with this option is that cookies are automatically sent by the browser therefore we need a CSRF protection in place. Using the Synchronizer Token Pattern a new token would be generated every time a state changing request has been made e.g. POST. This means that the application needs to supply a CSRF token with every request so that the PWA can send it via AJAX. We determined that it’s not ideal as the user can send multiple post requests in a quick succession making some of them fail and resulting in a bad user experience.

We could also use this method without the CSRF by limiting the CORS policy to same domain and adding a header requirement which technically should stop all CSRF, however we're unsure how secure it would be.

JWT token based authentication - the user sends username and password to /accounts/auth and a new JWT token is issued. The JWT then needs to be stored in localstorage or a cookie. Using localstorage means that JWT is XSS vulnerable and if the token is stolen, an attacker can impersonate the user completely. Using cookies we will still have a CSRF issue to resolve. We considered a double submit cookie method but the CSRF would only refresh every time the JWT is reissued which creates a window for the attacker to find out what the CSRF is. It is not clear which method is best to use.

Session based authentication + JWT token authentication - the user sends username and password to /accounts/auth, a session is created, a HTTP only cookie is set in the browser and a JWT token is sent back to the user. The PWA can authenticate requests with the JWT and whenever the JWT expires the app calls /accounts/auth again to acquire a new one. The /accounts/auth endpoint would still need to be CSRF protected, however the impact of it on usability would be minimised.

There seems to be a large amount of articles claiming that localStorage is insecure and shouldn't be used so why are high profile organisations like Amazon still recommending it? https://github.com/aws/amazon-cognito-auth-js - this SDK uses localStorage to store the token.

Community
  • 1
  • 1
Lukasz J
  • 336
  • 2
  • 6
  • JWT tokens are the way to go. You are using HTTPS so XSS is far less likely, My recommendation is either Auth0 or AWS Cognito for an Identity Service. That is how I handle authentication in my PWAs. – Chris Love Feb 02 '20 at 03:14
  • did you ever find a good solution to this? – Just a coder Mar 25 '21 at 05:14
  • 1
    Yes, don't use JTW with localStorage if you want your webapp to be secure. Using it with cookies is just like a session with extra steps. Good old HTTP only cookie with a session ID is the way to go. – Lukasz J Mar 26 '21 at 09:15

2 Answers2

0

You don't need to generate new CSRF token each time a client make a request. It's much easier to use a scheme like token = hash(id + secret + current_day). You only need to update it once a day, or even employ mixed scheme (if the token is invalid today, but is okay for the previous day, the server accepts the operation and returns new token in a predefined header for client to renew it). You may also use the cookie as an id, making the token totally stateless and much easier to check, no need to store them in the database.

Sergey 'Twirl' Konstantinov
  • 81
  • 5
  • I would argue that CSRF token is still required if the author wants to protect the flow from replay attacks. The suggested token generation in this answer is not protecting from these replay attacks, since an already generated token can be easily replayed back. – galaxy Mar 17 '21 at 04:00
0

Here is how I look at it.

JWT token authentication : with this approach, you can always use a time-bound token with its expiration set to say 2 hours or something?

Or another approach would also be to try and see how you could use some of the approaches the Credentials Management API suggests for example, auto-sign-in of users whenever they come back.

Stuff like 2-step verification with OTPs for instance; for very important features in your web app can be a choice. In this case basic stuff are tied to whichever one time authentication method you have.

Actually, you can also use user-defined pins or short codes (seen a lot in banking apps) to grant access to some features in your web app.

Hope this helps, or sparks some ideation.

Maye Edwin
  • 49
  • 5