Web storage and progressive enhancement

[rjmk]

In #5, #46 and most discussions online, people seem to default to using local storage / session storage for JWTs, rather than in a cookie. This requires using AJAX throughout the app so that the header can be set from web storage each time. My understanding is that this to prevent cross-site request forgeries (and is essentially leveraging the same-origin policy to do this).

How does this fit with progressive enhancement, where some devices will not support javascript at all?

[nelsonic]

Another _GREAT_ Question from the Wizard! 👍
For the purposes of this micro-example I think its "Ok" to use localStorage.
Let's be honest, everyone is using React these days with zero regard for accessibility.
All the cool kids are way more interested in Shiny New Frameworks than Progressive Enhancement...

However...
In our actual app we are using cookies precisely for backward compatibility and progressive enhancement.
That's why we added the option to JWT2 ... see: https://github.com/dwyl/hapi-auth-jwt2#want-to-sendstore-your-jwt-in-a-cookie

So in conclusion: I would add localStorage to the example in this repo and add a comment informing people that using cookies for storing JWTs is "Ohkay" because you still get all the horizontal scalability and security benefits of using JWTs while saving effort of having to set/get the JWT and add it to headers on each request...

[Jbarget]

@rjmk & @nelsonic

is there a specific reason the JWTS stored in local storage should be sent in the headers or is there anything vulnerable/"wrong" about using https://www.npmjs.com/package/node-localstorage?

[nelsonic]

@Jbarget are you building a "Universal" that requires you to have access to localStorage on the server? If that is your use-case then the node-localstorage module will serve your purpose.
However you will still have to manually send the JWT in the header to send it back to the server in "AJAX" requests... so there isn't much advantage to using a module if all you want to do is get/set the token to/from localStorage ...

[Jbarget]

@nelsonic we'll probably end up setting it in the headers of each request, thanks for the clarity!

[nelsonic]

@Jbarget do you have an objection to storing the JWT in a cookie? (it simplifies your life...)

[Jbarget]

@nelsonic no objection, am i right in thinking it simplifies my life by being able to access the cookies from anywhere in the app as opposed to local/session storage?

[nelsonic]

It simplifies your app because once the cookie is set by the server, all requests sent/received will always contain the cookie. which means you never need to think about it after that point.
By contrast storing the JWT in localStorage means you cannot have non-ajax interaction and you have to remember to SET the auth header for each request you make to the server...

[pscott-au]

Not necessarily though this depends on your toolset. Angular for example allows you to set this once .. i think you can even do with jquery easily.

$.ajaxSetup({
   headers: { 'x-my-custom-header': 'some value' }
});

Another issue with cookies as transport layer for tokens is you are using 2 timeouts and you don't get the benefit of avoiding CORS issues. Cookies complicate access to RESTful web services. Is much easier to construct a curl one liner to access a resource with a token than bundling in a cookie.

[rjmk]

This is issue is being automatically closed as it's more than a year old. Please feel free to reopen it if it's still relevant to your project.