disableNonceCheck always leads to an error

[ssaip]

on version 13.0.1

Current behavior
Passing { disableNonceCheck: true } to tryLoginCodeFlow (or other calling methods) will always result in Promise.reject()

The method is as following:

if (!options.disableNonceCheck) { ... }
return Promise.reject();

therefore, it will always result in an error.

Expected behavior
code should probably be something like:

        if (!options.disableNonceCheck) {
            if (!nonceInState) {
                this.saveRequestedRoute();
                return Promise.resolve();
            }
            if (!options.disableOAuth2StateCheck) {
                const success = this.validateNonce(nonceInState);
                if (!success) {
                    const event = new OAuthErrorEvent('invalid_nonce_in_state', null);
                    this.eventsSubject.next(event);
                    return Promise.reject(event);
                }
            }
        }
        this.storeSessionState(sessionState);
        if (code) {
            await this.getTokenFromCode(code, options);
            this.restoreRequestedRoute();
            return Promise.resolve();
        }
        else {
            return Promise.resolve();
        }

[thierryve]

Running into the same problem. @ssaip do you have any workaround for this issue?

[ssaip]

Running into the same problem. @ssaip do you have any workaround for this issue?

We forked the project, fixed it there and build it ourselves.

There's also an open pull request with the fix: #1211

[youett]

@jeroenheijmans any update on this? I think it is a clear bug because setting "disableNonceCheck" will skip the session-state-storage and code-to-token-exchange and always Promise.reject

[jeroenheijmans]

Nope, no update from me personally. I currently mostly moderate issues and answer questions when I can do so from my knowledge.

Judging (at a glance) based on the above comments, folks have found fixes and workarounds, so at first sight I can remove the "needs investigation" tag to label things a bit more appropriately.

Note that in general the library's development is not super active, so rolling with a fork that has a fix might be an option depending on your case.

Hope that helps!

[manfredsteyer]

Thanks for pointing this out. will be fixed in the next version.