OAuth migration | Force user to sign in if Access token auth_time older than 30 minutes

[raphaelkabo]

Changes

Context

After deploying #1294 and enabling Okta on PROD manage-frontend, we discovered an Okta behaviour which was undocumented in the sense that it was only documented in a modal in the UI, three layers down, after you clicked a specific radio button, and the actual documentation completely contradicted it:

One is reminded of a quote from The Hitchhiker's Guide To The Galaxy:

“But the plans were on display…”
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well, the lights had probably gone.”
“So had the stairs.”
“But look, you found the notice, didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”

What this means in practice is that, when passing the max_age parameter when requesting OAuth tokens:

• Regular email/password users will be forced to sign in again after max_age
• Users of the FEDERATION or SOCIAL types (i.e. social login users who have never set a password) will never be forced to sign in again as long as their global Okta session is not expired. This is probably most of our social users.

This behaviour means that we can't reliably enforce the MMA behaviour where a user must reauthenticate if they last authenticated more than 30 minutes ago using Okta settings alone.

For this reason, this PR adds the following check into identityMiddleware:

• Does the user's ID token have an auth_time claim longer than 30 minutes in the past?
• If the claim is older than 30 minutes, we:
  • Call the Okta OAuth API to revoke the associated Access token
  • Delete the ID and Access token cookies
  • Redirect the browser to the Gateway /reauthenticate route. This route always shows a signin form, irrespective of any session set in the browser. This essentially replicates the previous, IDAPI behaviour in MMA.
• If the claim is newer than 30 minutes, we proceed with the rest of the middleware.
• For routes which don't require sign in, if the ID token is older than 30 minutes, the user is designated signedInNotRecently but allowed to proceed to the route. This again replicates the old IDAPI behaviour.

The auth_time claim

According to the OpenID spec, and confirmed by Okta, the auth_time claim is "Time when the End-User authentication occurred" in UNIX seconds, which in Okta land means the last time the user actively authenticated, i.e. created their Okta session. The OpenID spec states that auth_time is returned whenever the max_age parameter is sent in the OAuth request, which in MMA is always. The Okta docs state that auth_time is a 'base claim', always returned. We've added logging in the check for auth_time which will give us data on missing auth_time claims, if any.

Further reading for nerds here:

• https://openid.net/specs/openid-connect-core-1_0.html
• https://openid.net/specs/openid-connect-basic-1_0.html
• https://developer.okta.com/docs/reference/api/oidc/#reserved-claims-in-the-payload-section

Other changes

• We add end-to-end testing for the auth_time behaviour, which sets the Okta max_age to a very short value and attempts to refresh the page, expecting to be redirected.
• We add unit tests for the new utility functions.
• There's a fair amount of refactoring to improve the middleware - rather than various utility functions fetching their own Okta config object async, the top-level middleware does this once and passes it down the chain. This also required a lot of refactoring in tests.
• We now redirect identityMiddleware error states to a new frontend error page, /sign-in-error, which shows a more helpful message and a link to sign out, which is likely to resolve edge-case sign in issues:

Testing

• Tested on CODE (Okta disabled)
• Tested on CODE (Okta enabled)
• Tested on PROD (Okta disabled)
• Tested on PROD (Okta enabled)

[prout-bot]

Overdue on PROD (merged by @raphaelkabo 15 minutes and 4 seconds ago) What's gone wrong?

[prout-bot]

Seen on PROD (merged by @raphaelkabo 46 minutes and 52 seconds ago) Please check your changes!