I've been learning about how to use Keycloak from React (with the Keycloak javascript adapter) with the scenario that Keycloak will provide SSO, allowing the React application to authenticate users with Keycloak, and then use the access JWT provided by Keycloak for bearer authorization with some secured REST api.
I have read lots of discussion on Stack Overflow about where is the best place within React to store the JWTs that Keycloak provides when the user is first authenticated (i.e. context / redux / local storage / cookies). However whatever choice you make about storing a JWT there is always a risk of a XSS attack and the token therefore being obtained by someone else. Because you'll be storing a refresh token as well as the access token, if these are both at risk of being compromised then that would be less than ideal!
Thinking about this I'm wondering if it's actually possible to not ever need to store these tokens in memory at all. I am wondering if the following scenario woud work, and if so (1) is it a better security approach or have I missed something, and (2) are there any disadvantages to it?
The plan is this... When the user first runs our React application we authenticate the user via Keycloak, which might require a login / authentication process. React gets the response back and only extracts and stores from the response the parts that the React application needs to operate, such as some user information and resource roles. But we won't store the JWTs, instead we will instantly discard them.
When the React application subsequently needs to make a rest call it first will re-authenticate the user via keycloak, which will be a seamless / non-visible process from the user's point of view, as they are still authenticated as far as Keycloak is concerned. (On that last point I'm guessing that this is done by a session cookie from Keycloak?). Keycloak will respond to the react application with the tokens, we extract the access token and use it to make the required rest call, and then the React application can discard the token immediately after it has been sent to the server.
Have I come up with a genius idea, or is this seriously flawed???