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](https://developers.google.com/web/fundamentals/architecture/app-shell)).

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.