We're talking about simplicity, but the solution you outline sounds to me at least as complex as what I implemented, if not more... I installed two popular lib

We're talking about simplicity, but the solution you outline sounds to me at least as complex as what I implemented, if not more... I installed two popular libs, tweaked some code in the back, rolled out my front-end, and came up with a robust solution. In my opinion, I wouldn't have saved any time implementing your proposed design if I understand it correctly (especially on the front-end), and I'm not sure about its overall robustness since I don't like at all the idea of periodically polling from the front-end to check the state of the token, as opposed to automatically attempting a refresh on certain response conditions. But that's just me... Regardless, my original point is that one shouldn't be spending much time at all on a commodity feature like this. I wish I could've spent 80% of that time writing real business logic and interfaces. > I'm really not sure that a refresh token on the front end actually provides that much security. Compared to any other mechanism where tokens are revokable (ex: hitting the db), no, it doesn't provide additional security. Compared to non-revokable tokens it provides loads of additional security, without compromising on UX... The refresh token allows for short access token lifetimes (I have them at ~5min, same as Google has on Firebase), while providing the possibility of keeping the user logged in for weeks and having a revokation mechanism if it all goes south.