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:

oidc-client-ts/src/OidcClient.ts

Lines 134 to 135 in ae22167

	const signinState = signinRequest.state;
	await this.settings.stateStore.set(signinState.id, signinState.toStorageString());

Here it is read back from the store:

oidc-client-ts/src/OidcClient.ts

Lines 271 to 277 in ae22167

	const storedStateString = await this.settings.stateStore[removeState ? "remove" : "get"](response.state);
	if (!storedStateString) {
	logger.throw(new Error("No matching state found in storage"));
	throw null; // https://github.com/microsoft/TypeScript/issues/46972
	}
	const state = State.fromStorageString(storedStateString);

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 #734 (comment). 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.