Securing Single Page Applications with Refresh Token Rotation

How Auth0 helps you securely maintain user sessions and engagement in the era of ITP

Brought to you by @randynasson

Read on

1 Like

If you want to see a few more details regarding that here’s the community announcement for that feature:

1 Like

I still didn’t get one point though. What if the refresh token is stolen but there was not re-use in place?

  1. Legit user (U1) gets AT1 and RT1 for the first time.
  2. Malicious user (U2) steels RT1.
  3. U1 closes the browser while AT1 is still valid.
  4. U2 uses RT1 to get AT2 and RT2
  5. U2 is free to continue forever until U1 logs in again.

There appear to be some serious reservations about this approach raised later by Ping (I am not affiliated with Ping). TLDR the SPA remains vulnerable to ever-evolving exploits which can allow black hats to make use of client-side tokens regardless of refresh token rotation. A sensitive app, perhaps handling personal data or financial transactions, might want to consider using Auth0’s token rotation (which is quite handy IMHO) in a backend service rather than in the SPA.

This post shows up first in my search engine, but a little digging for the Backend for Frontend pattern finds a later post from Auth0 for React SPAs. It does not explicitly mention Auth0’s refresh token rotation, but it seems like it might be appropriate. It would be nice if articles could reflect changes in recommended security practices. Perhaps BFF is no longer considered best practice…