Cookies vs LocalStorage

[thombruce]

When we authenticate a user, we provide a JWT. Currently, this is manually stored in LocalStorage by the consuming application...

This has some vulnerability over cookies, but is good practise because:

• It is similar to how external apps will be required to handle JWTs. They are detached from the origin, so cookies are non-viable.
• The end user has greater control over what is done with the JWT - they may use cookies if they wish.

Cookies vs LocalStorage vs SessionStorage

Here's a solid writeup of the three options: https://wpreset.com/localstorage-sessionstorage-cookies-detailed-comparison/

SessionStorage is an interesting third option: It clears its cache when the browser window is closed (when the page session ends). It, like cookies, can also have an expiration time set (localStorage cannot).

This means that:

• Cookies are persistent

• LocalStorage is persistent

• SessionStorage is temporary

• Cookies are timeoutable

• LocalStorage is permanent

• SessionStorage is timeoutable

What could we do with Cookies?

Usage of cookies would take the responsibility out of the hands of the developer to implement an interceptor ensuring that every request provides the JWT in its Authorization header...

I think it's well worth looking at implementing them as an option, for the convenience of the end user.

[thombruce]

Tech	Persistent	Timeoutable
Cookies	yes	yes
LocalStorage	yes	no
SessionStorage	no	yes

Persistent

• Desirable for maintaining RefreshToken between sessions
• Essential for "Remember me" implementations

Timeoutable

• Useful for discarding of tokens after their expiry

Suitability

RefreshToken: Cookie or LocalStorage where "Remember me" is desired

AccessToken: SessionStorage, maybe; otherwise in memory - timeoutable cookie also acceptable at a push

Is this important, or even relevant?

If we create a Credible.js plugin... maybe. Decisions about how we handle tokens will be very relevant there. My preferred approach presently is: RefreshToken:LocalStorage, AccessToken:InMemory... which is entirely left to the end developer.

I don't think it's worth implementing cookies at this time. The end user can always set them using JavaScript. The question is whether Credible should support these, as cookies are sent automatically to the server...

Closing for now as this is non-essential, and I have no reason to assume that it will even be desirable.