Support storing JWT token on cookie (HttpOnly; SameSite=Strict)

[gagarine]

Storing JWT in a browser front end is a bit of a challenge. It's not uncommon to see insecure example such as storing JWT in browser localstorage. Even storing a memory is not safe against XSS and have a lot of drawback (reloading page or opening a new tabs do not works).

A much more secure way would be to transmit the token in a cookie with two options:

• HttpOnly so the token cannot be captured with a XSS as you cannot access such cookie from JS
• SameSite=Strict to defend against CSRF attack

Using a cookie do not mean we use a backend session. The client (browser) is still responsible of the "session" (that's the point of JWT), the client store the JWT token and the backend do not have to keep a session table. But it's not done at the browser level instead of the the JS app level.

Login (auth) from frontend
Query the /auth endpoint with the user credential. The server return a response with a HttpOnly cookie containing the JWT. The browser will automatically attach the JWT cookie in all your future request. No need to manage that on the JS side.

Logout from frontend
To disconnect before the expiration of the cookie lifetime (or the JWT lifetime) you need to query the backend on endpoint that will clear this cookie. Again, this do not mean the backend manage it, simply as the cookie is not accessible from JS you need to query the backend and the response will clear the cookie on the browser.

If needed, implementing logout even when the backend is offline is not hard, create a cookie from JS "please disconnect me". Next time the front query the backend it will send this cookie, the backend can look for it and clear the JSW HttpOnly cookie. Of course this expose the logout endpoint to XSS attack.

Revoke JWT token (logout) from backend
This is currently not implemented in loopback. But using a cookie would not change this. In both case you will need a list of revoked token in the backend.
Yet as the backend is not responsible for session it has no clue about other potential session of a given user. You cannot provide a list of "other device connected". If you want to do that, you certainly want classic session managed in the backend.

[gagarine]

As a side note. Providing a good and straightforward way to auth is key. Yes people can implement their own stuff, but they will certainly make mistakes. This part should be battle tested.

I think well documented and support of JWT on header or cookies and classic sessions (not everybody need to scale that much and session bring a lot of benefit) out of the box would be a big plus. Specially after browsing and see so much insecure implementation.