STCOR-671 handle access-control via cookies

[zburke]

Handle access-control via HTTP-only cookies instead of storing the JWT in local storage and providing it in the X-Okapi-Token header of fetch requests, and proxy all requests through a service worker that performs Refresh Token Rotation as needed to make sure the access-token remains fresh.

Notable changes:

• Fetch requests are proxied by a Service Worker that intercepts them, validates that the Access Token is still valid, and performs token rotation (if it is not) before completing the original fetch.
• Sessions automatically end (i.e. the user is automatically logged out) when the Refresh Token expires.
• Access control is managed by including an HTTP-only cookie with all requests. This means the Access Token formerly available in the response-header as X-Okapi-Token is never accessible to JS code.

Replaces #1340. It was gross and I really don't want to talk about it. Let us never mention it again.

• Requires STCON-138 handle access-control via cookies stripes-connect#223
• Requires STSMACOM-714 handle access-control via cookies stripes-smart-components#1397
• Requires STRWEB-99 bundle stripes-core's service-worker.js stripes-webpack#125

Refs STCOR-671, FOLIO-3627

[github-actions]

Jest Unit Test Statistics

125 tests  +48   125 ✔️ +48   17s ⏱️ +4s
  15 suites +  2       0 💤 ±  0 
    1 files   ±  0       0 ❌ ±  0 

Results for commit a17f72f. ± Comparison against base commit bbc722d.

This pull request removes 1 and adds 49 tests. Note that renamed tests count towards both.

createOkapiSession clears authentication errors ‑ createOkapiSession clears authentication errors

createOkapiSession clears authentication errors and sends a TOKEN_EXPIRATION message ‑ createOkapiSession clears authentication errors and sends a TOKEN_EXPIRATION message
handleServiceWorkerMessage handles same-origin events on RTR error, ends session ‑ handleServiceWorkerMessage handles same-origin events on RTR error, ends session
handleServiceWorkerMessage handles same-origin events on RTR, dispatches new token-expiration data ‑ handleServiceWorkerMessage handles same-origin events on RTR, dispatches new token-expiration data
handleServiceWorkerMessage handles same-origin events only handles events if data.source is "@folio/stripes-core" ‑ handleServiceWorkerMessage handles same-origin events only handles events if data.source is "@folio/stripes-core"
handleServiceWorkerMessage ignores cross-origin events mismatched event origin ‑ handleServiceWorkerMessage ignores cross-origin events mismatched event origin
handleServiceWorkerMessage ignores cross-origin events missing event origin ‑ handleServiceWorkerMessage ignores cross-origin events missing event origin
isLogoutRequest accepts logout endpoints /authn/logout ‑ isLogoutRequest accepts logout endpoints /authn/logout
isLogoutRequest rejects unknown endpoints ‑ isLogoutRequest rejects unknown endpoints
isOkapiRequest accepts requests whose origin matches okapi's ‑ isOkapiRequest accepts requests whose origin matches okapi's
isOkapiRequest rejects requests whose origin does not match okapi's ‑ isOkapiRequest rejects requests whose origin does not match okapi's
…

♻️ This comment has been updated with latest results.

[github-actions]

BigTest Unit Test Statistics

    1 files  ±0      1 suites  ±0   10s ⏱️ ±0s
271 tests ±0  265 ✔️  - 1  6 💤 +1  0 ❌ ±0 
274 runs  ±0  268 ✔️  - 1  6 💤 +1  0 ❌ ±0 

Results for commit a17f72f. ± Comparison against base commit bbc722d.

This pull request removes 5 and adds 3 tests. Note that renamed tests count towards both.

      equal to check email label in english translation
      equal to check email precautions label in english translation
      equal to sent email precautions label in english translation
Chrome_118_0_0_0_(Linux_x86_64).Forgot username form test ‑ Forgot username form test check email status page tests should have the header with an appropriate text content
Chrome_118_0_0_0_(Linux_x86_64).Forgot username form test ‑ Forgot username form test check email status page tests should have the paragraph with an appropriate text content

Chrome_118_0_0_0_(Linux_x86_64).Forgot username form test ‑ Forgot username form test check email status page tests should have the header with an appropriate text content
      equal to check email label in english translation
