Navigate back to login (browser back button) and then login => No matching state found in storage

Same problem as the original library https://github.com/IdentityModel/oidc-client-js/issues/940.

The scenario is:

user lands on app page -> page checks user, if not logged in -> signinRedirect to Id server -> Id server redirects back to auth-callback -> auth-callback navigates to some page in app.

Now if user pressed back button which will take it back to the login (where the state (state which is sent to id server) wouldn’t be written to local storage which is why siginRedirectCallback throws this error.

https://github.com/IdentityModel/oidc-client-js/issues/940#issuecomment-532657529

Should oidc-client-ts leave the state available for some time?

[kherock]

I’m not sure if there’s much that should be done here. In my mind, navigating into the middle of an authentication flow is invalid and should generate an error. The spec doesn’t seem to have a strict prescription on how to treat this scenario, but it does suggesting associating an authentication session cookie with the nonce parameter provided by the client in order to prevent replay attacks. In case the auth server doesn’t implement this restriction (as in @pamapa’s screenshots), the UX I’d expect from the application side would be an error explaining that the sign in request is invalid with options to restart the sign in flow. We could make this simpler by providing a named error so that applications don’t need to parse error message strings.

[pamapa]

but the server responded with a redirection to the URL with the state stripped away from the params.

I assume that happen in may case.

The current oidc-client-ts implementation ex-changes the localStorage state against a profile, which makes it simple. I am afraid if we break that it will make things more complicated. Is only Cognito affected? Will using history.replaceState + forward button bring you too back?

@kherock Can you reproduce with your authentication service?