Oidc-client-js: Uncaught (in promise) Error: No matching state found in storage

Created on 27 Jan 2020  路  11Comments  路  Source: IdentityModel/oidc-client-js

Hi,

Our scenario is like this: If user presses browser back button right after the login it goes back to provider. And there our provider asks for login again (they don't keep the session apparently). So, after entering the login info, user is redirected to our login result page with new token.

Here we only call the signinRedirectCallback method to get the user. But this method fails and goes in to the catch from promise. From the console I see following error:

Uncaught (in promise) Error: No matching state found in storage
    at oidc-client.min.js:1

In catch if I restart login by calling signInRedirect it works but I am just curious about what is the issue here. Is it because the second login can't overwrite the first one? Is there a good way to handle this from our application?

P.S. I can't make any change from provider side if that's necessary. Need to handle this in our application somehow.

question

Most helpful comment

Thank you for the reply. But in my case the Promise is rejected and goes to catch directly.

All 11 comments

the same problem

everything fine, everything works - but errors in console -

2020-01-29_16-58-08

Do you clear the callback page form your history entry? Perhaps you should. Here's an example:

https://github.com/IdentityServer/IdentityServer4/blob/master/samples/Clients/src/JsOidc/wwwroot/callback.js#L4

Thank you for the reply. But in my case the Promise is rejected and goes to catch directly.

I just dropped in to say, I was running into the same thing. Your key value for oidc. is missing. In order to debug it, I changed node_modules/oidc-client package.json to use the non-min version of oidc-client.js for debugging purposes.

I then put a break point in UserManager.prototype._signInStart. (line 10207-ish) Step through, and after the call to 'createSigninRequest' (line 10216-ish), check your storage, the key should be there 'oidc.' and values to go with it. That generated state id is sent to Identity Server as part of the authentication request's redirect string, you can see the &state param in the url for the request (which is subsequently used by the client to pull the state back out of storage after post-auth re-direct). Then put a breakpoint on 'return handle.navigate(...)' line 10222-ish. This is the actual redirect call. Let it redirect (to login page), then immediately check storage. If your key is still there and the values are gone, or both the key and values are gone, if it's not an http to https issue you're likely doing a localstorage.clear() in script on your login page.

I spent more time than I wanted to debugging through this library, and in the end IT WAS MEEEE!
;=P

Do you clear the callback page form your history entry? Perhaps you should. Here's an example:

https://github.com/IdentityServer/IdentityServer4/blob/master/samples/Clients/src/JsOidc/wwwroot/callback.js#L4

Sorry for running into this conversation, but no matter if I replace the history entry or not, I have a strange behavior only in Chrome.
The browser seems to ignore the callback page and goes straight to the Idsrv login page when the user presses back button. But when holding the back button and choosing explicitly the callback page from history entry - chrome hits the callback and everything is fine.
Should I enhance the callback page with proper headers? Why is chrome not hitting the callback? Any ideas?

Do you clear the callback page form your history entry? Perhaps you should. Here's an example:

https://github.com/IdentityServer/IdentityServer4/blob/master/samples/Clients/src/JsOidc/wwwroot/callback.js#L4

Unfortunatly we get thrown out of the 'then' before we start the function. the exception seems to be thrown in signinRedirectCallback

@abarisuzuner

i have fixed this issue by alllowing cookies to store data.actually i have faced this issue from the last 4 month but i could not able to find any clue about this error. but yesterday my colleague and me were trying find out the exact issue and we have found that cookie is blocked for our app url. so we have allow to it and issue is solved within a pulse of second.

-
Screenshot from 2020-04-21 18-32-11

go to show cookies and other site data then go to blocked tab and allow from there itself will fix the issue

Much of these problems are due to browsers trying to protect users from tracking/advertising software and sites. Unfortunately to implement many of the OIDC/OAuth2 protocols from the client browser/JS side, we need to utilize the similar storage mechanisms. if these features are disabled/blocked wholesale, then there's not much we can do except reachitect to a more BFF pattern:

https://leastprivilege.com/2020/03/31/spas-are-dead/

@abarisuzuner

i have fixed this issue by alllowing cookies to store data.actually i have faced this issue from the last 4 month but i could not able to find any clue about this error. but yesterday my colleague and me were trying find out the exact issue and we have found that cookie is blocked for our app url. so we have allow to it and issue is solved within a pulse of second.

Screenshot from 2020-04-21 18-32-11

go to show cookies and other site data then go to blocked tab and allow from there itself will fix the issue

Did you also change the store type from tbe oidc library? And how would you handle people denying cookies?
We now handle people who have cookies disabled by showing an alert and not rendering the app, same for storage.

Much of these problems are due to browsers trying to protect users from tracking/advertising software and sites. Unfortunately to implement many of the OIDC/OAuth2 protocols from the client browser/JS side, we need to utilize the similar storage mechanisms. if these features are disabled/blocked wholesale, then there's not much we can do except reachitect to a more BFF pattern:

https://leastprivilege.com/2020/03/31/spas-are-dead/

Thank you for that answer we were thinking the same, we have decided to block users who do not have localstorage available.
There are some older devices with android 5.1 that do not have localstorage activated automatically.
Now we only need to write a how to on turning on the localstorage 馃榿

Ok, I think it's safe to close this issue now.

Was this page helpful?
0 / 5 - 0 ratings