I've been studying front-end developing using ReactJS and back-end using ASP.NET Core and as a first step I've been developing an authentication/authorization (login) system.
I've implemented access token that expires in 1 hour and refresh tokens that expires in 7 days or when a new access token requested (in exchange for the old one and a valid refresh token).
I tried to follow people's advice and use HttpOnly cookies for the refresh token but I've struggled with that, my API would only get the same (old/expired) refresh token from the cookies... so I decided to send the refresh token and access token as json when refreshing my access token.
On the front-end I'm saving both tokens on Cookies (non-HttpOnly) using js-cookie package, BUT I'm encrypting them using AES 256-bit before saving. I've been told localStorage and Cookies (non-HttpOnly) are vulnerable to XXS attacks, but I'm wondering how vulnerable are my tokens since I encrypt them with a private key using a U.S. Federal Information Processing Standard?
As juraj-martinika implied, client-side encryption with client-side stored key cannot make anything more secured. An application level, the challenge with any encryption is not the encryption process, but the key management process. Your encrypted data is as secure as your key storage is. If you store the key in a constant in JS file, or a JS variable, or local / session storage - it's as easy to get your encrypted data as if it were not encrypted at all.
There's a good topic about patterns you might use to implement secure token management: Where to store the refresh token on the Client? See what can help in your case.
If you could use cookies - I would revert to them, but solve the issue with getting outdated ones.