feat: Move tokens to local storage (M2-11055)

[sricharan-varanasi]

📝 Description

🔗 Jira Ticket M2-11055

Tokens live in sessionStorage, which is per tab. So a new tab always shows the login page even when a session is live next door, closing the tab ends the session, and the tokens sit in DevTools as readable JWTs.

This moves them to react-secure-storage already a dependency, already used for language and library paths. One session per browser, shared by every tab, encrypted at rest.

Changes include:

• Tokens and workspace move to the encrypted store
• lastActivityAt moves to plain localStorage . it is a timestamp, not a secret, and it has to stay readable live because the encrypted store answers reads from a snapshot taken at page load
• Applet private keys stay in sessionStorage
• Logout clears the new locations. Today's sessionStorage.clear() no longer reaches the tokens, so leaving it alone would leave a signed-in session behind
• A session signed in before this ships is carried over, so the deploy is not a logout
• The idle deadline is checked at boot, because closing the browser no longer ends a session
• Activity is now tracked with the feature flag off, so that boot check has a clock to read

🪤 Peer Testing

• Sign in, then open a new tab

  Expected outcome: already signed in, no login page

• Log out, check Application → Storage, then open a new tab

  Expected outcome: no tokens in either store, and the new tab shows the login page

• Change the language, log out, log back in

  Expected outcome: language is preserved

• Sign in on develop, switch to this branch, reload

  Expected outcome: still signed in, and the old accessToken / refreshToken keys are gone from sessionStorage

• Set REACT_APP_IDLE_TIMEOUT_MIN=1, quit the browser, reopen straight away

  Expected outcome: still signed in

• Let the access token expire, then click something

  Expected outcome: the 401 refresh still works transparently

• Log out from the account menu with unsaved changes in the builder

  Expected outcome: the save/discard prompt still appears and the logout completes

• Open two tabs and sign in as a different user in each

  Expected outcome: they converge on one user. This is the intended change, not a bug — see Notes

✏️ Notes

• **Base branch is session-keep-alive
• Not behind enableSessionKeepAlive.- Rolling back logs users out once. Their tokens would be in the new store and the reverted code looks in the old one. Rolling forward is covered by the migration; rolling back is not.

✅ Checklist

Functionality

• The feature behaves correctly in practice and fulfills the intended business purpose
• The implementation accounts for edge cases, avoids subtle logical errors, and handles somewhat rare failure states (e.g. offline mode for mobile, 3rd party being down, etc)

Testing

• Verify there are automated tests added that meaningfully cover critical behavior and failure cases
• Code coverage does not go down as result of this change
• Test suite passes

Security & Data Privacy

• Verify there is no chance we would accidentally log PII to application logs
• Verify this addition does not materially affect our security attack surface, and if so it has undergone security review
• All inputs are sanitized
• New dependencies are well maintained, have significant justification for being added to the project, and are documented in the Curious open source credit page - no new dependencies. react-secure-storage was already in use.

Logging/Monitoring

• Logging is implemented for this change such that you could troubleshoot this feature in production - no logging added. Failures surface as the login page. If we want to see how often the boot check clears a session, that would need adding.
• The change/feature is able to be monitored in production - as above.

Performance

• This change does not introduce n+1 queries or other performance issues within our expected scale (e.g. missing indexes on frequently queried columns, frequently updating tables that are accessed often)

Readability

• All commented out code is removed
• Debugging code including extraneous log lines are removed
• Code is easy to understand through naming and structure; comments explain intent or non‑obvious decisions

Change Safety

• Backend changes are backwards compatible with old clients, or it is well known they are not and a deployment/rollout plan is in place. This include backend changes being compatible with old mobile app versions, as well as applet versioning within Curious.
• Destructive database migrations are rolled out in stages. For example, renaming a column means adding a new column and migrating the existing data to that columns in one deployment. Then monitoring to ensure that field isn’t used, and finally removing that old column in a separate deployment.