How do you do jwt authentication in a server-side react app?

Question

JavaScript

Where do you put the token sent by the authorization service (like aws cognito) in localStorage in the cookie?
What steps are you taking to protect yourself from Cross-Site Request Forgery, Man-in-the-Middle, Cross-Site Scripting attacks.
As far as I know, such an authentication system is less susceptible to XSRF attacks, since the browser does not automatically set the Authorization token in the request header when making requests.
However, this system is more susceptible to MITM and XSS attacks than the session-based auth system.
In general, I logged in and received a token from aws cognito.
Considering that the application does primary rendering on the server (server-side rendering), what steps to apply next (like best practices)?
I can’t find an established pattern for the server-side react app + token-based authentication case on the Internet?
If you have already done something similar, share your experience, give a link to the repository, to some tutorial. Or at least explain step by step how to do it, what details to take into account? Basically, do something.

Answer 1

I will share my solution. Although I have rails on the server, and react is only on the face. But nevertheless, suddenly it will be useful.
During authorization, the server generates:
- access token
- cookie
- refresh token
which then race between the client and the server.
Refresh token may be missing. Generally speaking, it is only needed to update the access token, and the client adds it to the request only when the access token expires. In this case, the server generates a new access and refresh token.
Cookies are given with the HTTP only mark, that is, the client cannot read them in any way. Cookies are needed only to check the validity of the access token, that is, there are no sessions on them (in general, the application is completely stateless).
The client stores both tokens (access and refresh) in local storage, from where it retrieves them for each request to the server.
Any request from a client containing a valid access token is considered authorized only if it contains cookies corresponding to the token (not matching, but corresponding, that is, encoded according to some algorithm with the access token as a base). Well, if there is a refresh token, then we also look to see if it fits our access token.
Such a scheme, in combination with HTTPS, protects well from XSS or CSRF vulnerabilities (disclaimer: but not from both at once).
Some theory why this works can be read here: www.redotheweb.com/2015/11/09/api-security.html

Answer 2

Only SSL certificates and icons on the server will protect you from MitM.
Where to store? Well, in general, this is not so important, but I would store it in LocalStorage. Xs why, just the left heel says.
Although if yours is not exactly REST, then you can store the token in cookies and send it "according to the classics" (in headers).