PYIC-7189 Invalidate repeat CRI callbacks

[Joe-Edwards-GDS]

Proposed changes

What changed

Clear the CRI OAuth session id as soon as we receive a successful callback for that CRI.

Why did it change

Previously we would only invalidate the CRI OAuth session id after processing the full CRI callback and a subsequent journey event.

For slow CRIs this can be a significant window of time (5-10s), and the user may get frustrated and either resubmit or refresh the page. This triggers a second CRI callback, however this callback will always fail:

• If the user resubmits with the same URL, the authorization code is single-use and will receive an error at token exchange
• If the user resubmits on the CRI side, they will generally have cleared the session, and will return an OAuth error

This means that the second callback will trigger an error scenario, which may complete faster than the first (possibly successful) request, leaving the user on an error screen.

By invalidating the session immediately, we should significantly reduce this window (although it will still exist), and instead produce an INVALID_OAUTH_STATE error, which will render pyi-attempt-recovery, allowing the user to try and recover their state.

The state they recover to will depend on the progress of the first callback:

• If the first callback is complete, they'll recover to the correct target state
• If the first callback is still processing, they'll recover to the CRI state, forcing them to revisit the CRI
  • This isn't ideal - but should eventually allow the user to return to IPV Core and recover their journey

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud