Sami

Strongly second the backend-for-frontend suggestion. I moved a single-page app to it after the third round of browser privacy changes broke silent renewal again, and the thing that convinced me was that it stopped being a moving target.

Token handling in the browser has been rewritten roughly every eighteen months for years: implicit flow, then authorisation code with a challenge, then silent renewal in an iframe, then refresh tokens with rotation. Each migration was work. A session cookie against your own backend has not changed at all in that time because it never depended on third-party cookies in the first place.

The cost is a server-side component you now run, and it does not suit a purely static deployment. If you already have a backend, it is much less work than it sounds — it is a proxy plus a session store.

The truncation case is worth taking seriously if you are storing the token in a cookie, because it is silent and size-dependent.

Browsers cap cookie size, and if you put a token with a large payload in one — several roles, a list of permissions, a profile — you can go over the limit. What happens then depends on the browser and it is not always a clean rejection.

The symptom is characteristic and confusing: it works for users with small payloads and fails for users with many roles or long names. So it passes every test and breaks for the account with the most permissions, which is usually somebody senior.

If that sounds like your situation, shrink the payload. A token should carry an identifier and a small number of claims, not a copy of the user record.