1

I have seen sites like twitter send the auth token back to their server in the http header, as Bearer authorization, as people recommend, but I can't find where do they actually store it inside the browser. Neither in the cookies nor in the local storage. Can someone explain me how they do it or at least what is the best practice to follow.

Riccardo Merlo
  • 21
  • 4

2 Answers2

1

There are different methods but in general if your JWT is acting as a sort of authorization, you want to keep it out of reach of external Javascripts in order to protect the JWT.

This can be done through the use of a cookie that is scoped to your domain and httpOnly in order to protect against CSRF and XSS. This option has the added value of persisting through sessions until the eventual expiration of the cookie. This has the drawback of not having the ability to extract data that may be needed for displaying on the UI. This drawback can be subverted by having an authed endpoint that returns the user data for the currently authed session.

Another option is if you need access to some of the contents of the jwt on the frontend, you can store it in memory (such that it's only accessible to your application code by encapsulating it) and sent along as a header in your authed http requests. The big drawback here is that the jwt would not be persisted across page reloads.

dillon
  • 721
  • 6
  • 16
  • What do you mean by authed session? Do you read the httponly cookie sent to the endpoint? – Riccardo Merlo Apr 16 '20 at 20:22
  • 1
    The authed session meaning the value in the httpOnly cookie with the jwt, yes. That would be considered the "authed session". If you've authenticated, and your server sets the httpOnly cookie, you can make a subsequent request to an endpoint like GET `api/sessions/current` or something more RESTful that will return necessary data about that user that the Frontend is reliant on. – dillon Apr 16 '20 at 20:30
  • Ok, so this means every page refresh the Client will send a request to the server to get the login status & data? – Riccardo Merlo Apr 16 '20 at 20:45
  • You can store the data in local storage if it's not private information, so you don't have to re-request for that data. On login, you can set the httpOnly jwt and pass back the user data as a response. That user data can be stored in session or local storage to persist across page refreshes. When you're making authed CRUD operations on your backend, the httpOnly cookie will be used as the authorization mechanism. – dillon Apr 16 '20 at 20:53
  • What if I change the data stored in the local storage? For this specific reason I thought to always request the server for the user data. Otherwise I wouldn't be able to verify the integrity of the data stored in the local storage even if this data is not private. – Riccardo Merlo Apr 16 '20 at 21:03
  • 1
    That's a great reason to make the request upon reload of the page. It was just an alternative to store in local storage. I'd agree and would reach for the option that provides the highest level of data integrity. – dillon Apr 16 '20 at 21:20
0

Most popular way is store token in local storage. Here you can find more detailed info. Please share your code and show us, what did you try.

Kamil Naja
  • 6,267
  • 6
  • 33
  • 47
  • This can be problematic if the site is vulnerable to XSS as an attacker can compromise a jwt quite easily if it's stored in local storage. Session hijacking is something that needs to be considered when thinking of your auth mechanism. – dillon Apr 16 '20 at 20:03
  • 1
    The reason this is so common is because it's a very simple mechanism. The issue is that it widens your sites attack vector. Here is a related post (though in the context of reactjs) that applies https://stackoverflow.com/questions/44133536/is-it-safe-to-store-a-jwt-in-localstorage-with-reactjs – dillon Apr 16 '20 at 20:05