[Hybrid] PWA Kit should have a mechanism for replacing the access token when a SFRA login state is changed

[shethj]

On login, PWA Kit stores several properties such as the access token and refresh token. Once an access token is present, PWA Kit will continue to use the same access token until it expires, where it will then use the refresh token to acquire a new access token.

In hybrid sites, SFRA logins are handled by plugin_SLAS. However, plugin_SLAS only has the ability to modify the refresh token on login. Since it is unable to modify/revoke the access token directly, situations can occur where a user with a PWA Kit access token navigates to SFRA, logs in via SFRA, then goes back to PWA Kit where their login status would remain unchanged since the access token from before the SFRA login will continue to be in use.

For PWA Kit to know whether plugin_SLAS has changed a user's login state, PWA needs to know when the refresh token changes.

Description

• All PWA Kit login scenarios (guest, registered, and refresh token) should store the refresh token in a 2nd property in addition to cc-nx-g / cc-nx
• On every request to SCAPI, before we check for the existence of an access token, run a check comparing the value of the refresh token stored in cc-nx-g / cc-nx with the 2nd copy. If the values are equal, continue to use the access token. If the values are different, throw out (or revoke) the existing access token and trigger a new login using the refresh token stored in cc-nx-g / cc-nx

Types of Changes

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Documentation update
• Breaking change (could cause existing functionality to not work as expected)
• Other changes (non-breaking changes that does not fit any of the above)

Breaking changes include:

• Removing a public function or component or prop
• Adding a required argument to a function
• Changing the data type of a function parameter or return value
• Adding a new peer dependency to package.json

Changes

• Implemented hasSFRAAuthStateChanged(...) to compare refresh_token keys between SFRA and PWA
• Moved constants from commerce-api/auth.js to commerce-api/constants.js for shared usage
• updated auth.js with a getter function for isTokenValid to combine token validation and sfra login state changed checks
• Updated if conditions to use this.auth.isTokenValid from auth.js instead of using the util function isTokenValid(...)

How to Test-Drive This PR

Checklists

General

• Changes are covered by test cases
• CHANGELOG.md updated with a short description of changes (not required for documentation updates)

Accessibility Compliance

You must check off all items in one of the follow two lists:

• There are no changes to UI

or...

• Changes were tested with a Screen Reader (iOS VoiceOver or Android Talkback) and had no issues
• Changes comply with WCAG 2.0 guidelines levels A and AA
• Changes to common UI patterns and interactions comply with WAI-ARIA best practices

Localization

• Changes include a UI text update in the Retail React App (which requires translation)

[bfeister]

LGTM

[kevinxh]

expires is for cookies, it doesn't work for localstorage

[vcua-mobify]

Dumb question: What does this look like if both the original and copy are stored in local store? They're stored separately still correct? Otherwise, since they have the same name, one would override the other.

[shethj]

@vcua-mobify The original and copy would both point to LocalStorage only in case of standalone setups in which case the token values will be the same and hasSFRAAuthStateChanged does not check values it only compares the keys. which again will be the same in this case. So we should be good.

[vcua-mobify]

I think we want to be actively comparing the values since we open ourselves up to an edge case if we just look at the keys.

On a PWA Kit only environment (the only scenario where both point the original and copy are in local store) I think it's fine if we compare the value with itself or if the copy overrides the original since they should never diverge in this scenario in the first place.

On a hybrid environment, the original will be in the cookie store while the copy is in local store so we should have different values then.

[kevinxh]

what happens if user stays on PWA kit and keeps refreshing the page? (no SFRA)

It seems to me hasSFRAAuthStateChanged always evaluate to true and PWA will always use refresh token, and never re-use access token?

[kevinxh]

if cookie doesn't exist, this function should return true

[kevinxh]

also, let's add a test case for when refresh cookies does not exist.

[shethj]

what happens if user stays on PWA kit and keeps refreshing the page? (no SFRA)

I'm guessing by no SFRA you mean in case of a PWA Kit only setup:
In this case, the storage and storageCopy would both be pointing to LocalStorage and refreshTokenKey === refreshTokenKeyCopy so hasSFRAAuthStateChanged will be false

If by no SFRA you mean Hybrid Setup but the user hasn't yet navigated to SFRA,
Then storage will point to CookieStorage and storageCopy will point to LocalStorage in which case PWA Kit itself will write the refresh_token in both places. And if the user keeps refreshing on PWA kit without navigating to SFRA again refreshTokenKey === refreshTokenKeyCopy so hasSFRAAuthStateChanged will be false

[vcua-mobify]

Sorry to be a stickler but why are we only comparing the keys and not the values of the refresh token?

By comparing just the keys we open ourselves to the following edge case in hybrid:

1. User signs in as a guest via SFRA
2. User goes to PWA - this sets an access token PWA side
3. User adds something to their cart via PWA
4. User goes back to SFRA, logs in (gets a cc-nx) then logs out (goes back to cc-nx-g)
5. User goes back to PWA

In the above, SFRA has changed the login state a couple of times but settled on a cc-nx-g when transitioning to PWA. If we compare only the keys, in this case we are not discarding the old access token.

[shethj]

Updated hasSFRALoginStateChanged(...) to compare values if refershToken keys are same.

Thanks @vcua-mobify for catching that 🎉

[vcua-mobify]

Dumb question: What does this look like if both the original and copy are stored in local store? They're stored separately still correct? Otherwise, since they have the same name, one would override the other.

[vcua-mobify]

Sorry to be a stickler but why are we only comparing the keys and not the values of the refresh token?

By comparing just the keys we open ourselves to the following edge case in hybrid:

1. User signs in as a guest via SFRA
2. User goes to PWA - this sets an access token PWA side
3. User adds something to their cart via PWA
4. User goes back to SFRA, logs in (gets a cc-nx) then logs out (goes back to cc-nx-g)
5. User goes back to PWA

In the above, SFRA has changed the login state a couple of times but settled on a cc-nx-g when transitioning to PWA. If we compare only the keys, in this case we are not discarding the old access token.

[vcua-mobify]

Thanks for addressing the edge case @shethj. This PR looks good to me