feat: Refresh access tokens on 401 errors

[impactmass]

Resolves #350
Type: feature

Issue

Get a new access token from Hydra.

Solution

• Setup of a CORS-enabled endpoint in Identity provider that talks to Hydra to retrieve new tokens (feat: Add a CORS-enabled endpoint for token refresh in Hydra plugin reaction#4743)
• Update Apollo link setup to catch 401s
• Use endpoint created within IDP in apollo-client to get new tokens
• Write new tokens received to cookie

Breaking changes

None

Testing

1. Start Starterkit on this branch, and Reaction API on this PR feat: Add a CORS-enabled endpoint for token refresh in Hydra plugin reaction#4743
2. Run Hydra on master. Set this ENV in the docker-compose yaml before starting the service: ACCESS_TOKEN_LIFESPAN=1m. This will reduce the wait time. The tokens will expire in 60s.
3. Load up a page. Leave it for a while for the token to expire.
4. Return back to the page, and browser (e.g make a view a product, pause, then come back to add to cart. Try different approaches).
5. Note if there are any token denied errors or 401s. There should be none

[impactmass]

Added @mikemurray as primary reviewer.
@aldeed I added you to this PR because of changes around the cookie-session setup (now that it gets changed in the browser when token refreshes). I'd like your comments there.

[aldeed]

@impactmass See some comments on the diff

[aldeed]

Why is a cookie needed here? Can you add these three config values to the public app config instead? publicRuntimeConfig in next.config.js

changes made. Readme added for cookie issue

[impactmass]

@aldeed @ticean @rosshadden these proposed changes to how we use cookies need a few more eyes to review. I've written this readme doc, per Eric's earlier review, to list the changes and will like comments from you all.

[rosshadden]

Looks good to me @impactmass.

[ticean]

Hi @impactmass. Thanks for the great writeup. Switching to an insecure cookie (not HTTP-only) is a blocker. Especially with a refresh token in it. Refreshes don't expire. All the conventional wisdom suggests that it shouldn't be stored in the browser ^{[citation needed]}.

I understand the impact on user experience with short-lived access tokens. Can we take some intermediate, secure solutions to move toward the desired state? For example, a full redirect flow would be possible with the tradeoff that it's more intrusive on the user experience because it kicks out of the SPA. Would that be acceptable enough for now to move things forward until we get something like a tested, iframe solution going? Are there other intermediate (or permanent) solutions that would work? Have suggestions @aldeed?

[impactmass]

Based on the discussions from this review (especially the case around using not HTTP-only cookie, I'm adding token "refresh flow with redirects only" in #399 (almost finishing up).
This can serve as a first solution while we figure out the implementation for in browser refresh (new issue here #400). I'll close this PR, but keep the branch up.