Chrome_118_0_0_0_(Linux_x86_64).Forgot username form test ‑ Forgot username form test check email status page tests should have the paragraph with an appropriate text content
      equal to check email precautions label in english translation
Chrome_118_0_0_0_(Linux_x86_64).Forgot username form test ‑ Forgot username form test check email status page tests should have the paragraph with an appropriate text content
      equal to sent email precautions label in english translation

This pull request skips 1 test.

Chrome_118_0_0_0_(Linux_x86_64).Session timeout test ‑ Session timeout test clicking settings should redirect to login with session timeout message

♻️ This comment has been updated with latest results.

[NikitaSedyx]

@zburke should we have so much logs here? - if there are removed in production bundle, it's fine to have them

[zburke]

@zburke should we have so much logs here? - if there are removed in production bundle, it's fine to have them

No, logs should be purged. I forgot to remove them when I moved this from "draft" to "ready". I wanted to use the stripes logger in service-worker.js, passed in from App.js through to registerServiceWorker and into the service-worker itself, but it didn't work. I could call logger.log() in the register function and it would work, but inside the service-worker none of the logger's functions were findable on the object. It was so weird.

[steveellis]

I'm not completely understanding what problem this would solve. Why would "several fetches trigger rtr in a short window"? Is it that lots of requests can arrive in the filter at once since the browser of course processes 8 or 10 at once in separate threads normally. If this is firing every time that happens, things might not work very well...

The reason I ask is because of the single use feature of the RT. You can only POST a single RT once. If you post it twice (say if two requests send at roughly the same time or in close proximity), mod-at will consider this a "leaked token" and log the user out of all of their devices.

I think this means that the RT should only be sent when it needs to be sent or just lazily in the background, which is at some interval that is less than the AT TTL. Occasionally it will result in a 401 because the RT expired.

[steveellis]

I think what we want is for the service worker to not be too ambitious. He's lazy after all. But his laziness is a virtue. If he does his work well, in his lazy way, he doesn't need to be ambitious. Ambitious would mean that he's trying to solve every problem that comes his way just as soon as these problems arrive. But he's not like that. His reliability is how he makes up for his lack of ambition. He takes care of everything eventually. And because of that he doesn't need to be ambitious.

But why does he care about every request that comes his way then?

Only because just in case, something unforeseen has caused a problem that is outside of his control, he can send the user to the login screen, which is after all, much better than the alternative which would never to be sent anywhere at all.

[zburke]

Simultaneous fetches are common, e.g. the ui-users landing page fires several requests to fill in the values on its search form: patron groups, departments, tags, custom fields. The browser handles these in parallel streams, but as you pointed out, the RT is single use, so we need to guard against the situation where an AT has expired and then several requests arrive all at once. We need to let the first one through and force the others to wait.

As to laziness, this code goes through great pains to be lazy, i.e. to implement just-in-time RTR, passing along requests as-is when it believes the AT is valid. But that's as lazy as we can be: the nature of a fetch event listener is that it hears about every fetch, so we need to handle all the surrounding edge cases: the expiration data in storage said the AT (or RT) was good but it turned out to be bad, here are five simultaneous fetches after a period of inactivity during which the AT expired, etc.

A timer-based approach is simpler, and doesn't need to involve service workers at all, but it limits sessions to the AT's expiration instead of the RT's. If we want sessions that last as long as the RT does, we have to implement JIT renewal as above, and it gets complicated pretty quickly.

[BogdanDenis]

Hey @zburke, looks good, don't have any issues with implementation.
One question though - do all UI modules need to remove X-Okapi-Token header from all requests, or will it just be ignored?

[zburke]

@BogdanDenis, that's tricky to answer. Basically, if you pass the X-Okapi-Token in a request header AND in an AT via a cookie, then I think they have to match. All the UI code I saw in tickets linked to FOLIO-3627 was implemented sorta like

if (stripes.okapi.token) {
  headers['x-okapi-token': stripes.okapi.token;
}

which should be fine, because stripes.okapi.token will be undefined after this work merges.

[sonarcloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
4 Code Smells

73.4% Coverage
0.0% Duplication

Catch issues before they fail your Quality Gate with our IDE extension SonarLint