How to solve this error: No state in response

[LouLamSan]

hi,I am using the latest version of oidc-client.ts, when trying to login and get the token, it prompts me an error: "No state in response". Could you please advise how to solve this issue?

The configuration in my client is as follows: const config = { authority: 'https://localhost:7150/', client_id: 'client1', redirect_uri: ${window.location.origin}/#/callback, response_type: 'code', scope: 'openid profile api', response_mode: 'query' }

and the error message like this: Error: No state in response at OidcClient.readSigninResponseState (OidcClient.ts:155:26) at OidcClient.processSigninResponse (OidcClient.ts:173:48) at UserManager._signinEnd (UserManager.ts:442:51) at UserManager.signinRedirectCallback (UserManager.ts:174:33) at Proxy.created (callback.vue:19:31) at callWithErrorHandling (runtime-core.esm-bundler.js:173:36) at callWithAsyncErrorHandling (runtime-core.esm-bundler.js:182:21) at callHook (runtime-core.esm-bundler.js:3608:5) at applyOptions (runtime-core.esm-bundler.js:3510:9) at finishComponentSetup (runtime-core.esm-bundler.js:7387:9)

the callback url like this: http://localhost:5007/#/callback?code=9F399AF8C82E4F458A5B1A37C79ADF28&state=b97ddcf6aa584df4a320e3022234bf75

[pamapa]

Your response mode is not query but fragment: response_mode: 'query' -> 'fragment'

[LouLamSan]

That was feasible and the previous error no longer occurs, but now I have received another error message: Error: authority mismatch on settings vs. signin state at ResponseValidator._processSigninState (ResponseValidator.ts:151:26) at ResponseValidator.validateSigninResponse (ResponseValidator.ts:62:14) at OidcClient.processSigninResponse (OidcClient.ts:175:31) at async UserManager._signinEnd (UserManager.ts:442:32) at async UserManager.signinRedirectCallback (UserManager.ts:174:22) at async Proxy.created (callback.vue:20:13)

I have checked the corresponding source code according to the error message, and I feel confused why the authority that I specified in the configuration is inconsistent with the state.authority（I noticed that this state seems to be read from my configuration.）

[pamapa]

You may need to enable logging, you can do like here described https://authts.github.io/oidc-client-ts/#logging. This and debugging + looking into session and local storage should help you find your issue...

[LouLamSan]

I started the logging as per your guidance, and I see a lot of output in the browser. Some of it is quite confusing. One message reads as follows: "[WebStorageStateStore] remove('9ef30a7377aa42058ceaf1264fb71be5'): begin." Does this mean that the state is being removed from local storage?

[pamapa]

Does this mean that the state is being removed from local storage?

Yes, old stale states are removed...

The state works like:

• client auth request -> authz server
• client remember what we sent (store state)
• authz server -> request to redirect_uri (client)
• client now needs to match that request with what was send (lookup/read state previously saved)
• there must be a state...

[net027]

是不是使用HashRouter，redirect_uri中包含字符"#“，导致不能从url中正确的读取state参数的值

[pamapa]

是不是使用HashRouter，redirect_uri中包含字符"#“，导致不能从url中正确的读取state参数的值

Means: "Is using HashRouter, the redirect_uri contains the character "#", so the value of the state parameter cannot be read correctly from the url" Thanks for pointing the user into the right direction. Please use English in this repository...

@LouLamSan You are using response_mode: 'query' but you have hash routes -> response_mode: 'fragment' might help...

[ximbong]

I got the same issue, although I'm not using hash router. My settings is:

 const settings = {
      authority: '...',
      redirect_uri: 'http://localhost:8000/login/callback',
      client_id: '...',
      client_secret: '...',
      client_authentication: 'client_secret_basic' as const,
      scope: 'openid profile',
      metadata: {
       ...
      }
    };

[LouLamSan]

response_mode: 'fragment'

Thank you for your guidance. I have modified the configuration to "response_mode: 'fragment'", but the issue still has not been resolved.

[pamapa]

To track your issue: debug/log where the state is stored: https://github.com/authts/oidc-client-ts/blob/ae221679d1f823abb4443146cdde90315bdde03e/src/OidcClient.ts#L134-L135

Here it is read back from the store: https://github.com/authts/oidc-client-ts/blob/ae221679d1f823abb4443146cdde90315bdde03e/src/OidcClient.ts#L271-L277

Maybe it is useful to add response.state in to the message of the thrown error...

[ch-lepp]

Could this be a browser problem?

WebKit seems to have some issues when accessing the sessionstorage to quickly before redirecting, as mentioned here. To quote from the subsequent discussion

A workaround is for the JavaScript code to wait before accessing the storage.

This might also be related to an old issue from oidc-client-js...

[tennox]

If y'all are having the same issue as me - using a SPA in hash-mode router, which will make problems with the URL params parsing:

As you can see, the URLSearchParams expects the input to only contain the query part, which would be the case for a typical fragment-style Oauth callback:

https://domain.org/oidc-callback#id_token=eyJh...&state=abc123&..

but in hash mode:

https://domain.org/#oidc-callback?id_token=eyJh...&state=abc123&..

Fragment parsing is thus not appropriate for this case. (and query isn't working either, as it ignores the #.. part of the URL) It would need a special parsing mode as part of this library PoC PR

[pamapa]

Please have a look at this issue https://github.com/authts/oidc-client-ts/issues/734#issuecomment-1298381823. Read through the thread. Summary:

Simply process the URL before passing it along to signinCallback

[pamapa]

This issue (question) staled some time ago, closing it for now.