Sync IDAPI and Okta session refresh timing

[raphaelkabo]

What does this change?

Applies some bugfixes on top of code commited in https://github.com/guardian/frontend/pull/25306.

The original problem we are solving is that as part of the Identity migration to Okta, we want to keep IDAPI and Okta behaviour around sessions in sync. IDAPI sessions are being refreshed if they're older than 30 days on Frontend, so with this change, Okta and IDAPI sessions will be refreshed simultaneously, ensuring they're kept in sync.

As @mxdvl suggested in https://github.com/guardian/frontend/pull/25306#discussion_r937843037, we now partly use the internal storage API built-in expiry method to check whether the cookies need to be refreshed. Rather than renaming our localStorage value, however, we will still use the old value key, but get the code to run if the record has expired, or if the record is invalid or missing.

Does this change need to be reproduced in dotcom-rendering ?

• [X] No

What is the value of this and can you measure success?

This keeps IDAPI and Okta sessions in sync for signed-in users on the Guardian frontend, which is necessary to keep parity between the legacy and new Identity systems during migration and ensure users don't get logged out unexpectedly.

Checklist

Tested

• [x] Locally
• [x] On CODE (optional)

[raphaelkabo]

Pleased to report the flow works on CODE, showing a JS-initiated 302 redirect when the localStorage value identity.lastRefresh is absent, or is artificially set to a time less than 30 days away.

[raphaelkabo]

@coldlink Yes, it all works as expected with an Okta session!

[prout-bot]

Seen on PROD (merged by @raphaelkabo 12 minutes and 35 seconds ago)

• Check your changes on www.theguardian.com ✔️
• Keep an eye on the deploy dashboard 📉

[coldlink]

I think that there is some unnecessary work here, as @guardian/lib’s storage has its built-in expiry mechanism.

Is there a risk that by using the same key with a different shape of data, all users will automatically get a refreshed session? The old behaviour stored a value as string, whereas the new one parses a JSON, and therefore will always return invalid data for legacy values.

I think you might want to use a new key and leave the legacy one untouched. This means you can also forgo the check for freshness and rely on the key being anything but null.

That's not a bad idea to use both keys. We decided to keep the same key in this case though, as we would've thought to remove the old key.

So the reason we thought to avoid a different key was that would've caused all logged in users to refresh their session, which going by the numbers from last week, would've meant we would've rate limited ourselves again.

So we decided to be safe to use the same key, and add the additional expiry logic here based on both the value and the expiry functionality. So that it was backwards compatible.

Your idea works well too!

Most of this is temporary work anyway, when migrating dot-com and making Okta the default, sessions will get refreshed in a different way anyway, namely the session will get refreshed when retrieving a new OAuth access token from the OAuth/OIDC Okta API.

[mxdvl]

So we decided to be safe to use the same key, and add the additional expiry logic here based on both the value and the expiry functionality. So that it was backwards compatible.

I’m surprised it backwards compatible at all, considering it’s using JSON.parse(), and the value will be undefined.