Does refresh token requires Expired JWT for creating new access token?

2
votes

In my recent encounter, I was trying to implement JWT Tokens storing securely in the Front-End. What my previous approach is to store access_token as well refresh_token in sessionStorage which is vulnerable to XSS attacks. Now, when access_token expires, I'll call for /refresh endpoint to obtain a new access_token. Here I'm passing expired JWT into Authorization Header. The idea here is to protect your refresh endpoint and make sure only logged-in users ask for the token.

After that, we change the implementation to prevent XSS and CSRF. And followed this, LocalStorage vs. Cookies

which recommend, store your access token in memory, and store the refresh token in the cookie. so from FE, we can't access the cookie.(HTTPOnly cookie) and access_token

Now the real challenge is when the page refresh, we lose access_token as we stored it into in-memory, and API asks for Expired JWT token.

So my question is, does /refresh endpoint requires an expired JWT token, or is that a good practice to use the refresh token without JWT token.

1
angularoauth-2.0jwtaccess-tokenrefresh-token

1 Answers

0
votes

Access token in memory and refresh token in a cookie is a respected option for SPAs. There is an emerging standard called TMI BFF that is worth keeping an eye on, since it is expected to formalise the best practice.

The cookie should have properties in line with these:

  • HTTP Only
  • Secure
  • AES 256 encrypted
  • SameSite=strict

Use of the 'auth cookie' cannot also require an access token, since these use cases will not work for the client:

  • User refreshes page
  • User opens new browser tab

One option is to send an anti forgery token as well as the cookie, as described in the OWASP Double Submit Pattern. In the browser the anti forgery token would need to be stored in local storage in order for the above use cases to work. This is not 100% XSS safe, but nor is anything else in the browser.

Some code of mine uses this approach as part of doing the OAuth work in a back end API:

Like quite a few people I am interested to see how SPA best practice evolves. It is worth mentioning also that some people recommend proxying all API calls via a 'back end for front end':

  • It is currently considered more secure
  • But it also adds complexity and perhaps reduces capabilities in some areas